MySQL调优表结构优化

Posted 2021-05-16 EileenChang

文章目录

• 1 合理使用范式和反范式
• • 1.1 范式
  • 1.2 反范式
  • 1.3 如何选择
• 2 主键的选择
• • 2.1 代理主键和自然主键
  • 2.2 问题：为什么使用自增id而不是UUID
  • • 2.2.1 从空间方面考虑
    • 2.2.2 从插入性能考虑
• 3 存储引擎的选择
• 4 适当的拆分

---

1 合理使用范式和反范式

1.1 范式

遵循范式的优点：

• 范式化的更新通常比反范式要快。
• 当数据较好的范式化后，很少或者没有重复的数据。
• 范式化的数据比较小，可以放在内存中，操作比较快。

遵循范式的缺点：

• 通常需要进行表关联。

1.2 反范式

反范式优点：

• 所有的数据都在同一张表中，可以避免关联。
• 可以设计有效的索引。

反范式缺点：

• 表格内的冗余较多，删除数据时候会造成表有些有用的信息丢失。

1.3 如何选择

  在实际开发中很少能做到严格意义上的范式或者反范式，一般都是混合使用。

2 主键的选择

2.1 代理主键和自然主键

  主键一般可分为代理主键和自然主键：代理主键与业务无关，是无意义的数字序列；自然主键指事物属性中的自然唯一标识。一般推荐使用代理主键，因为它们不与业务耦合，因此更容易维护。

2.2 问题：为什么使用自增id而不是UUID

2.2.1 从空间方面考虑

  使用uuid（varchar）所占用的存储空间一般都比int甚至bigint占用的存储空间都要大。InnoDB的数据是按数据页为单位来读写的，一个页的大小是16kb。本来查询某个范围的数据，只需要加载一页，现在需要查询两页才能获取完整结果。这意味着加载数据时，多了一次磁盘I/O。

2.2.2 从插入性能考虑

  我们知道mysql的索引树是按索引列进行排序的，而如果我们用无序的uuid直接插入数据的话很可能会破坏这个平衡，而自增id则可以避免破坏这个平衡。
  为了保持这个平衡，MYSQL在插入时uuid时肯定会进行二分查找，而二分查找的过程肯定需要对数据进行比较，这样无疑就增加了成本。
  还有一点，针对页分裂，因为uuid的无序性，页分裂时可能要将一部分数据移动到新页中，这样不仅消耗额外性能，也容易生成空间碎片。而使用自增id，则不会出现"将一部分数据移动至新页"这种操作，因为本来就是有序的，直接在新页往下写就是了。

3 存储引擎的选择

	MyISAM	InnoDB
索引类型	非聚簇索引	聚簇索引
支持事务	否	是
支持表锁	是	是
支持行锁	否	是
支持外键	否	是
支持全文索引	是	是
适合操作类型	大量SELECT	大量INSERT、UPDATE、DELETE

4 适当的拆分

  当我们的表中存在类似于TEXT或者是很大的VARCHAR类型的大字段的时候，如果我们大部分访问这张表的时候都不需要这个字段，我们就该将其拆分到另外的独立表中，以减少常用数据所占用的存储空间。这样做的一个明显好处就是每个数据块中可以存储的数据条数可以大大增加，既减少物理 IO 次数，也能大大提高内存中的缓存命中率。