SQL中LEN仅用于SQL Server（忽略尾空格、返回字符数），LENGTH用于MySQL/PostgreSQL/Oracle（默认字节数，含空格）；跨库不可混用，需按数据库类型选择，且中文/emoji等多字节字符须用CHAR_LENGTH()确保字符计数准确。
SQL中LEN和LENGTH函数的区别与选择
不同数据库对字符串长度函数的命名和行为不一致，直接混用会导致语法错误或结果偏差。SQL Server用LEN()，MySQL/PostgreSQL/Oracle用LENGTH()，而且LEN()会自动忽略末尾空格，LENGTH()则计算所有字符（包括空格）。
实际查询前必须先确认所用数据库类型，不能凭经验硬套。比如在MySQL里写LEN(name)会报错Unknown function 'LEN'；反过来在SQL Server里用LENGTH(name)也会失败。
查询字符长度等于某值的数据（含空格处理差异）
当业务要求“字段恰好5个字符”，要注意LEN()和LENGTH()对空格的处理逻辑不同，可能导致漏查或误查。
- SQL Server：
WHERE LEN(name) = 5—— 若name是'abc '（带2个尾部空格），LEN()返回3，不满足条件 - MySQL/PostgreSQL：
WHERE LENGTH(name) = 5—— 同样值'abc '会返回5，被命中 - 若需跨数据库统一语义（比如严格按存储字节数判断），优先用
LENGTH()；若需兼容SQL Server且逻辑上“可视长度”更重要，可改用RTRIM()配合：LEN(RTRIM(name)) = 5
查询长度大于、小于或在区间内的数据
这类范围查询写法简单，但性能容易被忽视：在WHERE子句中对列使用函数（如LENGTH(name) > 10）通常无法走索引，尤其在大表上可能全表扫描。
- MySQL 8.0+ / PostgreSQL 支持函数索引，可建：
CREATE INDEX idx_name_len ON users (LENGTH(name)) - SQL Server 可用计算列+索引：
ALTER TABLE users ADD name_len AS LEN(name)，再对name_len建索引 - 更通用的优化方式是业务层控制输入长度，或用触发器/约束提前拦截超长数据，避免查询时才过滤
中文、emoji等多字节字符的长度陷阱
LENGTH()返回的是**字节数**，不是字符数。UTF-8下中文通常占3字节，emoji可能占4字节，导致LENGTH('好') = 3，而非1。
如果需求是“字符个数≥5”，用LENGTH()会出错，应改用数据库提供的字符计数函数：
- MySQL：用
CHAR_LENGTH()（或CHARACTER_LENGTH()），CHAR_LENGTH('好') = 1 - PostgreSQL：
CHAR_LENGTH()和LENGTH()行为相同，默认按字符计数（取决于配置，但通常如此） - SQL Server：
LEN()本就是按字符计数，无需替换
真正麻烦的是跨库迁移场景——同一句LENGTH()在MySQL里是字节，在PostgreSQL里可能是字符，必须逐库验证。
