MySQL用LENGTH()返回字节长度，中文UTF8mb4下占3-4字节；需字符数用CHAR_LENGTH()；SQL Server用LEN()忽略尾部空格，查字节用DATALENGTH()；PostgreSQL LENGTH()返回字符数，字节用OCTET_LENGTH()；跨库无通用函数，应用层校验更可靠。
MySQL里用LENGTH()，不是LEN()
MySQL不支持LEN()函数，直接写会报错：FUNCTION LEN does not exist。必须用LENGTH()——它返回的是**字节长度**，不是字符数。比如中文在UTF8mb4下占3或4个字节，LENGTH('你好')返回6（每个汉字3字节），而非2。
常见误用场景：想统计用户名字符数做校验，却用LENGTH()判断是否超10个汉字，结果实际只存了3个字就触发截断。
- 要按字符数统计，改用
CHAR_LENGTH()（MySQL 4.1+全支持） -
LENGTH()适合判断存储开销、二进制数据长度或ASCII纯文本 - 建表时若字段定义为
VARCHAR(10)，指的是10个字符，不是10字节，校验逻辑应与之对齐
SQL Server必须用LEN()，LENGTH()会报错
SQL Server只认LEN()，且它**自动忽略尾部空格**。例如LEN('abc ')返回3，不是6。这点和MySQL的CHAR_LENGTH()行为不同（后者保留空格）。
典型坑点：比对用户输入前后是否加了空格用于绕过校验，用LEN()就发现不了。
- 需要包含尾部空格的长度，改用
DATALENGTH()（返回字节数，注意Unicode字符占2字节） -
LEN(N'测试')返回2，但DATALENGTH(N'测试')返回4（nchar/nvarchar按UTF-16存） - WHERE条件中用
LEN(col) = 5可能漏掉带空格的合法值，需结合RTRIM()显式处理
PostgreSQL统一用LENGTH()，但参数类型敏感
PostgreSQL的LENGTH()接受text、bytea甚至数组，但不支持直接传integer或boolean。传数字会报错：function length(integer) does not exist。
最常踩的坑是拼接字符串后忘记类型转换：
SELECT LENGTH('id:' || id) FROM users;
如果id是整型，PostgreSQL会尝试隐式转text，多数情况成功；但遇到自定义类型或严格模式就失败。
- 稳妥写法：显式转
CAST(id AS TEXT)或id::TEXT -
LENGTH()在PG中返回字符数（不是字节），对emoji、中文均准确 - 想查字节长度？用
OCTET_LENGTH()，比如OCTET_LENGTH('??')返回4（UTF-8编码下）
跨数据库可移植写法几乎不存在
没有SQL标准强制规定字符串长度函数名，ANSI SQL里连LENGTH都只是可选特性。所谓“通用方案”本质是妥协：
- Django ORM用
.annotate(len=Length('field'))，底层按方言自动映射——但你手写原生SQL时没法靠它 - 用
CASE WHEN @@version LIKE 'Microsoft%' THEN LEN(...) ELSE ... END硬判断？维护成本高，且无法覆盖所有版本分支 - 真正稳定的解法：在应用层做长度校验（如Python用
len(s)），数据库只负责存，不依赖函数做业务逻辑
别指望一个函数名打遍天下，先确认执行环境再选函数，比找“通用写法”实在得多。
