sql中len和length函数因数据库而异：sql server用len（忽略尾部空格），mysql/pg用length（统计所有字符）；中文或emoji场景需注意字节与字符区别，跨库应优先应用层适配。
SQL中LEN和LENGTH函数的区别与数据库适配
不同数据库对字符串长度函数的命名和行为不一致，直接混用会导致语法错误。SQL Server用LEN()，MySQL/PostgreSQL用LENGTH()，而且LEN()会自动忽略末尾空格，LENGTH()则统计所有字符（包括空格）。
常见错误现象：LEN('abc ')返回3，而LENGTH('abc ')返回6；在SQL Server里误写LENGTH()会报“无效的列名”或“函数不存在”。
- SQL Server / Azure SQL：必须用
LEN() - MySQL / MariaDB：只认
LENGTH()（CHAR_LENGTH()也可用，但按字符数而非字节数） - PostgreSQL：支持
LENGTH()和CHAR_LENGTH()，两者等价 - SQLite：用
length()（小写，大小写敏感）
查询固定长度字符串的实际写法
核心是把长度函数放在WHERE子句中做条件过滤，注意字段是否为NULL——多数数据库中LEN(NULL)或LENGTH(NULL)结果为NULL，不会匹配任何比较条件，所以无需额外判空，但若业务要求显式排除NULL，需加IS NOT NULL。
示例：查用户名恰好为5个字符的记录
SELECT * FROM users WHERE LEN(username) = 5; -- SQL Server
SELECT * FROM users WHERE LENGTH(username) = 5; -- MySQL / PostgreSQL
- 若字段含前导/尾随空格且业务上认为“abc”和“abc ”长度相同，SQL Server下
LEN()天然满足；MySQL/PG下建议用TRIM()包裹：LENGTH(TRIM(username)) = 5 - 中文或emoji场景要注意：MySQL默认
LENGTH()返回字节数，utf8mb4编码下一个emoji占4字节，此时应改用CHAR_LENGTH()获取真实字符数 - 性能影响：在无索引字段上用函数过滤无法走索引，大数据量时考虑添加计算列+索引（如SQL Server的持久化计算列，MySQL 5.7+的函数索引）
跨数据库兼容的替代方案（不依赖LEN/LENGTH）
当SQL需在多种数据库间复用（如ORM动态生成、共享脚本），硬编码LEN或LENGTH不可行。可用字符串操作间接实现，虽然低效但语法通用。
原理：用SUBSTRING或SUBSTR截取第n+1位，判断是否为空来推断长度是否≥n；再结合LEFT/SUBSTR确认前n位存在且第n+1位不存在。
- 查长度=4的字符串（通用写法，兼容SQL Server/MySQL/PG/SQLite）：
SUBSTR(col, 5, 1) IS NULL AND SUBSTR(col, 4, 1) IS NOT NULL - 缺点明显：无法利用索引、可读性差、逻辑易错（比如没处理NULL）、对超长字段效率极低
- 真正需要跨库时，优先在应用层适配，而不是在SQL里强行统一
容易被忽略的边界情况
实际查数据时，以下几点常导致结果不符预期：
-
LEN('')和LENGTH('')都返回0，但空字符串''和NULL完全不同，二者在GROUP BY或JOIN中行为也不同 - 某些数据库（如旧版SQL Server）对text/ntext类型不支持
LEN()，需先转成varchar(max) - PostgreSQL中
LENGTH(NULL::text)返回NULL，但LENGTH(CAST(NULL AS VARCHAR))也一样——别指望类型转换能绕过NULL问题 - MySQL开启
sql_mode=PAD_CHAR_TO_FULL_LENGTH时，char字段比较会补空格，但LENGTH()仍按实际存储字节数返回，和比较行为不一致
最稳妥的做法是：明确所用数据库类型，查清其文档中长度函数定义，再结合字段实际内容（有无空格、编码、NULL占比）决定是否加TRIM()或CAST。别让“看起来长度对”掩盖了语义差异。
