做后端开发久了发现大部分人对数据库空值的理解都是模糊的。很多人默认 NULL 和 空字符串’’ 是一回事都是空数据业务代码里不做区分存的时候随便存查的时候模糊匹配。平时简单业务、测试数据少完全看不出问题。一旦项目迭代久了、数据量大了就会出现各种诡异的数据查询丢失、统计不准、筛选漏数据的问题。最关键的是这种问题不会报错、不会超时、日志无异常就是数据对不上排查起来特别磨人。首先要搞懂一个核心点在MySQL里NULL 和 ‘’ 完全是两个东西。NULL 代表无值、未定义、未知状态空字符串是确定的空内容。两者本质不同查询规则、索引命中、统计逻辑全部不一样。日常开发最大的坑就是普通等值查询查不到 NULL。很多人写SQL习惯用 where column ‘’ 查空数据结果只能匹配到空字符串库里大量NULL的数据直接被漏掉。反过来用 is null 查询又拿不到空字符串的数据。很多后台列表筛选、数据统计、对账报表出错根源就在这里。开发存数据混用两种空值查询只判断一种直接漏掉一半数据。还有一个很隐蔽的坑是索引失效问题。同样的字段空字符串可以正常走索引但是NULL值在部分场景下会被索引忽略。我之前遇到过一个线上慢查询筛选空数据时一半数据走索引秒查一半NULL数据全表扫描。就是因为前期字段不规范既有NULL又有空字符串导致查询效率两极分化。分组统计的坑更是重灾区。group by 分组的时候所有NULL值会被合并成一组而空字符串会单独成一组。如果业务逻辑需要精准统计不同分类的空数据混用两种空值会直接导致统计数据错乱对账永远对不平。更离谱的是排序规则不一样。MySQL排序时NULL值默认排在最前面空字符串会排在正常数据中间。列表分页、数据排序错乱、前后页数据重复缺失很多玄学分页问题都是空值不统一导致的。还有新增数据的遗留问题。很多老表字段允许为NULL新业务代码统一存空字符串。新旧数据混杂库里面两种空值并存。后续迭代的查询逻辑无论怎么写都无法完美兼容要么漏数据要么查冗余数据变成历史技术债务。网上很多人说字段默认设为NULL无所谓其实这是很不负责任的写法。业务字段尤其是字符串、备注、渠道、扩展字段一旦允许NULL大概率会出现空值混乱问题。现在我建表的习惯很简单所有业务字符串字段统一 not null default ‘’。从建表阶段杜绝NULL和空字符串混用的问题查询逻辑只需要判断空字符串不用兼容is null代码简洁还不出错。真正稳定的数据库业务从来不是靠写复杂SQL而是靠前期规范的字段设计。很多看起来微不足道的空值细节堆积起来就是长期修不完的数据bug。