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也只是掩盖问题。
