SUBSTRING函数通用写法为SUBSTRING(str, start, len)，起始位置从1开始，len为负或超长时各库行为不同：MySQL静默截断或返空，SQL Server报错，PostgreSQL需用FROM/ FOR语法；跨库推荐LEFT/RIGHT。
SQL里SUBSTRING函数怎么写才不报错
不同数据库对SUBSTRING的参数顺序和命名支持不一致，直接照搬示例容易触发Invalid parameter count或function does not exist错误。MySQL、PostgreSQL、SQL Server都支持SUBSTRING，但SQLite只认SUBSTR；PostgreSQL还允许用substring()加正则，但初学者容易混淆。
通用写法（兼容MySQL/SQL Server）：SUBSTRING(column_name, start_position, length)
常见错误点：
-
start_position从1开始（不是0），传0或负数在MySQL中可能返回空，在SQL Server中会报错 -
length为负数时，MySQL返回空字符串，PostgreSQL直接报错 - 如果
length超出字段实际长度，多数数据库会自动截断，不报错，但结果可能不符合预期
想从邮箱里取用户名部分，SUBSTRING配合CHARINDEX或LOCATE怎么用
提取user@example.com中@前的内容，关键在于动态定位分隔符位置，不能写死起始位。
SQL Server写法：SUBSTRING(email, 1, CHARINDEX('@', email) - 1)
MySQL写法：SUBSTRING(email, 1, LOCATE('@', email) - 1)
注意点：
- 如果字段里没有
@，CHARINDEX返回0，减1后变成-1，SQL Server会报错；MySQL的LOCATE返回0，SUBSTRING(..., 1, -1)结果为空，不报错但逻辑失效 - 稳妥做法是加
CASE WHEN判断：CASE WHEN LOCATE('@', email) > 0 THEN SUBSTRING(email, 1, LOCATE('@', email) - 1) ELSE email END
用SUBSTRING做模糊匹配前缀时，为什么索引失效了
写WHERE SUBSTRING(name, 1, 3) = 'abc'会导致全表扫描——因为函数作用于字段，数据库无法利用name字段上的B-Tree索引。
替代方案更高效：
- 改用前缀匹配：
WHERE name LIKE 'abc%'（可走索引） - 如果必须截取中间段，且查询频繁，考虑新增计算列并建索引（如MySQL 5.7+的Generated Column）：
ALTER TABLE users ADD name_prefix VARCHAR(3) AS (SUBSTRING(name, 1, 3)) STORED;CREATE INDEX idx_name_prefix ON users(name_prefix); - PostgreSQL可用函数索引：
CREATE INDEX idx_name_sub ON users (SUBSTRING(name, 1, 3));
SUBSTRING处理NULL或超长字段时的边界行为
SUBSTRING(NULL, 1, 5)在所有主流数据库中都返回NULL，这点一致；但字段内容长度不足时表现不同：
- MySQL：
SUBSTRING('ab', 1, 10)→'ab'（静默截断） - SQL Server：同样返回
'ab'，无警告 - PostgreSQL：也返回
'ab'，但若用substring('ab' from 1 for 10)语法，行为相同
真正容易被忽略的是字符集影响：如果字段是UTF8MB4，一个中文字符占3–4字节，但SUBSTRING按“字符”计数，不是字节。例如SUBSTRING('你好world', 1, 4)返回'你好wo'，不是前4个字节。
跨库迁移或对接前端时，这个细节常导致显示错位或截断异常。
