mysql 字段设计，尽量设置不允许为null

其实 从 个人的角度来看，， 都无所谓，，为了麻烦，有时候 都是 默认可以为 null 的 。 但是看了一些 文章，说 如果 字段 加了索引，或者 以后 有可能会 加索引，， 对于 MySQL 的 字段来说， 应该是 不能 null 的 ，不仅仅是 效率 和性能问题，，，而且 还有着 查询的 巨坑的。

注意：MySQL字段尽量避免NULL，应该指定列为NOT NULL，除非你想存储NULL。在MySQL中，含有空值的列很难进行查询优化，而且对表索引时不会存储NULL值的，所以如果索引的字段可以为NULL，索引的效率会下降很多。因为它们使得索引、索引的统计信息以及比较运算更加复杂。你应该用0、一个特殊的值或者一个空串代替空值。 本文永久地址：http://blog.it985.com/12398.html

参考地址： http://blog.csdn.net/qingfenglu/article/details/48022837

允许为null 的 列，查询有潜在 大坑。 单列索引不存 null 值，复合索引 不存全为 null 的值，如果 列 允许为null ,可能会得到 "不符合预期" 的结果集：

例子： 
 select * from  user where name!='xxxa'
如果name 允许 为 null ,  加了索引， 索引不存储 为 null 的值 ，结果 集中不会包含 这些记录的

但是呢，，，如果字段设置了不为 null,而且有默认值。。。 那么在开发端呢，就会比较麻烦了。。。 特别是 一些 DAO的框架或者 jdbc的工具类，，会把 一些 table entity 实体，，没有值得属性，调用 save 方法的时候， 将该值 设置为 null ，来进行插入，如果字段设置了不能为null ,,,那么就会插不进去了。。。 当然如果我们可以 改改 save的方法，，判断如果没有值得话，，就忽略掉，，，那当然是好事了。。。 可是有时候 往往 没有改的权利，或者不好动。。怕出问题，特别是一些 大的老的项目。。。

总结

字段尽量避免NULL ，设置默认值，，，如果这样设置了，对开发端来说比较难 控制或者不好插入的话，，，影响开发效率的话。。。 那么就可以允许插入 null... 先把开发效率提高了再说。 如果是 加入了 索引的字段，，，那么在 插入的时候，，，代码层插入，就可以判断不能为null。。放入默认值。。这样来避免索引不存储为null的值,的情况，又提高了开发效率，兼容了dao插入方法。 或者 写代码的时候，校验不能为null。。。 如果确定了该字段不可能为null, 就设置不能为 null好了。(只是这样 如果业务发展，该字段可能又允许为 null ，那么就要修改数据库的该字段的设计了。会感觉有点麻烦了。 )

其实好多字段理论上不会 null的，就算设置了可以为 null ,那么 很多时候 写代码插入的时候，都不会有 null的，如果有null 了，，，很可能程序有问题了，加入校验即可。

我遇到的好多 dao的框架，封装的 jdbc 插入方法，都会把字段值如果没有，就 设置为 null的情况，然后 插入数据库也是 null的。

**有些技术老大，或者是公司，设置数据库表 字段的规范是： 除了主键，，，一律都可以为null的。这样子方便了 数据库的扩展和以后业务变化而造成数据库字段的改动的情况，对开发效率来说也是有一定提高的。。。 可是这样子，，容易出现bug...这个bug可能是 业务层出现的，，，不小心把不能为null的值，放入了数据库里面了，，，这样子容易造成数据的不对。 如果数据库字段设置了不能null,就可以避免了 数据风险了。 所以我的理解就是，设计的时候，对于当前业务来说，字段不能为null，有默认值就设置默认值，就设置为null,可以可能为null,就设置为null 。如果以后 有业务需求要加 挺多字段的，而之前旧的字段要为null的情况，就可以 建多一张表，或者 将默认值给之前不能为null的字段。

**

转载于:https://my.oschina.net/ouminzy/blog/1480089