SQL中LEN与LENGTH函数不可混用：LEN仅适用于SQL Server/Sybase，LENGTH用于MySQL/PostgreSQL/Oracle（标准模式）/SQLite；二者语义与行为差异大，跨库需按数据库类型选择，无兼容写法。
SQL里该用LEN还是LENGTH？看数据库类型
不是函数写错了，是根本没对上号——LEN是SQL Server和Sybase的函数，LENGTH才是MySQL、PostgreSQL、Oracle（标准模式）和SQLite认的。用错直接报Invalid column name或Unknown function。
常见错误现象：SELECT LEN('abc') FROM table在MySQL里跑不通；反过来SELECT LENGTH('abc') FROM table在SQL Server 2012之前版本会报错（2012+才支持LENGTH作为别名，但不推荐依赖）。
- SQL Server / Azure SQL：只认
LEN，它自动忽略末尾空格（LEN('a ')返回1） - PostgreSQL / MySQL / SQLite：只认
LENGTH，按字节计数（UTF-8下中文通常占3字节） - Oracle：标准用
LENGTH，但注意它默认按字符计数；若需字节长度得用LENGTHB
LEN在SQL Server里为什么比预期短？空格被吃了
LEN的设计就是去尾随空格后算长度，这是它的行为，不是bug。比如LEN('hello ')返回5，不是8。如果业务逻辑真要包含空格（比如校验固定长度字段填充），就不能靠LEN。
使用场景：判断用户昵称是否为空（LEN(TRIM(name)) = 0）比name = ''更安全，因为能覆盖纯空格输入；但做数据截断或协议对齐时，必须意识到它“吃空格”。
- 要真正统计所有字符（含尾空格）：改用
DATALENGTH（SQL Server），它返回字节数，DATALENGTH('a ')返回3 -
DATALENGTH对Unicode字段（nvarchar）返回的是字节数，不是字符数，一个汉字算2字节 - 跨库兼容写法不存在，别硬套；应用层统一trim后再传长度判断更可控
LENGTH在MySQL和PostgreSQL里为何结果不一样？编码惹的祸
同一个字符串，在MySQL（默认utf8mb4）和PostgreSQL（UTF-8）里LENGTH返回值可能不同，不是函数问题，是字符集配置或客户端连接设置导致的底层字节解释不一致。
典型表现：LENGTH('??')在MySQL里可能是4（utf8mb4中emoji占4字节），在PostgreSQL里也可能是4，但如果数据库初始化用的是SQL_ASCII或连接未声明client_encoding，就可能崩成乱码或报错。
- MySQL：确认
character_set_client、collation_connection和字段定义一致，用SHOW VARIABLES LIKE 'character_set%'查 - PostgreSQL：执行
SHOW client_encoding，确保是UTF8；用OCTET_LENGTH替代LENGTH可强制按字节算，避开字符语义歧义 - 避免在WHERE条件里直接比
LENGTH(col) > 10——如果col有NULL，结果就是NULL，整行过滤掉；加AND col IS NOT NULL
字符串长度判断别只盯函数，先想清楚“长度”指什么
业务说“用户名不能超过10个字符”，这个“字符”是用户感知的字数（如“张三”算2），还是存储占的字节数（UTF-8下“张三”占6字节），还是前端input的maxlength限制（受浏览器渲染影响）？三者经常不等价。
容易被忽略的地方：前端JS用str.length是按UTF-16码元算的，一个emoji可能返回2；后端Java用String.length()同理；而数据库LENGTH按UTF-8字节算。同一串文字，在各层长度值可能分别是2、4、8。
- 最稳妥的做法：在应用层统一用Unicode字符数（如Python的
len(s)、JS的[...s].length），数据库只存、不验长度 - 如果必须数据库侧校验，SQL Server用
LEN+TRIM，PostgreSQL用CHAR_LENGTH（按字符，非字节），MySQL用CHAR_LENGTH（同样按字符） - 别在触发器或CHECK约束里调用长度函数做复杂逻辑——性能差，且不同版本优化器处理方式可能突变
