SUBSTRING函数在不同数据库中参数顺序一致但细节有差异：MySQL、PostgreSQL、SQL Server均用1-based索引且语法为SUBSTRING(str, start, len)，Oracle用SUBSTR；起始位置不能为0，否则MySQL返回空、SQL Server行为异常；处理NULL需COALESCE，性能优化应避免WHERE中直接使用SUBSTRING而改用LIKE或添加持久化计算列索引。
SUBSTRING 函数在不同数据库里的写法差异
MySQL、PostgreSQL 和 SQL Server 都支持 SUBSTRING，但参数顺序和起始位置规则不一样——这是最容易出错的地方。MySQL 和 PostgreSQL 用 1-based 索引（第一个字符位置是 1），SQL Server 也是 1-based，但 Oracle 用的是 SUBSTR，且同样从 1 开始。别按 Python 思维默认从 0 开始，否则会偏移一位。
常见错误现象：SUBSTRING(order_no, 0, 4) 在 MySQL 中返回空字符串（因为起始位置必须 ≥1）；在 SQL Server 中虽不报错，但行为可能不符合预期。
- MySQL / PostgreSQL：
SUBSTRING(order_no, start_pos, length) - SQL Server：
SUBSTRING(order_no, start_pos, length)（同上，但对 NULL 更敏感） - Oracle：
SUBSTR(order_no, start_pos, length)（函数名不同）
截取订单编号前缀（如“ORD-2024-”后的数字部分）
很多订单号形如 'ORD-2024-00123'，要提取末尾的流水号（'00123'）。不能硬写 SUBSTRING(order_no, 10, 5)，因为年份可能变长（比如到 2025），位数不固定。
更稳妥的做法是结合定位函数：
- MySQL：用
SUBSTRING(order_no, LOCATE('-', order_no, LOCATE('-', order_no) + 1) + 1)向后找第二个'-'的位置 - PostgreSQL：用
SUBSTRING(order_no FROM POSITION('-' IN order_no, POSITION('-' IN order_no) + 1) + 1)（注意语法差异） - SQL Server：用
SUBSTRING(order_no, CHARINDEX('-', order_no, CHARINDEX('-', order_no) + 1) + 1, LEN(order_no))
如果确定格式稳定，直接用 SUBSTRING(order_no, 10, LEN(order_no)-9) 也行，但得确认字段长度足够，否则截出来全是空格或 NULL。
处理 NULL 或超长截取导致的异常结果
SUBSTRING 遇到 NULL 输入会直接返回 NULL，不是空字符串；如果指定长度超过源字符串长度，多数数据库会自动截断到末尾（不报错），但有些 ORM 或中间件会把这种“隐式截断”当成数据异常。
- 加
COALESCE防 NULL：SUBSTRING(COALESCE(order_no, ''), 1, 8) - 加长度校验更安全：
CASE WHEN LEN(order_no) >= 8 THEN SUBSTRING(order_no, 1, 8) ELSE order_no END - SQL Server 中
SUBSTRING(NULL, 1, 1)返回 NULL，但SUBSTRING('', 1, 1)返回空字符串——二者语义不同，别混用
性能提醒：别在 WHERE 条件里对大字段用 SUBSTRING 做匹配
比如写 WHERE SUBSTRING(order_no, 1, 3) = 'ORD'，会导致全表扫描，无法走 order_no 字段上的索引。真正要查前缀，应该用 order_no LIKE 'ORD%'。
如果业务确实依赖中间某段做查询（比如提取年份做分区筛选），考虑增加计算列并建索引：
- MySQL 5.7+：
ALTER TABLE orders ADD COLUMN order_year VARCHAR(4) STORED AS (SUBSTRING(order_no, 5, 4))，再建索引 - SQL Server：
ALTER TABLE orders ADD order_year AS SUBSTRING(order_no, 5, 4) PERSISTED
没加 PERSISTED 或 STORED 的计算列，每次查询仍要实时计算，白忙活。
