17370845950

MySQL中NULL不能用=或!=判断，须用IS NULL；算术运算结果为NULL；GROUP BY/ORDER BY视所有NULL为相同值；优先用标准COALESCE而非MySQL专属IFNULL；建表应设NOT NULL与DEFAULT，并清理脏数据后再加约束。

MySQL 中 NULL 值的常见误判场景

直接用 = NULL 或 != NULL 判断必然失败，因为 NULL 在 SQL 中不参与任何等值比较，结果恒为 UNKNOWN（不是 TRUE 也不是 FALSE）。这是新手最常踩的坑，比如 WHERE status = NULL 永远查不到数据。

• 必须用 IS NULL 或 IS NOT NULL 显式判断
• NULL 与任意值做算术运算（如 price + NULL）结果仍是 NULL
• GROUP BY 和 ORDER BY 中，所有 NULL 被视为“相同值”，会归到同一组或排在一起（但具体顺序依赖 MySQL 版本和排序规则）

COALESCE 和 IFNULL 的实际选用差异

两者都用于提供 NULL 的替代值，但行为和兼容性不同。优先选 COALESCE()，它是标准 SQL 函数；IFNULL() 是 MySQL 特有，仅支持两个参数。

• COALESCE(col1, col2, 'default')：从左到右返回第一个非 NULL 值，支持任意数量参数
• IFNULL(col, 'fallback')：仅判断第一个参数，是 COALESCE(col, fallback) 的简写，但不可移植到 PostgreSQL 或 SQLite
• 注意：如果替换值本身可能为 NULL（比如 COALESCE(NULLIF(a, b), 'x')），嵌套时逻辑容易出错，建议拆开验证

INSERT 和 UPDATE 中防止 NULL 写入的关键控制点

靠应用层过滤不保险，必须在数据库层面加固。核心是结合约束、默认值和触发器三类机制。

• 建表时对关键字段加 NOT NULL，并指定 DEFAULT（如 created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP）
• 对已有表添加约束前，先用 UPDATE table SET col = 'N/A' WHERE col IS NULL 清理脏数据，否则 ALTER TABLE ... MODIFY col VARCHAR(50) NOT NULL 会报错
• 避免用触发器自动填充 NULL——它绕过应用逻辑且难调试；优先用 DEFAULT 和应用层预处理

备份与权限配置中容易被忽略的安全细节

NULL 本身不构成安全风险，但处理不当会暴露数据缺失逻辑，或让权限策略失效。

• mysqldump 默认不导出 DEFINER 属性，若视图/存储过程含 SQL SECURITY DEFINER，恢复后可能因用户不存在导致执行失败
• 授予 SELECT 权限时，如果某列允许 NULL，攻击者可通过大量 WHERE col IS NULL 查询推断该列是否被业务逻辑刻意留空（如“未审核”状态），需配合行级权限或视图脱敏
• 开启 sql_mode=STRICT_TRANS_TABLES，否

  

  则插入超长字符串或非法日期会静默转为 NULL，掩盖数据质量问题

NULL 的真正难点不在语法，而在于它同时是“缺失值”“未知值”和“未定义值”——同一个字段在不同业务上下文中语义可能完全不同。处理时得先问清楚：“这个 NULL 是用户没填？系统没采集到？还是逻辑上就该不存在？”否则补再多 COALESCE 也只是掩盖问题。