SUBSTRING函数参数顺序在MySQL/PostgreSQL中为(str, start, length)，SQL Server/Oracle也支持该格式；起始位置从1开始，负数索引仅PostgreSQL原生支持；截取需防越界，应配合LOCATE/CHARINDEX判断；WHERE中使用会导致索引失效，建议用计算列优化。
SUBSTRING 函数的基本用法和参数顺序差异
SUBSTRING 在不同数据库中行为不一致，核心坑在于参数顺序：MySQL 和 PostgreSQL 用 SUBSTRING(str, start, length)，而 SQL Server 和 Oracle 支持两种写法，但 SUBSTRING(str, start, length) 更通用。PostgreSQL 还支持 SUBSTR() 别名，但建议统一用 SUBSTRING 提高可移植性。
- MySQL 中
SUBSTRING('hello', 2, 3)返回'ell'（从第 2 位起取 3 个字符） - SQL Server 中同样写法结果一致，但若省略
length（如SUBSTRING(col, 5, NULL)），会报错，必须显式指定或用LEN(col)-4计算 - 起始位置从 1 开始，不是 0 —— 这是新手最常翻车的地方，
SUBSTRING('abc', 0, 1)在 MySQL 返回空，在 SQL Server 直接报错
截取固定位置的子串时如何避免越界错误
当字段长度不确定（比如日志字段、用户输入），直接硬写 length 参数容易截出空值或报错。例如想取邮箱 @ 符号前的用户名：SUBSTRING(email, 1, CHARINDEX('@', email) - 1)（SQL Server）或 SUBSTRING(email, 1, LOCATE('@', email) - 1)（MySQL）。
- 必须先确认分隔符存在，否则
LOCATE/CHARINDEX返回 0，导致SUBSTRING(..., 1, -1)出错 - 安全写法要加条件判断：
CASE WHEN LOCATE('@', email) > 0 THEN SUBSTRING(email, 1, LOCATE('@', email) - 1) ELSE email END - PostgreSQL 可用
SPLIT_PART(email, '@', 1)更简洁，但不属于SUBSTRING体系，跨库迁移时需注意
用 SUBSTRING 配合其他函数提取结构化信息
真实业务中常要从非结构化字段里“抠”数据，比如订单号格式为 'ORD-2024-00123'，需提取年份和序号：
- 年份：MySQL 写
SUBSTRING(order_no, 5, 4)；SQL Server 同样适用 - 序号部分（最后 5 位）：不能简单写
SUBSTRING(order_no, -5, 5)—— 大多数数据库不支持负数索引（仅 PostgreSQL 的SUBSTRING(str FROM -5 FOR 5)支持） - 更可靠方式是结合
REVERSE+SUBSTRING：SUBSTRING(REVERSE(order_no), 1, 5)再套一层REVERSE，或者用正则（如 MySQL 8.0+ 的REGEXP_SUBSTR(order_no, '\d{5}$')）
性能与索引失效风险必须提前意识到
SUBSTRING 是典型“无法走索引”的操作。哪怕你在 WHERE 条件里写 WHERE SUBSTRING(phone, 1, 3) = '138'，数据库也无法利用 phone 字段上的索引，只能全表扫描。
- 如果高频按前缀查询手机号，应额外建计算列（SQL Server）或生成列（MySQL 5.7+）并为其建索引：
ALTER TABLE users ADD phone_prefix VARCHAR(3) STORED AS (SUBSTRING(phone, 1, 3)) - 日志类字段做
SUBSTRING分析时，优先考虑应用层解析，或用物化视图/汇总表预处理，而不是每次查都实时截取
实际用的时候，别只盯着语法对不对，先想清楚这个截取是不是真得在 SQL 层做——很多场景下，把逻辑搬到应用代码里反而更稳、更快、更容易测。
