安全过滤非空字符串需TRIM+IS NOT NULL+长度判断三步：先TRIM去空白，再IS NOT NULL排除NULL，最后CHAR_LENGTH>0确保有可见字符；否则NULL、空格、emoji等均易漏判。
WHERE column != '' 为什么不能单独用
因为 NULL != '' 返回的是 UNKNOWN，不是 TRUE，所以整行被 WHERE 自动排除——你查不到 NULL 值的记录，但它们确实存在。更隐蔽的是，' '（空格）、'\t'、'\n' 这类纯空白字符，!= '' 依然判定为“非空”，结果被错误放行。
常见错误现象：
- 前端显示“无数据”，但数据库里明明有几十条 NULL 或全空格的记录
- 导出报表时字段看着有内容，实际是 3 个空格，后续清洗失败
LENGTH(column) > 0 为什么也不够健壮
LENGTH() 对 NULL 返回 NULL，而 NULL > 0 仍是 UNKNOWN，该行照样不出现——这看似“过滤掉了 NULL”，但语义模糊：你是想排除 NULL，还是只是碰巧它没出来？而且不同库对空格处理不一致：
- SQL Server 的
LEN()自动 rtrim，LEN('abc ')= 3 - MySQL 的
LENGTH()算字节，LENGTH('??')= 4（utf8mb4 下一个 emoji 占 4 字节） - PostgreSQL 的
LENGTH()按字符计，但LENGTH(NULL)直接让整行失效，需配合COALESCE
真正安全的写法：TRIM + IS NOT NULL + 长度判断
三步缺一不可，顺序也有讲究：先去空白，再确认非空，最后看长度。否则 TRIM(NULL) 还是 NULL，LENGTH(TRIM(NULL)) 还是 NULL。
推荐组合（以 MySQL/PG 为例）：
WHERE column IS NOT NULL AND TRIM(column) != '' AND CHAR_LENGTH(TRIM(column)) > 0- 若只需“至少一个可见字符”，可简化为：
WHERE TRIM(column) != ''（因为''是唯一能通过TRIM()变成空串的非-NULL 输入） - PostgreSQL 用户可用更紧凑写法：
WHERE NULLIF(TRIM(column), '') IS NOT NULL
索引和性能必须手动兜底
只要 WHERE 里出现 TRIM() 或 CHAR_LENGTH()，原生索引基本失效。千万级表上直接跑会变慢十倍以上。
可行解法：
- 加计算列并建索引（MySQL 5.7+）：
ALTER TABLE users ADD COLUMN username_clean VARCHAR(255) AS (TRIM(username)) STORED，再在username_clean上建索引 - 业务写入时就存清洗后长度：
INSERT INTO users (username, username_len) VALUES (' abc ', CHAR_LENGTH(TRIM(' abc '))) - 临时应急：用前缀匹配缩小范围，比如
WHERE username LIKE '_%'（至少一个非空字符），再套函数二次过滤
最常被忽略的一点：你写的那个“看起来很全”的条件，可能在测试环境跑得飞快，但上线后面对真实脏数据（NULL、BOM 字符、零宽空格、emoji）立刻漏判——别依赖单一层级过滤。
