SUBSTRING函数在不同数据库中参数顺序和行为不一致：MySQL/PostgreSQL为SUBSTRING(str, start, length)，SQL Server虽支持相同语法但对TEXT类型需显式转换，且起始位置从1开始；提取分隔符间内容应结合CHARINDEX/LOCATE动态定位，避免硬编码；WHERE中滥用SUBSTRING会导致索引失效，宜用范围查询替代。
SUBSTRING 函数在不同数据库中的参数顺序不一致
MySQL、PostgreSQL 和 SQL Server 对 SUBSTRING 的参数定义不同，直接套用会返回空或报错。MySQL 和 PostgreSQL 用 SUBSTRING(str, start, length)，而 SQL Server 支持两种语法：SUBSTRING(str, start, length) 和 LEFT/RIGHT 等等价写法，但部分旧版本对负数起始位置处理异常。
常见错误现象：SUBSTRING('2024-05-12', 6, 2) 在 MySQL 中返回 '05'，但在某些 SQL Server 实例中若字段为 TEXT 类型且未显式转换，可能报错 Argument data type text is invalid for argument 1 of substring function.
- 使用前先确认数据库类型，执行
SELECT VERSION()（MySQL）或SELECT @@VERSION（SQL Server） - 对
TEXT/NTEXT字段，务必先转成VARCHAR：SUBSTRING(CAST(col AS VARCHAR(100)), 6, 2) - 起始位置从 1 开始计数（不是 0），超出长度时多数数据库返回空字符串而非报错
提取固定分隔符之间的子串（如邮箱用户名）
当目标字符串有稳定结构（例如 user@domain.com），靠硬编码位置容易失效。更可靠的方式是结合 CHARINDEX（SQL Server）或 LOCATE（MySQL）动态定位分隔符。
示例：从 email 字段取 @ 前的用户名
SELECT
SUBSTRING(email, 1, CHARINDEX('@', email) - 1) AS username
FROM users
WHERE email LIKE '%@%';- 必须加
WHERE过滤含@的记录，否则CHARINDEX返回 0，SUBSTRING(..., 1, -1)导致结果为空 - MySQL 用户改用
LOCATE('@', email)，行为一致；PostgreSQL 则用POSITION('@' IN email) - 如果分隔符可能重复（如
first.last@company.co.uk），需明确取第一个还是最后一个 ——CHARINDEX默认找首次出现，要取最后可用REVERSE + CHARINDEX组合
处理可变长前缀后的固定偏移（如日志行解析）
日志格式类似 [INFO][2024-05-12 10:23:45] User login: alice，想取冒号后用户名。不能直接写 SUBSTRING(log, 32, 10)，因为时间戳长度固定但前缀级别（INFO/WARN/ERROR）不同。
正确做法是两次定位：先找 :，再向后跳空格取词
SELECT
LTRIM(SUBSTRING(log, CHARINDEX(':', log) + 1, 50)) AS username
FROM logs;-
+ 1跳过冒号本身，50是保守上限，避免截断；后续可用CHARINDEX(' ', ...)精确切到下一个空格 - 注意
LTRIM必不可少 —— 冒号后可能是空格或制表符，直接SUBSTRING会带前导空白 - 若目标子串含空格（如全名
User login: Alice Smith），需改用正则（PostgreSQL 的REGEXP_SUBSTR或 SQL Server 2022+ 的STRING_SPLIT配合OFFSET）
性能陷阱：在 WHERE 条件中滥用 SUBSTRING
用 SUBSTRING(phone, 1, 3) = '138' 查询号段，会导致索引失效 —— 大多数数据库无法对函数结果走 B-tree 索引，哪怕 phone 字段本身已建索引。
- 替代方案：用范围查询模拟前缀匹配：
phone >= '138' AND phone （前提是字段类型为字符串且无前导零） - 若必须用函数提取，考虑建计算列并索引：
ALTER TABLE users ADD area_code AS SUBSTRING(phone, 1, 3) PERSISTED（SQL Server），然后对area_code建索引 - MySQL 5.7+ 支持函数索引：
CREATE INDEX idx_area ON users ((SUBSTRING(phone, 1, 3)))，但注意括号语法和版本兼容性
真正麻烦的是嵌套调用，比如 SUBSTRING(SUBSTRING(col, 5, 20), 2, 8) —— 不仅难读，优化器也几乎放弃推导，查大表时很容易拖慢整个查询。
