高性能SQL——数据库设计使用陷阱

Posted 2021-09-27 苏凌峰

数据库设计陷阱

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语句聚合数据的表