len函数在sql server中明确设计为忽略尾随空格后计数，返回有效字符数而非实际存储长度，例如len('abc ')返回3；其行为源于ansi sql-92标准的尾部空格语义等价性，与datalength（返回字节数）本质不同，且不具跨数据库兼容性。
LEN函数在SQL Server中自动忽略尾随空格
这是最常被误用的点：LEN不是“算错了”，而是明确设计为排除尾随空格后计数。比如 LEN('abc ') 返回 3，不是 6。它只统计“有效字符数”，不反映实际存储长度。如果你正做字段长度校验、协议对齐或数据迁移，这个行为会直接导致逻辑偏差——你以为截断了10个字符，实际可能多留了3个空格。
用LEN做字符串相等性判断会失效
SQL Server中，'a' = 'a ' 判定为 True，LEN('a') = LEN('a ') 也返回 True（都是1），看起来双重保险，实则完全没防住空格差异。真正要判断“字面完全一致”，必须组合 DATALENGTH：'a' = 'a ' AND DATALENGTH('a') = DATALENGTH('a ') 才能区分。否则 WHERE 条件里靠 LEN(col) > 5 过滤，可能把末尾带空格的合法数据意外放过。
跨数据库时LEN根本不可用
LEN 是 SQL Server / Azure SQL 专属函数。在 MySQL、PostgreSQL、SQLite 或 Oracle（标准模式）里直接写 LEN('x') 会报 Unknown function 或 Invalid column name。它们只认 LENGTH，且语义不同：MySQL 的 LENGTH 按字节算（UTF-8 下中文占3字节），PostgreSQL 的 LENGTH 默认按字符算，Oracle 还得区分 LENGTH 和 LENGTHB。没有跨库兼容的写法，硬套只会让查询在某个环境崩掉。
NULL 和编码会让LEN行为更难预测
当列值为 NULL 时，LEN(col) 直接返回 NULL，放进 WHERE 条件如 LEN(name) > 0 会导致整行被过滤（因为 NULL > 0 是未知）。必须显式加 AND name IS NOT NULL。另外，如果字段是 nvarchar，LEN 返回字符数，但 DATALENGTH 返回字节数（一个汉字=2字节），而客户端连接编码没设对时，DATALENGTH 的结果可能和你预期的字节数对不上——这点在导出固定宽文本或对接老系统时特别致命。
