MySQL中应使用CHAR_LENGTH()而非LENGTH()判断字符数，因前者按Unicode字符计数（中文、emoji均算1），后者按字节数计算易出错；CHAR_LENGTH(NULL)返回NULL需显式判空，且无法走索引。
MySQL 中用 CHAR_LENGTH() 判断字段长度
MySQL 不认 LENGTH() 作为字符数判断标准——它按字节算，遇到中文或 UTF-8 多字节字符会出错。真正该用的是 CHAR_LENGTH()，它严格按 Unicode 字符个数统计。
- 查
username字段长度超过 10 个字符的记录：SELECT * FROM users WHERE CHAR_LENGTH(username) > 10;
-
CHAR_LENGTH()对 NULL 返回 NULL，不会报错但也不会匹配，需要显式处理：WHERE CHAR_LENGTH(username) > 10 AND username IS NOT NULL
- 如果字段是
TEXT或超长类型，CHAR_LENGTH()依然可靠；但注意索引无法加速这类查询，大数据量时要考虑加生成列+索引
PostgreSQL 里必须用 LENGTH()（不是 CHAR_LENGTH()）
PostgreSQL 的 LENGTH() 就是按字符计数，和 MySQL 的 CHAR_LENGTH() 行为一致。它的 CHAR_LENGTH() 是别名，可用但没必要。
- 查
title超过 50 字符：SELECT * FROM posts WHERE LENGTH(title) > 50;
- PostgreSQL 对空字符串
''返回 0，对 NULL 返回 NULL，逻辑和 MySQL 一致 - 若字段含前导/尾随空格，
LENGTH(TRIM(title)) > 50才是“有效内容”超长，这点容易漏判
SQL Server 需避开 LEN() 的隐式截断陷阱
LEN() 在 SQL Server 中会自动忽略尾部空格，导致长度误判。比如 'abc ' 的 LEN() 是 3，不是 6。要严格按实际存储长度比，得用 DATALENGTH() 再除以字符字节数。
- 查 Unicode 字段（
NVARCHAR）真实字符数超 20：SELECT * FROM products WHERE LEN(name) > 20;
—— 这能用，但仅适用于“不关心尾空格”的场景 - 要包含尾空格的精确字符数，必须用：
WHERE DATALENGTH(name) / 2 > 20
（因为NVARCHAR每字符占 2 字节） - 如果是
VARCHAR字段，DATALENGTH(name) / 1 > 20，但要注意排序规则是否启用 UTF-8（SQL Server 2019+），否则多字节字符仍可能被拆解
跨数据库兼容写法几乎不存在
没有一条 SQL 能在 MySQL、PostgreSQL、SQL Server 上都正确返回“字符长度 > N”。函数名、NULL 处理、空格逻辑、Unicode 支持全都不统一。
- ORM 如 SQLAlchemy 或 Django ORM 会帮你封装，但底层仍是方言适配；手写 SQL 时必须明确目标数据库
- 如果应用需切换数据库，建议把长度校验提到应用层（如 Python 用
len(s)），数据库只存原始值，避免 SQL 层逻辑分裂 - 最易被忽略的是：某些字段定义了
CHECK (CHAR_LENGTH(content) ，但插入时用了 <code>INSERT ... VALUES (SUBSTR(..., 1, 1000))—— 这里SUBSTR在不同库中截取单位也不同，MySQL 是字符，PostgreSQL 是字符，SQL Server 的SUBSTRING却是字节（除非用LEFT()）
