MySQL 不建议将 NULL 作为默认值，核心原因是 NULL 的特殊语义会引发 逻辑判断异常、性能损耗、数据一致性风险 三大问题，具体可拆解为以下几点：
1. 逻辑判断容易出错（违反直觉）
- NULL 在 SQL 中代表“未知值”，而非“空值”，其判断逻辑不遵循普通布尔规则，极易导致业务逻辑错误：
- 不能用 = 或 != 判断 NULL：需用 IS NULL 或 IS NOT NULL（如 WHERE col = NULL 结果永远为 NULL，而非 false，会过滤掉所有数据）；
- 聚合函数忽略 NULL：COUNT(col) 会排除 NULL 值（若想统计所有行数需用 COUNT(*)），SUM()、AVG() 也会忽略 NULL，可能导致统计结果不符合预期；
- 数值运算结果异常：NULL + 1、NULL * 2 结果均为 NULL，若字段用于计算（如金额、数量），会直接导致业务逻辑中断。
2. 影响查询性能（索引与存储损耗）
-
NULL 会增加数据库的存储和计算开销，间接影响查询效率：
-
索引效率降低：MySQL 的 B-Tree 索引虽支持 NULL，但 NULL 值的存储会增加索引结构的复杂度（需额外标记“未知”状态），导致索引扫描速度变慢；
-
存储空间浪费：NULL 值在 InnoDB 中需额外占用 1 字节存储“是否为 NULL”的标记位（NULL 本身不存实际数据，但标记位会增加开销）；
-
条件过滤耗时：包含 IS NULL/IS NOT NULL 的查询，可能无法完全利用索引（尤其在复杂条件下），需更多的行级过滤，增加 CPU 消耗。
3. 破坏数据一致性（业务语义模糊）
-
NULL 的“未知”语义会导致数据含义不明确，增加业务维护成本：
-
语义歧义：NULL 无法区分“值未填写”“值不存在”“值为空”三种场景（如“用户手机号为 NULL”，无法判断是用户没填，还是系统没收集）；
-
关联查询异常：LEFT JOIN 中，若关联字段含 NULL，可能产生意外的匹配结果（如 a.col = b.col 时，NULL 与任何值都不匹配，导致关联失败）；
-
约束无法生效：UNIQUE 约束允许多个 NULL 值（因 NULL 不与任何值相等），若字段需唯一（如“邮箱”），用 NULL 会破坏唯一性约束。
替代方案（推荐做法）
为避免 NULL 的问题，建议根据字段语义设置更合理的默认值：
-
字符串类型：用空字符串（''）代替 NULL（如 DEFAULT ''）；
-
数值类型：用 0 或 -1（需符合业务语义，如“数量默认 0”“未设置的 ID 为 -1”）；
-
日期类型：用 '1970-01-01' 或业务无关的固定日期（避免 NULL 导致日期计算错误）。
总结
NULL 的核心问题是其“未知”语义与业务中“明确空值”的需求不匹配，且会引发逻辑、性能、一致性风险。除非字段确实需要表达“值不存在/未知”（极罕见场景），否则优先用具体的、有业务含义的默认值替代 NULL，能显著降低后续开发和维护成本。
