Zuo后端开发久了我们hen容易陷入一种“舒适区”。在建表的时候，手指头几乎是下意识地勾选了“允许NULL”。心里想着：“先这样吧，省事，反正业务上也不一定非要填。”这种想法就像是在代码里埋下了一颗颗不定时炸弹，平时相安无事，一旦到了业务复杂或者数据量上来的时候，炸得你措手不及。

今天咱们不聊那些枯燥的理论，就来扒一扒这个kan似人畜无害的 NULL，到底是怎么在不知不觉中搞垮你的系统和心态的。

一、 查询逻辑的“黑洞”：你以为你知道，其实你不知道

咱们先从Zui基础的查询说起。这事儿我敢打赌，在座的各位至少有一半人踩过坑。

某天下午，产品经理风风火火地跑过来：“大华，快帮我拉个数据，统计一下咱们平台有多少用户没填邮箱，运营那边要Zuo一波精准推送。”

你心想，这还不简单？于是你自信满满地敲下了这条SQL：

SELECT COUNT FROM user WHERE email = '';

结果出来了运营那边拿着数据一对比，眉头一皱：“不对啊，后台明明显示有几千个空邮箱的，怎么你这只有几百个？”

你心里咯噔一下。没错，你忘了那个Zui让人头疼的东西——NULL。

在数据库的世界里NULL 代表“未知”，它不是一个具体的值，甚至不等于它自己。所以当你用 = '' 去查的时候，那些被标记为 NULL 的数据就像隐身了一样，根本不会被查出来。你得像防贼一样，时刻记得加上 IS NULL 的判断：

SELECT COUNT FROM user WHERE email IS NULL OR email = '';

这还没完。Ru果你想反过来查所有“填了邮箱”的用户，你可Neng会写：

SELECT COUNT FROM user WHERE email != '';

又错了！因为在SQL的逻辑里NULL != '' 的结果既不是真，也不是假，而是“未知”。所以那些 NULL 的记录 被无情地排除在外。你不得不写成：

SELECT COUNT FROM user WHERE email IS NOT NULL AND email != '';

每次写这种 WHERE 条件，dou得在脑子里过一遍：这个字段会不会是NULL？是不是得加个 IS NULL？这种精神负担，写多了真的让人抓狂。

二、 聚合函数的“陷阱”：数据失真就在一瞬间

Ru果说查询逻辑只是让你多写几行代码，那聚合函数的问题，可Neng直接导致你给老板汇报的数据出大错。

还是刚才那个用户表。老板想kankan咱们用户的平均年龄大概是多少，好制定用户画像。你随手写了个：

SELECT AVG FROM user;

结果出来是25岁。老板一kan，乐了：“咱们平台这么年轻？”

实际上呢？可Neng是因为你的表里有一大半用户的 age 字段是 NULL。MySQL的 AVGSUM 这些聚合函数有个特性：它们会直接忽略 NULL 值。也就是说你算出来的只是“填了年龄的那些用户”的平均值，而不是“全站用户”的平均值。这数据水分可就大了去了。

Ru果你在建表的时候，把 age 设为 NOT NULL DEFAULT 0，那么没填年龄的用户就会被算作0岁。虽然业务上可Neng需要区分“婴儿”和“未填”，但这至少保证了统计分母的准确性。至于怎么区分，你完全Ke以用个 -1 或者其他特殊值来标记“未知”，总比让数据直接“消失”要好得多。

三、 索引效率的“隐形杀手”：性Neng就是这样被拖垮的

聊完业务逻辑，咱们再深挖一下底层性Neng。hen多同学觉得，NULL 就是个存不存数据的问题，跟性Neng有啥关系？

关系大了。

咱们dou知道，为了查询快，得加索引。但是在MySQL里NULL 值在索引中的处理方式比较特殊。虽然现在的MySQL对索引的优化Yi经比以前好多了但依然存在隐患。

Ru果你的索引列中包含了大量的 NULL 值，索引的选择性就会变差。啥叫选择性？简单说就是索引Neng不Neng精准地定位到数据。Ru果一个索引里有一半dou是 NULL，那MySQL查询优化器可Neng会觉得：“这索引也没啥用啊，还不如直接全表扫描来得快。”

举个例子，你执行这条语句：

SELECT * FROM user WHERE email = '';

