这个问题是咱们程序员典型的架构权衡问题,甚至可以说钻牛角尖(当然有时候钻牛角尖不是不好)。
题主,其实无论你存时间戳还是用mysql的datetime,甚至是存字符串,这基本上都不会造成系统瓶颈,你应该把80%的时间用在解决系统性能消耗占比80%的问题上去。
我们阿里的系统,能够支撑单日亿级的写操作,读是多少大家更可以YY,而其中使用mysql的系统,时间就用的datetime,所以你完全不用担心性能的问题了。
用datetime还有个显而易见的好处,可读性高。1409556216984,这个时间戳没有人能看出来是什么时间,对未来问题排查和定位也会加大复杂度。
Type | Storage (Bytes) | Minimum Value Signed | Minimum Value Unsigned | Maximum Value Signed | Maximum Value Unsigned |
---|---|---|---|---|---|
TINYINT | 1 | -128 | 0 | 127 | 255 |
SMALLINT | 2 | -32768 | 0 | 32767 | 65535 |
MEDIUMINT | 3 | -8388608 | 0 | 8388607 | 16777215 |
INT | 4 | -2147483648 | 0 | 2147483647 | 4294967295 |
BIGINT | 8 | -2^63 | 0 | 2^63 -1 | 2^64-1 |
MySQL 整型长度的含义
MySQL的 int 和 tinyint 的默认长度是 int(11) 和 tinyint(4), 而boolean 型实际存储的是 tinyint(1).
定义位数并不会影响占用空间和性能, 也不会影响存储的数字范围
- 全局唯一id分配
暂无合适解决方案
- 业务逻辑放在代码里还是数据库里
大多放在代码里比较好吧, 易维护