mysql子查询列为null_Mysql的列是否应该为null

本人建表一直不喜欢用NULL值，因为NULL代表给定的列多出了一种特殊的类型值。我一直觉得，int就应该都是int,string就应该都是string。

最近接手了一个项目，表已经都建好了。 但是字段都是nulll，类型除了ID全都是varchar。一直觉得匪夷所思，看了数据来源有点明白了，数据是第三方接口出的，存在大量NULL值。所有字段varchar会把接口给出的错误数据也记录下来。 在此不讨论此做法的利弊。

在某需求中，我体验到了null值所带来的好处，那就是统计。大家都知道，null值不属于任何类型，它就是null。所以他给字段的索引带来了额外的负担。而统计，正好相反。只要你自己明白null不属于任何阵营，在使用的过程中把他和int区分开来，他会带给你很大的方便。 在统计中，Mysql本身会忽略不计入null值，只计算本来应有的类型，只要你明白这点及与你的需求相符，它会给你省去很多的麻烦。

在上述中，我尝试到了null值带来的好处，或者说，我尝试到了一个字段多种类型所带来的好处。

直到我再次遇到了一个麻烦。

SELECT a.id from table is_comment = 0;

SELECT a.id from table is_comment = 1;

上面两段SQL，TABLE有600W的数据，这是今年所产生的，去年的让运维做了归档。is_comment为index。索引大小1.5G。数据3.5G

两个看似相同的SQL，执行起来的速度会让你感觉到绝望。

is_comment为varchar字段。按说所有的数字都会被转换成string去匹配索引。第二条的查询速度不到1秒，但是第一条缺30秒都没跑出来。让我感到相当的绝望。

EXPLAIN时，两条SQL都不会查询索引。 但是执行时发现is_comment=1是秒查，is_comment=0要30秒。很明显，1是被Mysql做了字符串转换，0却没有。is_comment='1' 或者 is_comment='0'都可以解决这个事情。  但我还是被一个字段多种类型玩的头大。

字段的类型是什么，关乎的不在于你的值，更在于与它交互的代码。这代表你的代码要严格照着给定的类型去执行。而null值，一种特殊的存在，不管你的字段是int还是string，他都是第三种类型。如果你的需求不需要它，就不要用它，尽量保证你的字段只会存在一种类型。