right函数正确写法为right(str, len)，要求str为字符串表达式、len为非负整数；传入负数或类型错误参数会报错，null返回null，空字符串返回空串，超长则返回原字符串。
LEFT 不适合截取后缀，RIGHT 才是正确选择；但“固定后缀编码”这个说法本身容易误导——RIGHT 只能截固定长度的末尾字符，不能识别语义上的“后缀”。
RIGHT 函数怎么写才不报错
RIGHT(str, len) 要求两个参数：字符串表达式（列名、函数结果或常量）在前，非负整数长度在后。常见错误包括：
-
RIGHT('order_no', 4)—— 把字段名当字符串字面量，结果永远是'r_no'，不是每行的值 -
RIGHT(order_no, -4)—— MySQL 直接报Invalid argument for function right()；SQL Server 报错更早 -
RIGHT(order_no, @len)（SQL Server）—— 若@len是VARCHAR类型，会隐式转换失败，必须先CAST(@len AS INT) - 中文/emoji 按字符计数，
RIGHT('订单#2024001', 4)返回'2024001'？不，是'001'（因为'#'算 1 字符，'订单'占 2 字符，共 7 字符，取后 4 位是'2001'？等等——实际是'2024001'共 7 字符，RIGHT(..., 4)就是最后 4 个：'001'？不对，再数：'订'(1)、'单'(2)、'#'(3)、'2'(4)、'0'(5)、'2'(6)、'4'(7)、'0'(8)、'0'(9)、'1'(10) → 共 10 字符，RIGHT(..., 4)='001'？错，是'001'前还有 '4' → 实际为'4001'。关键：别靠脑算，用CHAR_LENGTH()验证。
为什么 RIGHT(order_no, 4) 在 WHERE 中性能差
直接写 WHERE RIGHT(order_no, 4) = '0001' 几乎必然触发全表扫描，因为数据库无法对函数结果使用普通索引。真实影响：
- MySQL/PostgreSQL：即使
order_no上有 B-tree 索引，该条件也无法命中 - SQL Server：同理，除非你显式创建函数索引（如
CREATE INDEX ix_order_no_suffix ON t (RIGHT(order_no, 4))），但仅 SQL Server 2016+ 支持计算列索引，且维护成本高 - 更高效替代：改用后缀匹配
WHERE order_no LIKE '%0001'—— 注意，这依然无法走标准索引，但某些引擎（如 MySQL 8.0+ 的倒排索引实验特性）或全文索引可优化；生产环境更推荐冗余字段
遇到 NULL 或空字符串怎么办
RIGHT(NULL, 4) 永远返回 NULL，不是空字符串；RIGHT('', 4) 返回 ''。这意味着：
- 分组或去重时，
NULL和''被视为不同值 - 和字符串字面量比较（如
= '0001'）时，NULL结果恒为UNKNOWN，不会进入结果集 - 安全兜底写法：
COALESCE(RIGHT(TRIM(order_no), 4), '')—— 先TRIM防前导/尾随空格干扰长度，再COALESCE把NULL转空串；但注意：这掩盖了原始数据缺失问题 - 若需区分“原字段为空”和“截出来为空”，必须拆开判断：
CASE WHEN order_no IS NULL THEN 'NULL_VAL' WHEN CHAR_LENGTH(TRIM(order_no))
真正麻烦的不是函数怎么写，而是业务里所谓“固定后缀”往往并不固定——比如 'INV-2024-001' 和 'REF-2024-1' 的末尾数字位数不同。这时 RIGHT 会截出 '001' 和 '-1'，语义完全错乱。得切分符（SUBSTRING_INDEX）、找位置（LOCATE + SUBSTRING）或正则，而不是硬套 RIGHT。
