数据库设计陷阱
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语句聚合数据的表