数据库设计陷阱
1. 数据库设计有哪些陷阱? 如何解决?
2. 泛式的思考
3. 读写速度如何衡量?
4. 计数器表和缓存表
注释:
1. 数据库设计有哪些陷阱? 如何解决?
太多的列
数据库设计的时候不宜领有太多的列.
sql 中要在服务器层和存储引擎之间通过行缓冲格局拷贝成数据，而后在服务器层将缓冲内容编码成各个列，从行缓冲中将编码过的列转换成行数据结构的操作代价是十分高的。
如果客户应用了数千个字段的表，这种转换的代价就会十分高
太多的关联
mysql 限定每个关联操作最多只能有 61 张表，如果咱们心愿查问执行地快且好，单个查问最好在 12 个表以内做关联。
非空
非空能够让索引的建设更高效, 然而也不要自觉应用非空, 兴许能够应用 0 或者负值等来代替飞控, 但如果应用一个不可能的值, 可能会导致代码逻辑简单十分多, 并且容易引入 bug。解决 null 不容易，然而有时候比它的代替计划要好
2. 泛式的思考
咱们都学过第一范式，第二范式，第三范式，接下来我简略地概括一下泛式和反泛式的特点：
范式：每个数据在数据库里只会呈现一次
反范式：每个数据在数据库里会呈现屡次
范式的长处
因为每个数据在数据库里只呈现一次，范式化的更新操作通常比反范式快。
当数据较好地范式化时，就只有很少或者没有反复数据，所以只须要批改很少的数据。
范式化的表通常更小，能够放在内存里，所以执行操作更快。
很少有多余的数据意味着检索列表数据时更少须要 distinct 或者 group by 语句。
毛病
须要关联，范式化可能将列寄存在不同的表中，而这些列如果在一个表中本能够属于同一个索引。
反范式的优缺点
长处：
所有数据都在一个表中，防止关联
毛病：
一个数据呈现屡次，可能会呈现数据不统一的状况
每次更新数据须要更新屡次
混用范式和反范式
须要搞清楚 select 的频率和 update 的频率
如果 select 更多，就采取反泛式
如果 update 更多，就采取泛式
3. 读和写的速度如何衡量？
一般来说，读和写的速度是抵触的。
你想读地更快，势必要在多个容易读到的中央存储更多的数据，那么每次更新这个数据的时候都要写更多的中央。这就是时空对抗准则。（工夫和空间的非对称性）
更快地读，更慢地写
为了晋升查问速度，常常须要建设一些额定索引，或者反泛式，但这样会减少写的累赘。
尽管写操作变得更慢了，但显著地晋升了读操作
然而写操作变慢可能不是惟一代价，还可能同时减少了读操作和写操作的开发难度。
4. 计数器表和缓存表
咱们先介绍一下计数器表和缓存表是干嘛的：
计数器表：
举个例子，比如说，有一个签到性能，这个签到性能在你签到后会提醒你是第几个签到的，这个时候如果咱们每次进行签到的时候进行 count(*)的统计，会很慢，所以咱们应用缓存表，间接记录了明天曾经有多少人签到过了，而后在下面 + 1 即可。
缓存表：
再举个例子，假如咱们有一个公众号发送关键字主动回复的表，一个关键字对应一个主动回复，这个时候咱们能够将罕用的 10 个甚至更多个关键字先提取进去，放在一个表里，能够先去这个表里查，能够大大减少检索的数据，放慢查问效率。
总结：
缓存表用来存储哪些每次获取速度比较慢的数据的表
汇总表保留你的是应用 groupby 语句聚合数据的表