SUBSTRING是标准SQL三参数函数，LEFT是方言两参数函数；前者跨库兼容性强但语法冗长，后者简洁但存在负长度静默处理、不支持PostgreSQL等兼容性问题。
SUBSTRING 和 LEFT 的本质区别在哪
SUBSTRING 是标准 SQL 函数，支持三参数：SUBSTRING(str, start, length)；LEFT 是 MySQL/SQL Server 等方言函数，只支持两参数：LEFT(str, length)，从开头截固定长度。PostgreSQL 不支持 LEFT，用 SUBSTRING(str FROM 1 FOR length) 替代。
常见错误现象：LEFT(col, -1) 在 MySQL 里返回空字符串（不是报错），但 SUBSTRING(col, 1, -1) 直接报错 —— 这说明 LEFT 对负长度做了静默处理，容易掩盖逻辑 bug。
使用场景差异：
- 要去掉末尾一个字符（比如删掉逗号）：用
SUBSTRING(col, 1, LENGTH(col)-1)更可靠 - 取前 10 个字：用
LEFT(col, 10)更简洁，但注意它不处理 NULL ——LEFT(NULL, 10)返回 NULL，而有些业务期望空字符串 - 跨数据库兼容需求强：只用
SUBSTRING，避免方言陷阱
截取“从某字符后开始”的内容时别硬套 LEFT
想取 'user_12345' 中下划线后的数字？别写 LEFT(col, INSTR(col, '_') + 1) —— 那是反向操作，结果是 'user_'，不是你要的 '12345'。
正确做法是组合 SUBSTRING 与定位函数：
- MySQL：
SUBSTRING(col, INSTR(col, '_') + 1) - PostgreSQL：
SUBSTRING(col FROM POSITION('_' IN col) + 1) - SQL Server：
SUBSTRING(col, CHARINDEX('_', col) + 1, LEN(col))
容易踩的坑：INSTR 找不到字符时返回 0，SUBSTRING(col, 0 + 1, ...) 看似安全，但若字段本身为 NULL 或空串，整个表达式可能返回 NULL，下游逻辑没判空就崩了。
性能影响：SUBSTRING 在 WHERE 条件里能走索引吗
不能。只要对列用了函数，比如 WHERE SUBSTRING(name, 1, 3) = 'abc'，绝大多数数据库（MySQL、PostgreSQL、SQL Server）都会放弃索引扫描，转为全表扫描。
替代方案更实际：
- 想查“以 abc 开头”：直接写
WHERE name LIKE 'abc%'，能用上 B-tree 索引 - 必须动态截取中间段？考虑冗余字段：加一个
name_prefix字段存前三位，建索引，应用层维护一致性 - MySQL 8.0+ 支持函数索引：
CREATE INDEX idx_name_sub ON t ((SUBSTRING(name, 1, 3)))，但要注意该索引只对这个固定表达式生效
中文、emoji 场景下 LENGTH 和 CHAR_LENGTH 的坑
LENGTH() 返回字节数，CHAR_LENGTH() 返回字符数。在 utf8mb4 下，一个 emoji 占 4 字节，但只是 1 个字符。
示例：SELECT LENGTH('a?c'), CHAR_LENGTH('a?c') → 返回 5 和 3。
所以如果你写 SUBSTRING(name, 1, 10) 本意是取前 10 个字符，但用 LENGTH(name) 做边界判断，就会出错。尤其做分页截断、日志打点时，显示异常或被截半。
实操建议：
- 所有涉及“第 N 个字符”“前 N 个字符”的逻辑，统一用
CHAR_LENGTH()替代LENGTH() - MySQL 默认排序规则（如
utf8mb4_general_ci）对 emoji 排序不可靠，SUBSTRING截出来再比较可能和预期不符
最麻烦的其实是嵌套：比如 SUBSTRING(SUBSTRING(col, 1, CHAR_LENGTH(col)-1), -5)，既要用字符数算长度，又要小心负数起始位置在不同库行为不一致 —— 这类逻辑最好提到应用层做，SQL 里尽量保持单层、明确、可测。
