这是一个很好的数据库设计问题。MySQL不建议使用NULL作为列默认值主要有以下几个原因，涉及性能、查询复杂性和数据完整性：

1. 存储空间问题

• NULL值需要额外存储：在InnoDB中，每个可为NULL的列需要一个额外的位（bit）来标记是否为NULL
• 固定长度列中的NULL：如果是固定长度列（如CHAR），NULL仍然会占用完整长度
• 虽然现代MySQL版本有优化，但NULL列在行格式中仍有额外开销

2. 索引效率

• 索引包含NULL值：虽然NULL值会被索引，但在某些查询中可能不如预期工作
• 联合索引限制：如果联合索引包含NULL值，查询优化器可能无法充分利用索引
• COUNT查询差异： SELECT COUNT(*) FROM table; -- 统计所有行 SELECT COUNT(column) FROM table; -- 忽略NULL值，结果可能不同

3. 查询复杂性增加

-- 比较运算复杂
WHERE column = NULL;    -- 错误写法，永远不会返回true
WHERE column IS NULL;   -- 正确写法

-- 与聚合函数配合时的意外结果
SELECT AVG(column) FROM table;  -- NULL值被忽略，可能不是预期结果

4. 数据完整性风险

• 语义模糊：NULL可以表示”未知”、”不适用”、”未填写”，含义不明确
• 业务逻辑复杂：需要在应用层频繁处理NULL检查
• 默认值混淆：NULL vs 空字符串” vs 0 的选择困难

5. 最佳实践替代方案

使用NOT NULL + 默认值

-- 不推荐的写法
CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(100) NULL,
    age INT NULL
);

-- 推荐的写法
CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(100) NOT NULL DEFAULT '',
    age INT NOT NULL DEFAULT 0,
    status ENUM('active', 'inactive') NOT NULL DEFAULT 'active'
);

特殊情况的处理

-- 确实需要表示"未知"时
CREATE TABLE orders (
    id INT PRIMARY KEY,
    shipped_date DATE NULL,  -- 确实可能未知
    discount DECIMAL(5,2) NOT NULL DEFAULT 0.00
);

6. 实际性能影响示例

-- 当有大量NULL时，索引可能不被使用
EXPLAIN SELECT * FROM users WHERE phone = '123456';
-- 如果phone列大部分为NULL，优化器可能选择全表扫描

7. 框架和ORM的兼容性

许多ORM（如Hibernate、Eloquent）对NULL处理不够智能，可能导致：

• 意外的N+1查询问题
• 序列化/反序列化问题
• API响应中的null字段

建议总结

1. 尽量使用NOT NULL，为列设置合理的默认值
2. 区分”空值”和”未知”：
   • 字符串：用''代替NULL
   • 数字：用0代替NULL
   • 布尔：用false代替NULL
3. 只有确实需要表示”未知/不适用”时才用NULL
4. 在表设计时明确业务含义，而不是技术默认

例外情况：当确实需要区分”无值”、”未知”、”未设置”时，使用NULL是合理的，但要做好文档记录和团队规范统一。