不同数据库对字符串长度函数的处理方式，确实是个容易踩坑的地方。SQL Server 里用的是 LEN()，而 MySQL、PostgreSQL 和 Oracle 则统一用 LENGTH()。问题还不止命名差异——行为上也有细微区别：LEN() 在 SQL Server 中默认忽略尾部空格，LENGTH() 则是老老实实把所有字符都算进去，包括末尾的空格。
从实际遇到的错误来看，最常见的就是跨数据库环境迁移代码时忘了替换函数名。在 MySQL 里写 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() 函数要到 SQL Server 2016 才支持，旧版本只能用 RTRIM(LTRIM(...)) 组合拳。
变长字段不要只设上限，要结合业务定“合理区间”
拿用户昵称举个例子：限制 2–20 个字符比单纯 LENGTH(nickname) <= 20 靠谱得多。为什么这么说？
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() 在 MySQL 中默认返回的是字节数而不是字符数。如果想按字符数（也就是汉字的个数）来判断，得用 CHAR_LENGTH()。PostgreSQL 也一样，CHAR_LENGTH() 才是你想用的那个。千万别混用。
性能敏感场景下，避免在 WHERE 中对字段反复计算
如果表里有千万级数据，每次查询都算一遍 LENGTH(content)，执行计划会被拖得很慢，特别是当这个字段没有索引的时候。
- 别写
WHERE LENGTH(content) > 1000 AND LENGTH(content) < 5000，这种写法会让数据库算两次长度。改成：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; CREATE INDEX IX_logs_content_len ON logs(content_len);
注意PERSISTED是关键，否则索引无法建立在计算列表达式上。
话说回来，真正麻烦的事往往不是函数名选错，而是没有意识到“长度”在不同上下文里指代的东西可能完全不同：是字节长度？字符长度？还是可视字符的长度？有没有包含 BOM？这些细节一旦忽略，你以为筛出来的“干净数据”，很可能照样进不了下游系统。
