应根据数据库类型选择：SQL Server用LEN()（忽略尾空格），MySQL/PostgreSQL等用LENGTH()；中文或emoji场景需用CHAR_LENGTH()（MySQL）或OCTET_LENGTH()（PG）区分字符数与字节数。
SQL里该用 LEN 还是 LENGTH？看数据库类型
不是所有数据库都支持 LEN，也不是所有都支持 LENGTH。选错函数会直接报错，比如在 PostgreSQL 里写 LEN('abc') 就提示“function len(unknown) does not exist”。
- SQL Server、Sybase：只认
LEN()（自动忽略末尾空格） - PostgreSQL、MySQL（8.0+）、SQLite、Oracle：只认
LENGTH() - MySQL（5.7 及更早）：
LENGTH()返回字节长度，CHAR_LENGTH()才返回字符数（对 UTF-8 中文很重要）
中文或 emoji 字符下 LENGTH() 返回值不对？查清楚是字节还是字符
LENGTH() 在不同数据库里语义不一致，尤其处理多字节字符时容易误判。例如 LENGTH('你好') 在 MySQL 5.7 返回 6（UTF-8 占 3 字节/字符），但你实际想数的是“2 个字符”。
- MySQL：优先用
CHAR_LENGTH()获取字符数，LENGTH()仅用于调试编码或计算存储开销 - PostgreSQL：
LENGTH()默认按字符计数，OCTET_LENGTH()才是字节数 - SQL Server：
LEN()按字符计，但会截掉字符串末尾所有空格再算——LEN('abc ')结果是 3
WHERE 条件里用 LEN/LENGTH 做过滤，性能可能很差
在 WHERE 子句里对字段套 LEN(name) > 10 这类函数调用，基本会让索引失效，尤其是大表扫描时延迟明显。
- 能用约束替代就别 runtime 算：比如建表时加
CHECK (CHAR_LENGTH(name) - 真要查长度范围，考虑冗余一个
name_length INT字段，写入时用触发器或应用层同步更新 - SQL Server 若必须用
LEN()过滤，注意它不走索引；PostgreSQL 可建函数索引：CREATE INDEX idx_name_len ON users ((LENGTH(name)))
NULL 值传给 LEN 或 LENGTH 会返回 NULL，不是 0
这是最容易漏掉的逻辑坑：如果字段允许为 NULL，LENGTH(column) 结果也是 NULL，导致 WHERE LENGTH(column) > 5 会跳过所有 NULL 行——这通常符合预期，但若你本意是“非空且长度 > 5”，就得显式判断：
- 写成
WHERE column IS NOT NULL AND LENGTH(column) > 5 - 或者用
COALESCE(LENGTH(column), 0) > 5（注意：这会让索引失效） - SQL Server 的
LEN(NULL)同样返回 NULL，行为一致
字符长度计算看着简单，但跨库兼容、NULL 处理、性能影响和中英文混排下的字节/字符混淆，每个点都可能在线上查出意外结果。
