sql server用len()，mysql/postgresql用length()；len()忽略尾部空格，length()统计所有字符；跨库需按数据库类型选函数，且注意字节长度与字符长度区别。
SQL里用LEN还是LENGTH？先看数据库类型
不同数据库对字符串长度函数的命名和行为不一致，硬套会报错。SQL Server 用 LEN()，MySQL / PostgreSQL / Oracle 用 LENGTH()，而且 LEN() 在 SQL Server 中默认忽略尾部空格，LENGTH() 则统计所有字符（包括空格）。
- 如果你在 MySQL 或 PostgreSQL 里写
LEN(name)，直接报错：Unknown function 'LEN' - 如果你在 SQL Server 里写
LENGTH(name)，同样报错：Invalid column name 'LENGTH' - 更隐蔽的问题：SQL Server 的
LEN('abc ')返回 3，而DATALENGTH('abc ')才返回 6 —— 如果你本意是校验字段总字节数（比如防止超长 UTF-8 编码），就得换用DATALENGTH()
过滤手机号、身份证号这类固定长度字段
这类字段长度异常基本等于数据错误，适合用 WHERE + 长度函数直接筛掉。但要注意空值和不可见字符干扰。
-
NULL值传给LEN()或LENGTH()都返回NULL，而NULL != 11，所以WHERE LENGTH(phone) != 11会漏掉空值；必须显式加IS NULL判断 - 实际数据可能含空格、短横线、括号，比如
'138-1234-5678'或' (138) 12345678 '，直接算长度没意义，得先清洗 - 推荐写法（以 MySQL 为例）：
WHERE LENGTH(TRIM(REPLACE(REPLACE(phone, '-', ''), ' ', ''))) != 11
- SQL Server 用户注意：
TRIM()在 2016+ 才支持，旧版本得用RTRIM(LTRIM(...))
处理变长字段时，别只设“上限”，要结合业务定“合理区间”
比如用户昵称，限制 2–20 字符比单纯 LENGTH(nickname) 更靠谱：
-
LENGTH(nickname) = 0很可能是导入时字段为空或全空格，该剔除 -
LENGTH(nickname) = 1可能是误填的单个标点（如'.'）或控制字符，建议结合正则进一步判断（MySQL 8.0+ 支持REGEXP_LIKE(nickname, '^[a-zA-Z0-9\u4e00-\u9fa5]{2,20}$')） - PostgreSQL 用户可直接用
~操作符：WHERE nickname !~ '^[a-zA-Z0-9\u4e00-\u9fa5]{2,20}$' - 注意：UTF-8 下中文字符占 3 字节，
LENGTH()返回的是字节数，不是字符数；PostgreSQL 的CHAR_LENGTH()或 MySQL 的CHAR_LENGTH()才对应“几个汉字”，别混用
性能敏感场景下，避免在 WHERE 中对字段反复计算
如果表有千万级数据，每次查询都算 LENGTH(content) 可能拖慢执行计划，尤其当该字段没索引时。
- 不要写
WHERE LENGTH(content) > 1000 AND LENGTH(content) —— 算两次 - 改成一次计算：
WHERE LENGTH(content) BETWEEN 1001 AND 4999
- 更彻底的优化：建生成列（MySQL 5.7+/PostgreSQL 12+）或计算列（SQL Server），再在上面建索引。例如 SQL Server：
ALTER TABLE logs ADD content_len AS LEN(content) PERSISTED;<br>CREATE INDEX IX_logs_content_len ON logs(content_len);
- 注意
PERSISTED是关键，否则索引无法建立在计算列表达式上
真正麻烦的不是函数名选错，而是没意识到「长度」本身在不同上下文里指代不同东西：字节？字符？可视字符？是否含 BOM？这些细节一旦忽略，过滤出来的“干净数据”可能照样进不了下游系统。
