where子句中不能直接写length > 10，必须显式调用对应数据库的长度函数：mysql和postgresql用length(column)（后者按字符计），sql server用len(column)，sqlite用length(column)；且length()在mysql中返回字节数，需用char_length()按字符过滤。
WHERE子句里不能直接用 length > 10
SQL里没有全局统一的字符串长度函数，length 这种写法在 MySQL 里能跑，但在 PostgreSQL 或 SQL Server 上会报错或返回意外结果。比如 PostgreSQL 要用 LENGTH()（大写），SQL Server 用 LEN()，SQLite 用 length()（小写）。写成 length > 10 实际上是在比较字段名本身，不是调用函数——这会导致语法错误或全表误匹配。
不同数据库的长度函数写法必须严格区分
实际过滤时，得按目标数据库选对函数，并显式调用：
- MySQL：
WHERE LENGTH(column_name) > 10 - PostgreSQL：
WHERE LENGTH(column_name) > 10（注意：函数名大写，且对 Unicode 安全） - SQL Server：
WHERE LEN(column_name) > 10（LEN()会忽略末尾空格，如需精确字节长度改用DATALENGTH()） - SQLite：
WHERE length(column_name) > 10（小写，支持 UTF-8 字符）
别依赖 ORM 自动生成的 SQL——很多 ORM（如 Django 的 __len__gt）底层仍可能生成不兼容语句，建议手写 WHERE 条件并验证执行计划。
WHERE 中用 LENGTH() 可能导致索引失效
如果字段上有索引，但 WHERE 条件是 LENGTH(title) > 10，大多数数据库无法走索引扫描，会退化为全表扫描。尤其在千万级表上，响应时间可能从毫秒跳到秒级。
- 优化思路：加计算列 + 索引（如 MySQL 5.7+ 支持持久化计算列：
ALTER TABLE t ADD COLUMN title_len TINYINT AS (LENGTH(title)) STORED，再建索引INDEX idx_title_len (title_len)） - 替代方案：业务层控制——插入时就存长度值，查询直接用
WHERE title_len > 10 - 临时应急：用前缀匹配缩小范围，比如先
WHERE column_name LIKE '___________%'（11 个下划线），再套LENGTH()过滤（仅适用于 ASCII 主导场景）
空值和空白字符容易被忽略
LENGTH(NULL) 返回 NULL，而 NULL > 10 结果是 unknown，该行不会出现在结果集中——这符合三值逻辑，但常被误认为“没数据”。更麻烦的是，' '（纯空格）在某些数据库中 LENGTH() 返回 3，LEN() 返回 0（SQL Server 默认 trim）。
- 安全写法：显式排除空值和空白，例如
WHERE column_name IS NOT NULL AND TRIM(column_name) != '' AND LENGTH(column_name) > 10 - PostgreSQL 推荐用
NULLIF(TRIM(column_name), '')配合LENGTH()，避免空格干扰 - 测试时务必用真实数据验证：插入
NULL、' '、'x'、'0123456789a'四种值，看是否只返回最后一个
字符集和排序规则也会影响长度判断，特别是 MySQL 的 utf8mb4 下 emoji 占 4 字节，但 LENGTH() 返回字节数而非字符数——要按“字符数”过滤就得换用 CHAR_LENGTH()。
