MySQL中什么时候使用null_何时在MySQL表中使用NULL

However, I have often read about

performance problems when fields are

nullable and been advised to use an

empty string in cases where NULL is

actually semantically correct.

我要对字的选择有点挑剔：

>即使它是一个重要的性能因素，这不会使语义正确使用值而不是NULL。在SQL中，NULL具有语义角色，用于表示丢失或不适用的值。在给定的RDBMS实现中的NULL的性能特性与此无关。性能可能因品牌或版本而异，但语言中NULL的目的是一致的。

在任何情况下，我没有听说过任何证据表明NULL执行不好。我对任何对性能测量的引用感兴趣，表明可空列的性能比不可为空的列差。

我不是说我没有错，或者它在某些情况下不能是真的 – 只是，使空闲的假设没有意义。科学不是由猜想构成;必须显示具有可重复测量的证据。

指标还告诉你性能有多少不同，所以你可以判断它是否值得担心的事情。也就是说，影响可以是可衡量的和非零的，但与更大的性能因素相比仍然微不足道，例如正确地索引表或调整数据库缓存大小。

在MySQL中，搜索NULL可以从索引中获益：

mysql> CREATE TABLE foo (

i INT NOT NULL,

j INT DEFAULT NULL,

PRIMARY KEY (i),

UNIQUE KEY j_index (j)

);

mysql> INSERT INTO foo (i, j) VALUES

(1, 1), (2, 2), (3, NULL), (4, NULL), (5, 5);

mysql> EXPLAIN SELECT * FROM foo WHERE i = 3;

+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |

+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+

| 1 | SIMPLE | foo | const | PRIMARY | PRIMARY | 4 | const | 1 | |

+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+

mysql> EXPLAIN SELECT * FROM foo WHERE j IS NULL;

+----+-------------+-------+------+---------------+---------+---------+-------+------+-------------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |

+----+-------------+-------+------+---------------+---------+---------+-------+------+-------------+

| 1 | SIMPLE | foo | ref | j_index | j_index | 5 | const | 2 | Using where |

+----+-------------+-------+------+---------------+---------+---------+-------+------+-------------+

请注意，它仍然不是性能的衡量标准。我只显示你可以使用索引，同时搜索NULL。我要断言(不可否认，没有测量，但嘿这只是StackOverflow)，索引的好处遮蔽了任何可能的惩罚，当搜索NULL对一个空白字符串。

选择零或空白或任何其他值来替代NULL不是正确的设计决策。您可能需要在列中使用这些值作为重要值。这就是为什么NULL存在，作为一个值，通过定义在任何数据类型的值的域之外，所以你可以使用整数或字符串或任何值的完整范围的值，仍然有一些东西表示“没有上述的值。 “。