null在mysql中表示“未知”或“不存在”，不等于空字符串或0，参与比较时遵循三值逻辑（true、false、unknown），导致null = null结果为null；2. 查询null值不能使用=或!=，必须使用is null或is not null操作符，否则无法正确匹配；3. 使用null-safe equal operator ()可实现安全的null值比较，当两操作数均为null时返回true，一者为null时返回false；4. 聚合函数如count(column)忽略null值，而count(*)统计所有行，包含null；5. not in子查询若包含null值，整个表达式结果为null，导致无数据返回，应避免或改用not exists；6. b-tree索引可存储null值，通常位于索引端点，is null查询可能使用索引但效率较低，尤其当null占比高时优化器可能选择全表扫描；7. 联合索引中若前导列允许null，会影响索引利用效率，如where col1 is null and col2 = ‘abc’可能无法有效使用复合索引；8. 可通过创建虚拟列（如is_col_null tinyint generated always as (col is null)）并为其建立索引，提升is null查询性能；9. 表结构设计应审慎使用null，对业务上必填字段强制not null约束，保障数据完整性并提升查询稳定性；10. 对可选字段可考虑用默认值（如空字符串、0或特定编码）替代null，以简化查询逻辑并提高索引效率，但需权衡存储开销与业务语义清晰性；最终方案应基于业务需求、数据完整性和查询性能综合决策。
MySQL中对NULL值的处理，远比我们想象的要复杂，它不是一个空字符串，也不是数字0，而是一个“未知”或“不存在”的状态。这种特性决定了其在查询和索引优化上的特殊性，如果不正确理解和使用，很容易导致查询结果不准确或性能瓶颈。
解决方案
正确处理MySQL中的NULL值，核心在于理解其“未知”的语义，并采用恰当的SQL操作符进行查询，同时在表结构设计和索引策略上进行针对性优化。这意味着，我们不能用常规的等值比较来判断NULL，也不能想当然地认为含有NULL的列就能被索引高效利用。我们需要专门的
IS NULL
或
IS NOT NULL
操作符，甚至在某些场景下需要考虑
NULL-safe equal operator (<=>)
。在索引层面，要意识到NULL值在B-tree索引中的存储方式，并根据查询模式调整索引策略，比如考虑联合索引的列顺序，或者通过表结构设计尽量减少不必要的NULL值。
NULL值在MySQL中究竟特殊在哪里？
说实话，刚接触数据库那会儿，我总觉得NULL就是个“空”，跟空字符串或者0差不多，结果没少在这上面栽跟头。MySQL里的NULL，它真的不是“空”，而是一个“未知”或“不适用”的概念。举个例子，
NULL = NULL
这个表达式，你猜结果是什么？不是TRUE，也不是FALSE，而是NULL！因为两个未知的值，我们无法确定它们是否相等。这种三值逻辑（TRUE, FALSE, UNKNOWN/NULL）是NULL最核心的特性，它渗透到所有比较操作中。
再比如，聚合函数如
COUNT()
,
SUM()
,
AVG()
在默认情况下都会忽略NULL值。如果你
COUNT(column_name)
，它只统计非NULL的行数。但如果你
COUNT(*)
，它会统计所有行，包括那些包含NULL值的行。这种细微的差异，在数据分析时尤其需要注意，一不小心就可能得出错误的总计。还有，
NOT IN
子句如果遇到NULL值，其行为也会变得非常诡异，因为它内部的比较逻辑会把NULL传播开来，导致整个表达式返回NULL，进而筛选不出任何结果，这绝对是初学者最容易踩的坑之一。
查询NULL值时有哪些常见误区及正确姿势？
最常见的误区，没有之一，就是尝试用
=
或
!=
来查询NULL值。比如你想找出所有
字段为空的用户，写成
SELECT * FROM users WHERE email = NULL;
，你会发现什么都查不出来。原因前面提到了，
NULL = NULL
的结果是NULL，不是TRUE，所以条件不成立。同理，
email != NULL
也一样，它也不会返回你想要的结果。
正确的姿态，是使用专门的
IS NULL
和
IS NOT NULL
操作符。想找出
为空的用户，就应该写
SELECT * FROM users WHERE email IS NULL;
。想找出
不为空的用户，就是
SELECT * FROM users WHERE email IS NOT NULL;
。这才是MySQL理解“未知”状态的正确语法。
有时候，我们可能需要进行NULL-safe的比较，比如在存储过程中或者某些动态查询里，一个变量可能为NULL，也可能是一个具体的值，我们希望它能和列进行“等值”比较，无论变量是否为NULL。这时候，
NULL-safe equal operator (<=>)
就派上用场了。
a <=> b
会比较a和b，如果它们都为NULL，则返回TRUE；如果一个为NULL另一个不为NULL，则返回FALSE；如果都不为NULL，则像
=
一样进行比较。这在处理可能包含NULL的输入参数时特别有用，可以省去很多
IF...ELSE
的逻辑判断。
NULL值对索引优化究竟有多大影响？
NULL值对索引的影响，是个让人头疼的问题。B-tree索引是MySQL最常用的索引类型，它能高效地查找、范围查询。但NULL值在B-tree中的存储和查找效率，就没那么直观了。
首先，一个包含NULL值的列，是可以被索引的。MySQL的B-tree索引会存储NULL值，它们通常被视为一个特定的值，并被放在索引的开头或结尾（取决于具体的实现和排序规则）。这意味着，如果你对一个NULLable的列创建了索引，并且经常查询
WHERE column IS NULL
或
WHERE column IS NOT NULL
，这个索引理论上是可以被利用的。
然而，问题在于，对于
IS NULL
的查询，索引的效率往往不如对具体值的查询。因为
IS NULL
查询可能需要扫描索引中大量的NULL值条目，或者在某些情况下，优化器可能认为全表扫描更划算，从而放弃使用索引。尤其当NULL值在列中占比很高时，索引的优势就更不明显了。
更复杂的是联合索引。如果一个联合索引的第一个字段允许NULL，那么对于涉及到这个字段的查询，其索引效率可能会受到影响。例如，
INDEX(col1, col2)
，如果
col1
允许NULL，那么
WHERE col1 IS NULL AND col2 = 'abc'
这样的查询，可能就无法充分利用到
col1
的索引特性，或者只能在
col2
上进行部分索引扫描。
所以，在设计索引时，如果某个列经常用于查询且允许NULL，需要仔细权衡。如果
IS NULL
的查询非常频繁，可以考虑创建一个“虚拟列”或“计算列”，例如
is_col_null
（0或1），然后对这个虚拟列创建索引，这样查询
WHERE is_col_null = 1
就能高效利用索引了。
如何设计数据库表结构以最小化NULL值带来的负面影响？
从根源上解决问题，就是尽量减少不必要的NULL值。这并不是说要完全杜绝NULL，而是要审慎地决定哪些字段可以为NULL，哪些应该强制
NOT NULL
。
如果一个字段在业务逻辑上“总是”应该有值，那么就果断地加上
NOT NULL
约束。例如，用户注册时间、订单创建时间、产品名称等，这些信息通常都是必须的。强制
NOT NULL
不仅能保证数据完整性，还能让索引更有效，查询更简单，因为你不需要担心NULL的特殊语义。
对于那些确实可能“缺失”或“不适用”的字段，可以考虑使用默认值而不是NULL。例如，一个用户的性别字段，如果不知道，可以默认设置为“未知”或一个特定的代码（如0或9），而不是NULL。电话号码如果用户没填，可以默认设置为空字符串
''
而不是NULL。这样做的好处是，
''
和
0
都是具体的值，可以直接参与等值比较，索引效率也更高。
当然，这需要权衡。用默认值替代NULL，可能会增加数据存储的开销（比如空字符串比NULL占空间），也可能让某些业务逻辑变得复杂（需要区分
''
和实际值）。但从查询和索引优化的角度看，减少NULL值的存在，通常能带来更稳定的性能表现。
最终的决策，往往是业务需求、数据完整性和查询性能之间的平衡。没有一劳永逸的方案，只有最适合当前业务场景的设计。
评论（已关闭）
评论已关闭