[mysql 字段] not null 还是 null default

@RedBeanIce 看产品定义，产品要显示 0 那你整形默认值改为比如-1 。
具体情况具体分析。
不想显示 0 那就前端改为空。

@RedBeanIce #37
"请问一下，一个非必填字段。如何判断用户输入 0 ，还是 default 0 ，，"
—— 你既然根据产品规则设置了默认是 0 ，也就是可以给用户端 0 用来展示，那不管是不是用户输入的 0 ，都是正确的作为前端展示的值。
搞清楚一点，提高产品思维，这个前提下，实现业务逻辑的重点是为了产品合理性，而不是为了去满足你区分到底是不是用户输入的强迫症需求

#39 "产品规则可控，感觉好麻烦。。。。"
—— 我们程序员骂产品"狗"的时候，很多是因为产品不懂技术瓶颈压力、随便什么需求都敢提
—— 而产品骂程序员的时候也很多是因为程序员只考虑技术、不考虑产品

前阵子雷军不好举例子他亲自下场去当销售才体会到技术人员太执着于技术了做不好产品的嘛

嫌麻烦，其实就是咱没经历过好厂好项目好规范的训练，作坊式的生产、不规范习惯了导致了懒惰，然后反倒去以为别人这么做是多余、说人家麻烦。。

规范、严谨的工程，比如知名开源，或者硅谷那些知名厂的多数项目，规范化得多，提交、合并流程各种繁琐。说起来麻烦，但确实这很规范，大家都规范，也是对自己能力的提升

@iseki
默认值不一定是 0 。
结合产品需求的默认值设计，我#33 已经明确讲过了，#42 有更多补充。

@GTim 你说了半天我还是没懂，bigint 是如何存储时区信息的？ 转 UTC 时间的 timestamp ？

那么用 datetime 还是用 bigint 有差别吗？ 为了防止人肉眼看的时候能直接看出来这个是什么时间吗？

bigint 和 timestamp 最大的差距仅仅是 2038 的长度问题， 除此之外他们在存储本质上没区别，只是后一个 mysql 可以自动处理给你显示成人类可读的时间。

统统用 varchar ，默认值 '' ，益寿延年，🐶🐶🐶🐶

另外，这么多人聊了这么多 居然只有 @kiwi95 提到这个问题的重点，mysql 的 null 索引有性能问题，会慢非常多！

要求 not null + default 的规则制定者中能说明白的大拿都会和你明确的说，mysql 非 null 查询性能会差一个数量级。

这是 mysql 的问题，不知道 8.0 有没有解决，最起码 5.5 5.6 这些规则书写成那个年代的版本是真实存在的性能问题。
而且这只是 mysql 的问题，mysql 小毛病一大堆，所以你网上看到的许多数据库优化的点实际上并不通用，就是针对 mysql 的。

上学时候 学 sql server 还在天天教数据库三范式的年代，哪听说过这种要求。

最后，所有支持 存在 null 才是符合大多数 程序员逻辑的想法， 除非你入门编程语言恰好是非 C 系那几个排斥引用类型有 null 值的语言。

因为数据不存在 null 和 数据存在值为 0 ，含义是不一致的。
让他们表达相同的含义就和前端页面父子组件样式有问题导致挤压错位，然后用绝对定位或者 margin 负数移动回来一样。
在外在表现上看起来是没问题了，但实际上从根本逻辑上讲他就不应该这么处理。

@GTim 做过国际化的表示，timestamp with time zone 方便多了，pg

默认值是业务控制的，不是数据库控制的。数据库尽量不用默认值，空与非空，除非必要，不然可空，业务不可空交给业务控制。

@RedBeanIce 好，现在给你这个场景做面试题，你真的没有方案吗？

方案肯定有的，就看愿不愿意用。主要还是考虑统一和方便性。前后端通信有意义的值为什么一定要定义 0 呢，0 只是抽象的符号，用什么都可以。

@fengpan567 对。时间戳不允许 NULL 就是___🖊

@RedBeanIce
所以说你傻呀....不让用户输 0 不就可以了
难道你还要杠用户绕过 UI 设 0 ？

主要是 mysql 中如果设置 null 会有很多坑，例如在条件判定需要 is not null ，或者 sum 、groupby 这些函数结果，再有就是部分情况下索引失效，这些都是一不留神会出错的，就算你不出错，你也不能保证团队其他人不出错，所以如果能用空值或者是 0 标识且没有疑义的化还是不要用 null 来比较好。