LEFT和RIGHT函数在SQL Server、MySQL 8.0+中原生支持；PostgreSQL需用SUBSTRING模拟，Oracle和SQLite不支持，必须用SUBSTR或SUBSTRING配合LENGTH实现兼容。
LEFT 和 RIGHT 函数在哪些数据库里能用
LEFT 和 RIGHT 是 SQL Server、MySQL（8.0+）、PostgreSQL（通过 pg_catalog 扩展或自定义函数，原生不支持）、SQLite（需启用扩展）中较常见的字符串截取函数。但注意：标准 SQL 不定义这两个函数，所以 PostgreSQL 原生只有 SUBSTRING，Oracle 完全不支持 LEFT/RIGHT，必须用 SUBSTR 配合 LENGTH 模拟。
常见错误现象：ERROR: function left(unknown, integer) does not exist —— 这基本是 PostgreSQL 或旧版 MySQL 报的错。
- SQL Server：原生支持，语法最直白
- MySQL 5.7 及以前：不支持
LEFT/RIGHT，得用SUBSTRING(col, 1, n)和SUBSTRING(col, -n) - MySQL 8.0+：
LEFT(col, 3)等价于SUBSTRING(col, 1, 3)；RIGHT(col, 2)等价于SUBSTRING(col, -2) - PostgreSQL：必须写成
SUBSTRING(col FROM 1 FOR 4)（左截）或SUBSTRING(col FROM LENGTH(col)-2 + 1)（右截）
LEFT(col, n) 截左边时 n 超长会怎样
当 n 大于字段实际长度时，LEFT 不报错，而是直接返回完整字符串 —— 这是安全行为，但容易掩盖逻辑误判。
比如：LEFT('abc', 10) 返回 'abc'，不是 NULL 或报错。这在拼接前缀（如提取文件名前 5 位）时看似省心，但若业务要求“必须截出 5 位且不足则补空格”，就得额外加 CASE WHEN LENGTH(col) 。
- n 为负数：SQL Server 报错；MySQL 返回空字符串；PostgreSQL 不适用（无原生 LEFT）
- n 为 0：所有支持平台都返回空字符串
'' - col 为 NULL：结果恒为 NULL，不会触发隐式转换
RIGHT(col, n) 提取后缀的实际陷阱
RIGHT 看似简单，但对含多字节字符（如中文、emoji）或尾部空格的字段极易出错。例如：RIGHT('测试 ', 3) 在 MySQL 中返回 '试 '（含一个空格），而不是预期的 '测试 ' —— 因为它按字节算长度，而 UTF-8 下中文占 3 字节，“测试 ”共 7 字节，RIGHT(..., 3) 就只取最后 3 字节，可能切在中文中间导致乱码。
解决方案取决于数据库：
- MySQL：确保连接和字段用
utf8mb4排序规则，并改用SUBSTRING(col, -n)（它按字符计数） - SQL Server：默认按字符处理，但若列是
varchar且排序规则为 Latin1，仍可能误判 Unicode；推荐显式用N'测试 '和nvarchar类型 - 通用稳妥法：用
REVERSE(LEFT(REVERSE(col), n))，虽稍慢但跨平台语义一致
替代方案：为什么有时 SUBSTRING 更可靠
当需要动态边界（比如“取域名中最后一个点之后的部分”），LEFT/RIGHT 无法直接满足，必须结合 CHARINDEX（SQL Server）、LOCATE（MySQL）或 POSITION（PostgreSQL）来算位置，这时直接上 SUBSTRING 更清晰。
示例（SQL Server）：取邮箱 @ 后的域名
SUBSTRING(email, CHARINDEX('@', email) + 1, LEN(email))
这个写法比先 RIGHT 再找 @ 位置更直观，也避免了 RIGHT 对变长分隔符的硬编码风险。
真正容易被忽略的是：不同数据库对空格的 trim 行为不一致 —— RIGHT('abc ', 5) 在 SQL Server 中返回 'bc '（保留尾空格），而某些 ORM 或客户端可能自动 trim，导致肉眼难排查的匹配失败。
