统计「字符数」该用CHAR_LENGTH()，LENGTH()返回的是「字节数」；中文、emoji等在utf8mb4下占多字节，LENGTH()会高估字符个数，业务校验必须用CHAR_LENGTH()确保与用户感知一致。
MySQL里用LENGTH()还是CHAR_LENGTH()？
直接说结论：统计「字符数」该用CHAR_LENGTH()，LENGTH()返回的是「字节数」。中文、emoji、带重音的字母在UTF8mb4下占多个字节，用LENGTH()会算错——比如LENGTH('好')返回3（UTF8mb4中一个汉字占3字节），但你真正想问的是“这个字段有几个字符”，答案是1。
实操建议：
- 始终优先用
CHAR_LENGTH()做业务逻辑中的长度判断，比如限制用户名最多20个字符 -
LENGTH()只在特定场景有用：估算存储开销、检测是否含多字节字符（如LENGTH(col) > CHAR_LENGTH(col)说明有中文或emoji） - 注意MySQL 8.0+默认字符集是
utf8mb4，旧版本可能用utf8（实际是utf8mb3），但不影响函数语义
SQL Server必须用LEN()，但末尾空格会被忽略
LEN()是SQL Server唯一内置的字符长度函数，但它会自动截掉字符串末尾的空格再计算——这和大多数人的直觉不符。比如LEN('abc ')返回3，不是6。
实操建议：
- 如果必须精确统计含空格的总长度，改用
DATALENGTH()，它返回字节数；对varchar列，DATALENGTH()值等于字符数（因为ASCII字符占1字节），但对nvarchar要除以2（Unicode字符占2字节） - 验证空格敏感逻辑时，别只靠
LEN()，加个RTRIM()对比：LEN(RTRIM(col)) != LEN(col)说明原值末尾有空格 - 迁移MySQL代码到SQL Server时，别直接把
CHAR_LENGTH()替成LEN()，得先确认空格处理是否影响业务
PostgreSQL统一用LENGTH()，没歧义
PostgreSQL的LENGTH()明确按「字符」计数，不区分字节，也不吃掉空格，行为最符合直觉。不管是英文、中文、emoji还是组合字符（如带声调的é），都算作1个字符。
实操建议：
- 放心用
LENGTH()做校验，比如WHERE LENGTH(name) > 50 - 不需要额外处理空格，
LENGTH('a ')就是3 - 如果真需要字节数（例如对接某些二进制协议），用
OCTET_LENGTH()，它等价于MySQL的LENGTH()
跨数据库写法怎么兼容？
没有标准SQL函数能一统天下。CHAR_LENGTH()是SQL标准函数，在MySQL、PostgreSQL、SQL Server（2012+）、Oracle都支持，但SQL Server早期版本（2008及更早）不认它。
实操建议：
- 新项目优先用
CHAR_LENGTH()，覆盖主流现代版本 - 维护老SQL Server系统时，用
LEN()但补上空格处理：LEN(RTRIM(LTRIM(col)))避免首尾空格干扰 - ORM或查询构建器（如Django ORM、Knex.js）通常封装了方言差异，查文档确认它生成的是
CHAR_LENGTH()还是LEN()，别假设一致
字符集、空格、多字节编码——这三个点任何一个没对齐，长度就可能算错。尤其当字段存用户昵称或国际化文本时，别只在测试数据上验证一次就放过。
