left函数用于从流水号左侧提取固定长度前缀，如left(order_no,3)取“ord”；需配合trim处理空格、coalesce处理null，并注意跨数据库空值与负数长度差异，性能敏感场景应建函数索引。
LEFT函数提取流水号前缀的典型用法
当流水号格式统一（比如 ORD20240001、INV20240002），且前缀长度固定（如前3位是业务类型码），LEFT 是最直接的选择。它从字符串左侧截取指定字符数，不依赖分隔符，性能好、兼容性强。
常见错误是把长度参数写成变量却没加括号或类型转换（尤其在 SQL Server 中 LEFT(col, @len) 要求 @len 是整数，不能是字符串）；另一个坑是忽略字段可能含空格或 NULL——LEFT(NULL, 3) 结果仍是 NULL，不是空字符串。
- 明确写死长度：例如提取前3位，用
LEFT(order_no, 3) - 配合
TRIM()预处理：防止前导空格干扰，写成LEFT(TRIM(order_no), 3) - 处理 NULL：需要默认值时套一层
COALESCE(LEFT(TRIM(order_no), 3), 'UNK')
RIGHT函数适用于后缀识别，但也能反推前缀？
RIGHT 本身不用于提取前缀，但有人误以为“用 RIGHT 取后几位再反转”能替代 LEFT。这不仅多此一举，还引入额外函数调用和逻辑错误风险（比如 REVERSE(RIGHT(REVERSE(col), n)) 在含 Unicode 或特殊字符时行为不稳定，且 MySQL 8.0 以下不支持嵌套函数深度超过限制）。
真正需要用 RIGHT 的场景是识别流水号末尾的序列号部分（如 ORD20240001 中的 0001），此时长度固定才可靠。若前缀长度不固定（如 REFUND2024001 vs RET2024002），LEFT 和 RIGHT 都失效，必须换用 SUBSTRING_INDEX（MySQL）、STRING_SPLIT（SQL Server）或正则（PostgreSQL 的 REGEXP_SUBSTR）。
- 别为前缀硬套
RIGHT，这是设计误用 - 确认业务规则：前缀是否真「固定长度」？查样本数据，别只看文档
- 测试边界值：长度为 0、超长（如
LEFT('A', 10)返回'A'，不会报错但结果不符预期）
不同数据库对 LEFT/RIGHT 的空值和超长处理差异
MySQL 和 PostgreSQL 对 LEFT(str, n) 中 n 为负数会报错；SQL Server 则返回空字符串。更隐蔽的是空字符串处理：SQLite 的 LEFT('', 3) 返回空字符串，而某些旧版 Oracle（需用 SUBSTR 模拟）可能返回 NULL。这些差异在跨库迁移或联合查询时容易暴露。
- 避免负数长度：检查应用层传参，不要让
n来自未校验的用户输入 - 统一空值策略：在 WHERE 条件中慎用
LEFT(col, 3) = 'ORD'，因为如果col是 NULL 或空串，结果不可控；建议显式加AND col IS NOT NULL AND col != '' - 长度参数来源要可信：如果是动态长度（如按业务类型查配置表），确保该配置值存在且为正整数
前缀提取后常被忽略的排序与索引问题
直接在 SELECT 中用 LEFT(order_no, 3) 提取前缀没问题，但若要在 WHERE 或 ORDER BY 中高频使用（比如按前缀分组统计），每次都计算会拖慢性能。这时不能只想着“先写出来再说”，得考虑是否建计算列或函数索引。
例如 PostgreSQL 支持 CREATE INDEX idx_prefix ON orders ((LEFT(order_no, 3)))；SQL Server 需先建计算列再索引；MySQL 5.7+ 才支持函数索引，且要求表达式确定性。没索引时，WHERE LEFT(order_no, 3) = 'INV' 无法走 order_no 的普通 B-tree 索引。
- 上线前用
EXPLAIN看执行计划，确认是否用了索引 - 如果前缀长度可变，函数索引基本无效，优先重构数据模型（比如拆出
prefix字段并维护一致性） - 注意 collation：大小写敏感的排序规则下，
LEFT结果参与比较时可能意外区分大小写
LEFT 还是其他方案，最后补上索引和空值防护。
