substring函数在不同数据库中写法不一致：mysql/postgresql用substring(str,pos,len)，sql server用substring(str,start,length)，oracle仅支持substr(str,pos,len)；起始位置均为1-based，跨库推荐优先使用substr或left/right函数。
SUBSTRING 函数在不同数据库中的写法差异
MySQL、PostgreSQL、SQL Server 和 Oracle 对 SUBSTRING 的支持不一致，直接套用会报错。MySQL 和 PostgreSQL 支持 SUBSTRING(str, pos, len)，SQL Server 用 SUBSTRING(str, start, length)（参数名不同但行为一致），而 Oracle 默认只认 SUBSTR(str, pos, len) —— 用 SUBSTRING 会提示 “invalid identifier”。
实操建议：
- 先查当前数据库类型：
SELECT VERSION()（MySQL）、SELECT current_database()（PostgreSQL）、SELECT @@VERSION（SQL Server） - 跨库兼容场景下，优先用标准 SQL 函数
SUBSTR，它在四大主流数据库中都可用 - 若必须用
SUBSTRING，注意 SQL Server 中起始位置从 1 开始，不是 0；传入负数或超出长度不会报错，而是返回空字符串或截取到末尾
截取固定长度字段时常见的越界错误
想从第 5 位开始取 8 个字符，写成 SUBSTRING(content, 5, 8)，结果某些行返回空或长度不足 8 —— 这不是函数失效，而是源字段本身长度不够。
常见现象：
-
content值为'abc'，执行SUBSTRING(content, 2, 8)返回'bc'（不是报错，也不是补空格） - 字段为
NULL时，整个表达式结果为NULL，容易被误判为“没截出来” - 中文字符在 UTF-8 下占 3 字节，但
SUBSTRING按字符计数，不是字节，所以不用额外处理编码
安全写法示例（MySQL/PostgreSQL）：
SELECT COALESCE(SUBSTRING(title, 10, 6), '') AS key_part FROM articles;用
COALESCE 避免 NULL 干扰后续逻辑。从日志或路径中精准提取关键子串的典型模式
比如字段值是 '/api/v2/users/12345/profile?tab=info'，要稳定取出用户 ID '12345'。不能硬写 SUBSTRING(url, 18, 5)，因为 ID 长度不固定，且路径结构可能变化。
更可靠的思路：
- 先用
LOCATE（MySQL）或POSITION（PostgreSQL）定位分隔符，如LOCATE('/users/', url) + LENGTH('/users/')得起始偏移 - 再用
LOCATE找下一个'/'的位置，两者相减得长度 - 组合写法（MySQL）：
SELECT SUBSTRING(url, LOCATE('/users/', url) + 8, LOCATE('/', url, LOCATE('/users/', url) + 8) - (LOCATE('/users/', url) + 8) ) AS user_id FROM logs;
这种写法比“猜位置+固定长度”鲁棒得多，尤其适合解析 URL、JSON 片段或带分隔符的日志字段。
性能影响与索引失效风险
在 WHERE 子句中对字段用 SUBSTRING，比如 WHERE SUBSTRING(phone, 1, 3) = '138'，会导致该列无法使用普通 B-tree 索引（除非建函数索引）。
优化方向：
- MySQL 8.0+ 可建函数索引：
CREATE INDEX idx_phone_prefix ON users ((SUBSTRING(phone, 1, 3))) - PostgreSQL 支持表达式索引：
CREATE INDEX idx_phone_prefix ON users (SUBSTR(phone, 1, 3)) - 更通用的做法是冗余一个前缀字段（如
phone_prefix），写入时同步计算并建普通索引
函数索引虽能解燃眉之急，但增加维护成本；真正高频查询固定前缀的场景，冗余字段反而更稳。
固定长度截取看着简单，但一旦字段内容不规范、数据库版本混杂、或后续要加查询条件，很容易掉进隐式转换、NULL 传播、索引失效这些坑里。动手前先确认数据分布和查询模式，比死记函数语法重要得多。
