where column_name is not null 仅排除null，无法过滤空字符串、纯空格或0；需结合trim和比较操作，如and trim(name) != ''，并依据数据库特性选用nullif、coalesce或len等函数统一处理业务“空值”。
WHERE column_name IS NOT NULL 能筛掉 NULL，但筛不掉空字符串
直接写 WHERE name IS NOT NULL 只能排除数据库中真正为 NULL 的记录，对 ''（空字符串）、只含空格的字符串（如 ' '）、或数值型字段中的 0 都无效。这是最常被忽略的第一层陷阱。
实际业务里，用户提交表单后没填内容，后端可能存了空字符串而非 NULL；MySQL 默认也倾向用 '' 代替 NULL 存文本字段。所以单靠 IS NOT NULL 往往漏数据。
- 字符串字段要同时排除
NULL和空值：WHERE name IS NOT NULL AND TRIM(name) != '' - PostgreSQL 可用
NULLIF(TRIM(name), '') IS NOT NULL合并判断 - SQL Server 推荐
WHERE LEN(LTRIM(RTRIM(name))) > 0，因为LEN('')返回 0，且自动忽略尾部空格
NOT (column_name IS NULL) 和 column_name IS NOT NULL 效果一样，但别混用 OR
两者在标准 SQL 中完全等价，执行计划也无差异。但一旦加进复杂条件，比如 WHERE status = 'active' OR name IS NOT NULL，就可能意外拉回大量空字符串记录——因为 OR 只要一边为真整行就通过，和“非空筛选”本意背道而驰。
- 优先用
AND拼接非空条件，确保所有筛选逻辑共同生效 - 避免
WHERE name != '' OR name IS NOT NULL：这会把NULL记录也放进来（NULL != ''结果是UNKNOWN，不满足，但name IS NOT NULL单独为真就让整行通过） - MySQL 8.0+ 支持
COALESCE(name, '') != ''，语义更直白，但注意COALESCE有函数调用开销
索引对 IS NOT NULL 查询是否有效，取决于字段是否允许 NULL
只有当字段定义为 ALLOW NULL（即建表时没加 NOT NULL 约束），B-Tree 索引才会包含 NULL 值的条目，此时 IS NOT NULL 才可能走索引。如果字段本身定义为 NOT NULL，那这个条件就是恒真，优化器大概率直接忽略它，也不触发索引扫描。
- 用
SHOW CREATE TABLE table_name查看字段定义，确认NULL属性 - 如果字段本就不允许 NULL，删掉
IS NOT NULL条件反而更清晰，也避免误导后续维护者 - 对高并发查询，建议在经常用于非空过滤的字段上建函数索引（如 PostgreSQL 的
CREATE INDEX idx_name_trim ON users ((TRIM(name)))），否则TRIM()会导致全表扫描
用 COALESCE 或 CASE 处理混合空值类型更稳妥
当字段可能混着 NULL、''、'unknown'、'N/A' 等业务层面的“无效值”，硬写一堆 AND 条件可读性差还易漏。这时候用 COALESCE 统一转成一个哨兵值，再判断更可控。
例如清洗用户昵称：
WHERE COALESCE(NULLIF(TRIM(nickname), ''), 'MISSING') != 'MISSING'
这段的意思是：先 TRIM，再用 NULLIF 把空字符串转成 NULL，最后 COALESCE 把所有 NULL（原始的和转来的）统一成 'MISSING'，最后排除它。
- 比嵌套
AND (nickname IS NOT NULL AND TRIM(nickname) != '')更易扩展（比如后续加OR nickname = 'N/A'就得改结构） - 注意
COALESCE参数类型需一致，否则可能触发隐式转换，影响索引使用 - SQLite 不支持
NULLIF，得用CASE WHEN TRIM(nickname) = '' THEN NULL ELSE nickname END
NULL，还是应用层约定的任意无效标记。没有统一答案，只有匹配场景的写法。
