LEFT和RIGHT函数在MySQL、SQL Server中直接支持且行为一致；PostgreSQL默认不支持，需用SUBSTRING替代；SQLite自3.38.0起支持。
LEFT 和 RIGHT 函数在不同数据库里的行为差异
MySQL、PostgreSQL（需启用 pg_trgm 或用 substring）、SQL Server 和 SQLite 都支持 LEFT 和 RIGHT，但 PostgreSQL 默认不提供这两个函数——直接写会报错 function left(unknown, integer) does not exist。如果你在 pg 里看到这个错误，不是语法写错了，是根本没这函数。
SQL Server 和 MySQL 行为一致：两个函数都接受字符串和长度两个参数，长度为负数时多数数据库会报错或返回空串，不能像 Python 的切片那样自动截断。
- MySQL：
LEFT('hello', 2)→'he'；RIGHT('world', 3)→'rld' - SQL Server：同上，完全兼容
- PostgreSQL：必须改用
substring(col FROM 1 FOR 2)或substring(col FROM length(col)-2+1)模拟RIGHT - SQLite：支持
LEFT/RIGHT，但只从 3.38.0 版本起才内置，旧版本需自定义函数或用substr
LEFT('abcde', 10) 不报错但返回整串，这是陷阱
很多人以为超长截取会报错或截断失败，实际上所有支持 LEFT/RIGHT 的数据库都会“静默补全”：要取 10 个字符，但原串只有 5 个，就直接返回全部 5 个。这在拼接固定格式字段（比如生成编号前缀）时容易埋雷——你以为截出了 6 位编码，结果某条记录只有 4 位，后续逻辑就错位了。
- 检查是否真截到了预期长度：
LENGTH(LEFT(col, 6)) = 6，否则可能源数据太短 - 想强制补零或空格，得显式处理：
LPAD(LEFT(col, 6), 6, '0')（MySQL）或RIGHT('000000' || col, 6)（通用 trick） - 如果字段允许 NULL，
LEFT(NULL, 3)结果仍是NULL，别忘了加COALESCE
用 RIGHT 取后缀时，别忽略空格和不可见字符
RIGHT 看似简单，但实际常因尾部空格、制表符、换行符导致取错。比如日志字段 'error_404 \n'，你写 RIGHT(log_msg, 3) 得到的是 '\n' 而不是 '404'。
- 先清理再截取：
RIGHT(TRIM(TRAILING FROM log_msg), 3)（PostgreSQL/SQL Server）或RIGHT(RTRIM(log_msg), 3)（SQL Server） - MySQL 用
RIGHT(RTRIM(log_msg), 3)即可，但注意RTRIM不处理 Unicode 空格（如 ），得靠正则替换 - 如果后缀有固定分隔符（如
'file_v2.1.0.zip'想取'zip'），用SUBSTRING_INDEX（MySQL）或SPLIT_PART（PostgreSQL）比RIGHT更可靠
性能提示：LEFT/RIGHT 在 WHERE 中用不好会拖慢查询
对字段套 LEFT(col, 3) = 'ABC' 这种写法，大多数数据库无法走索引（除非建函数索引）。它本质是每行都计算一次左侧子串，数据量大时延迟明显。
- MySQL 8.0+ 支持函数索引：
CREATE INDEX idx_prefix ON tbl ((LEFT(code, 3))) - SQL Server 可建计算列 + 索引：
ALTER TABLE tbl ADD code_prefix AS LEFT(code, 3)，再对code_prefix建索引 - 更轻量的替代：用
col LIKE 'ABC%'，能命中前缀索引，且语义等价 - 如果只是做展示层截断（比如列表只显示前 20 字），优先放在应用层处理，避免数据库额外计算
真正麻烦的从来不是函数怎么写，而是你不知道源数据里混着多少看不见的空白、编码异常、或者长度根本不够。动手前先 SELECT LENGTH(col), DUMP(col)（Oracle）或 HEX(col)（MySQL）看一眼真实字节组成，比反复调参快得多。
