LENGTH函数返回字节数而非字符数，在MySQL中处理中文、emoji等多字节字符时易误判，应改用CHAR_LENGTH()获取真实字符数。
LENGTH 函数返回的是字节数，不是字符数
在 MySQL 中，LENGTH() 统计的是字符串所占的字节数，不是 Unicode 字符个数。这对中文、emoji 或 UTF8MB4 字符特别关键——比如一个中文汉字在 utf8mb4 编码下占 3 或 4 字节，LENGTH('你好') 返回 6（utf8）或 8（utf8mb4），而不是 2。
常见错误现象：WHERE LENGTH(name) > 10 本想筛出“超过 10 个字符”的名字，结果实际筛出的是“超过 10 字节”的数据，导致短中文名也被误过滤。
- 用
CHAR_LENGTH()替代LENGTH()来获取真实字符数 - 确认数据库字符集：执行
SHOW VARIABLES LIKE 'character_set_database';，避免在 latin1 下误用 UTF8 字符 - 如果必须用
LENGTH()（例如计算存储开销），记得搭配CONVERT(... USING utf8mb4)统一编码再算
PostgreSQL 和 SQL Server 不支持 LENGTH，要用对应函数
SQL 标准里没有强制要求 LENGTH()，各数据库实现不一致。PostgreSQL 用 LENGTH()，但它是字符长度（等价于 MySQL 的 CHAR_LENGTH()）；SQL Server 完全不用这个函数，得写 LEN()。
跨库迁移时硬写 LENGTH() 会直接报错：ERROR: function length(unknown) does not exist（PostgreSQL）或 Invalid column name 'LENGTH'（SQL Server）。
- MySQL / PostgreSQL：优先用
CHAR_LENGTH()（MySQL）或LENGTH()（PostgreSQL），语义统一为字符数 - SQL Server：只能用
LEN()，注意它会自动忽略末尾空格（LEN('abc ')→ 3） - SQLite：支持
LENGTH()，行为同 PostgreSQL，按字符计数
NULL 值会让 LENGTH 返回 NULL，不是 0
LENGTH(NULL) 结果是 NULL，不是 0。这在聚合或条件判断中容易引发逻辑断裂——比如 WHERE LENGTH(title) > 0 会漏掉所有 title 为 NULL 的行，但你可能想把它们也归为“空”来处理。
典型场景：导出报表时要标记“标题缺失”，但只写了 CASE WHEN LENGTH(title) = 0 THEN 'empty' ELSE 'ok' END，结果 NULL 标题全进了 ELSE 分支。
- 显式处理空值：
CASE WHEN title IS NULL OR CHAR_LENGTH(title) = 0 THEN 'empty' ELSE 'ok' END - 想把 NULL 当 0 算，可用
COALESCE(CHAR_LENGTH(title), 0) - 避免在索引字段上直接套
LENGTH()做 WHERE 条件，会导致索引失效
性能影响：LENGTH 在 WHERE 或 ORDER BY 中可能导致全表扫描
对字段套 LENGTH(title) 做筛选（如 WHERE LENGTH(title) > 20）时，MySQL 无法使用 title 上的普通 B-Tree 索引，因为函数改变了原始值的有序性。
实测：100 万行表，WHERE title LIKE 'a%' 走索引，耗时 0.02s；WHERE LENGTH(title) > 20 变成全表扫描，耗时 1.8s。
- 高频查询需要按长度筛选时，加生成列 + 索引：
ALTER TABLE posts ADD COLUMN title_len TINYINT AS (CHAR_LENGTH(title)) STORED，再建索引INDEX idx_title_len (title_len) - 避免在 JOIN 条件里用
LENGTH()，尤其是大表关联 - 如果只是校验导入数据是否超长，用应用层截断比 SQL 层判断更可控
LENGTH() 很快就会从“简单统计工具”变成“线上慢查元凶”。 
