PostgreSQL原生不支持LEFT/RIGHT，需用SUBSTRING模拟；SQL Server 2017+、MySQL 5.7+支持；参数为非负整数，负数报错，0返回空串，超长则全返，NULL输入返回NULL；Unicode按字符计；WHERE中使用会失索引，推荐LIKE前缀匹配。
LEFT 和 RIGHT 函数在不同数据库中的行为差异
MySQL、SQL Server、PostgreSQL（需扩展）、SQLite 都支持 LEFT 和 RIGHT，但 PostgreSQL 原生不支持，得用 SUBSTRING 模拟；SQL Server 从 2017 开始才支持 RIGHT（之前可用），而 MySQL 5.7+ 全支持。如果你在 PostgreSQL 里直接写 RIGHT(col, 3)，会报错 ERROR: function right(unknown, integer) does not exist。
实际使用前先确认数据库类型和版本，别一上来就抄示例——尤其跨团队协作时，DDL 或迁移脚本里混用会直接失败。
提取固定长度字符的典型写法与边界情况
LEFT 和 RIGHT 的第二个参数是长度，必须是非负整数。传负数会报错（如 MySQL 报 Invalid argument for function left）；传 0 返回空字符串；超过源字段长度时，不会报错，而是返回整个字段值。
-
LEFT('abc', 5)→'abc'（安全截断，不是错误） -
RIGHT('xyz', 10)→'xyz' -
LEFT(NULL, 2)→ 结果为NULL（注意空值传播） - 若字段含 Unicode 多字节字符（如中文、emoji），
LEFT按字符数计，不是字节数（MySQL 8.0+ utf8mb4 下如此；旧版可能有歧义）
替代方案：当 LEFT/RIGHT 不可用或需兼容时怎么写
PostgreSQL 或某些老 Oracle 环境下，用 SUBSTRING 最稳妥：
SELECT SUBSTRING(col FROM 1 FOR 4) AS prefix FROM t; -- 等效 LEFT(col, 4) SELECT SUBSTRING(col FROM LENGTH(col) - 2 + 1) AS suffix FROM t; -- 等效 RIGHT(col, 3)
注意 SUBSTRING(... FROM start FOR len) 是标准 SQL 写法，兼容性比 LEFT/RIGHT 高；但 RIGHT 的等效写法稍绕，容易漏掉 +1 导致偏移错误——比如 LENGTH(col) - 2 实际取的是倒数第 3 个字符起的位置。
性能与索引友好性提醒
LEFT(col, n) 在 WHERE 条件中（如 WHERE LEFT(name, 2) = 'Li'）通常无法走索引，因为它是函数操作。想高效匹配前缀，应改用 col LIKE 'Li%' —— 这样 B-tree 索引能生效。
同理，RIGHT(col, 3) 无法利用常规索引，除非你建了函数索引（如 PostgreSQL 的 CREATE INDEX idx_suffix ON t ((RIGHT(col, 3)))），但多数 OLTP 场景没必要为后缀单独建索引。
真正要小心的是字段为空或超短时的逻辑一致性：比如 RIGHT(phone, 4) 取后四位，但 phone 是空字符串或只有两位，结果就是那两位——业务上是否允许？这类隐式截断常被测试忽略。
