mysql中必须用length()而非len()，因len()不被支持；length()返回字节长度，char_length()才返回字符数，跨数据库函数语义不同，中文和emoji场景下易出错，应优先使用对应数据库的字符数函数并确保字符集正确。
MySQL里用LENGTH()而不是LEN()
MySQL不支持LEN()，这个函数是SQL Server和某些旧版Access的写法。直接写LEN('abc')会报错：ERROR 1305 (42000): FUNCTION db.LEN does not exist。必须用LENGTH()——它返回的是字节长度，不是字符数。比如LENGTH('你好')在UTF8mb4下返回4（每个汉字占3字节？不，MySQL中utf8mb4下汉字通常是3字节，但LENGTH()按实际存储字节数算，常见为6），而CHAR_LENGTH()才返回字符个数2。
PostgreSQL和SQL Server的函数名差异很关键
PostgreSQL用LENGTH()（返回字符数），SQL Server用LEN()（也返回字符数，但会自动忽略末尾空格）。这意味着同样字符串'abc '（带一个空格）：在SQL Server中LEN('abc ')返回3；在PostgreSQL中LENGTH('abc ')返回4；在MySQL中LENGTH('abc ')也返回4，但CHAR_LENGTH('abc ')才是4——LENGTH()在MySQL里永远是字节计数，这点极易混淆。
跨数据库可移植写法几乎不存在
如果代码要兼容多个数据库，别指望一个函数通吃。常见应对方式有：
- 应用层统一处理：读出字符串后用Python/Java等语言调
len()或.length() - 建视图时封装：比如在MySQL里定义
CREATE VIEW v_table AS SELECT ..., CHAR_LENGTH(name) AS name_len FROM t - 避免依赖长度做业务逻辑：比如用
LIKE 'a%'代替LENGTH(col) > 0判断非空
硬写COALESCE(LEN(col), LENGTH(col), CHAR_LENGTH(col))不仅无效，还会因语法错误直接失败。
中文、emoji场景下LENGTH()最容易踩坑
MySQL中LENGTH()对emoji尤其危险。比如插入''（U+1F600），在utf8mb4下占4字节，LENGTH()返回4，但CHAR_LENGTH()返回1。如果用LENGTH()校验“昵称不能超过10个字符”，用户输一个emoji就占掉4个“额度”，体验极差。生产环境涉及多语言或富文本字段，务必优先用CHAR_LENGTH()（MySQL）、LENGTH()（PostgreSQL）、LEN()（SQL Server），并确认字段字符集配置正确。
字符集没设对，比如把utf8mb4列误建为utf8（即utf8mb3），连emoji都存不进去，更别说长度统计了。
