索引字段设为NOT NULL是因为NULL不存入B+树，导致IS NULL必全表扫描、=查询可能弃用索引、复合索引范围查找失效，且增加存储开销；仅deleted_at等需区分“未发生/已发生”语义时才用NULL。
索引字段设为 NOT NULL 不是为了“必须遵守规范”，而是因为 NULL 会让索引行为变得不可控——它不进 B+ 树、影响 key_len、干扰优化器决策，且多数业务场景里根本不需要这种语义。
为什么 IS NULL 查询一定走全表扫描？
InnoDB 的 B+ 树索引结构压根不存储 NULL 值。不是“跳过”，是根本不写进去。所以哪怕你在 status 列建了索引，WHERE status IS NULL 也必然触发全表扫描。
-
EXPLAIN中key字段为空、type为ALL就是典型信号 - 即使该列
NULL比例极低，优化器也不会为“查 NULL”走索引——没得选 - 想绕开？只能加一个计算列：
ALTER TABLE t ADD status_notnull TINYINT AS (IF(status IS NULL, 0, 1)) STORED，再给它建索引，但这是补救，不是设计
= 查询时索引可能被悄悄弃用
当字段允许 NULL，且统计信息显示 NULL 占比偏高（比如 >5%），优化器会倾向放弃使用该索引，改走全表或别的索引——即使你写的 WHERE status = 'active' 看起来完全合理。
- 原因：优化器要预估“等值匹配能筛掉多少行”，而
NULL的存在让基数估算失真 -
EXPLAIN中key_len比预期大 1，说明用了 NULL 位图，这是个隐式成本提示 - 验证方法：执行
ANALYZE TABLE t后再EXPLAIN，对比rows预估是否突变
复合索引中 NULL 列破坏范围查找能力
比如 (user_id, created_at) 是联合索引，created_at 允许 NULL，那么 WHERE user_id = 123 AND created_at > '2025-01-01' 很可能无法利用 created_at 的有序性做索引下推。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- InnoDB 要求范围查询的右列必须“确定可比较”，而
NULL在排序中排最前，且不参与大小比较逻辑 - 如果
created_at有大量NULL，优化器可能直接降级为只用user_id单列查找，后面靠回表过滤 - 修复方式不是删数据，而是
ALTER TABLE t MODIFY created_at DATETIME NOT NULL DEFAULT '1970-01-01'，再补默认值
NOT NULL + DEFAULT 不是妥协，是适配 InnoDB 存储格式
很多人抗拒 NOT NULL DEFAULT ''，觉得“空字符串不等于没值”。但对 InnoDB 来说，'' 是确定值，可索引、可比较、不额外占位；而 NULL 强制每行多出最多 1 字节的 NULL 位图（CEILING(N/8) 字节），1000 万行就多 1.2MB 以上。
-
DEFAULT ''和DEFAULT 0都是明确语义：该字段有值，只是当前为空/零 -
deleted_at DATETIME NULL是合理例外——NULL表示“未删除”，非NULL表示“软删时间”，这个语义无法用默认值替代 - 一旦选了
NULL，所有 SQL 必须显式处理：WHERE invite_code IS NOT NULL，ORM 映射也要配nullable=True，否则容易漏数据
真正难的是判断“这里到底需不需要区分未知和空”。大多数字段不需要——用户昵称为空就是 ''，手机号没填就是 '' 或 '00000000000'，只有像 deleted_at、reviewed_at 这类状态标记才值得保留 NULL。别让“可能为空”变成“默认为空”。