Ru果 email 字段允许 NULL，且表中有hen多 NULL 值，MySQL在扫描索引时处理这些 NULL 的开销可Neng会影响优化器的判断。在某些极端情况下它甚至可Neng放弃走索引，直接扫表。一旦数据量到了百万、千万级，这一念之差，查询速度就是天壤之别。

而且，从存储空间的角度kan，虽然 NULL 本身不占用数据存储空间，但它需要额外的位图来标记这一行到底是不是 NULL。这虽然kan似微不足道，但积少成多，也是一笔开销。

四、 代码层面的“灾难”：空指针异常的噩梦

数据库的坑，Zui终dou会传导到代码里。对于咱们Java开发者来说NullPointerException 简直就是挥之不去的阴影。

假设你用MyBatis查了个用户对象：

User user = userMapper.findById;
String email = user.getEmail;
if ) { 
    // Zuo点啥... 
}

啪！程序崩了报了个空指针异常。为啥？因为数据库里 email 是 NULL，MyBatis老老实实地把它映射成了Java里的 null。你在一个 null 对象上调用 equals，不崩才怪。

你可Neng会说：“我知道啊，我加个判断不就行了？”

if ) { ... }

是Ke以但你想过没有，一个User对象有十几个字段，Ru果每个字段dou可Neng是 NULL，你的代码里就会充斥着这种防御性的 if 判断。代码写得丑不说还容易漏。漏掉一个，线上就挂一个。

geng坑的是字符串拼接。你想生成一句文案：“用户名xxx的邮箱是yyy”。

SELECT CONCAT FROM user;

只要 email 是 NULL，恭喜你，整条 CONCAT 的结果dou是 NULL。你想展示的文案直接消失在数据海洋里。这种隐式的“传染性”，是调试起来Zui让人头秃的问题。

五、 Zui佳实践：如何优雅地拒绝NULL

说了这么多 NULL 的坏话，那咱们该怎么办？难道以后dou不用 NULL 了吗？

我的建议是：Neng不用就不用，尽量使用 NOT NULL 并配合默认值。

咱们把刚才那个表结构改一改：

CREATE TABLE `user` (
  `id` int NOT NULL AUTO_INCREMENT,
  `username` varchar NOT NULL COMMENT '用户名',
  `nickname` varchar NOT NULL DEFAULT '' COMMENT '昵称',
  `age` int NOT NULL DEFAULT 0 COMMENT '年龄',
  `phone` varchar NOT NULL DEFAULT '' COMMENT '手机号',
  `email` varchar NOT NULL DEFAULT '' COMMENT '邮箱',
  `status` tinyint NOT NULL DEFAULT 1 COMMENT '状态 -1正常 0禁用',
  `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  PRIMARY KEY 
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

你kan，这样设计之后：

查询简单： 没填邮箱就是 email = ''，不用管 IS NULL。

统计准确： AVG 虽然会把没填的算作0，但至少分母是对的，业务上也好处理。

代码清爽： Java里取出来的永远是字符串，哪怕没填也是空串 ""，随便调用 equalslength dou不会报错。

索引紧凑： 没有 NULL 值干扰，索引树geng纯粹，查询优化器geng容易Zuo出正确的选择。

六、 什么时候必须用NULL？

当然凡事无绝对。咱们不Neng把 NULL 一棒子打死。有些业务场景，只有 NULL 才Neng表达那个意思。

比如你需要区分“空值”和“未知值”。

举个经典的例子：用户的“中间名”。Ru果用户没填中间名，那可Neng是他没有中间名，也可Neng是他不想填或者系统还没录入。虽然这种场景在业务上比较少见，但一旦有，你就得用 NULL。

再比如逻辑删除的时间戳。通常我们设计一个 deleted_at 字段，NULL 表示未删除，有具体时间值表示Yi删除。这种设计利用了 NULL 的唯一性，非常巧妙。

还有跟第三方系统对接的时候，对方规范里明确要求某些字段必须传 NULL，这时候你也得保留。

数据库设计是系统的地基。地基没打好，楼盖得再高也是危房。NULL 这个东西，用好了是利器，用不好就是给自己挖坑。

所以下次在建表或者加字段的时候，别再顺手就选 DEFAULT NULL 了。多问自己一句：“这个字段真的允许未知吗？Neng不Neng给个默认值？” 你的代码，你的运维同事，甚至未来的你自己，dou会感谢这个小小的坚持。

别偷懒，把 NOT NULL 刻进DNA里吧！

---