MySQL 数据库Schema设计的性能优化

前言

很多人都认为性能是在通过编写代码（程序代码或者是数据库代码）的过程中优化出来的，其实这是一个非常大的误区。真正影响性能最大的部分是在设计中就已经产生了的，后期的优化很多时候所能够带来的改善都只是在解决前妻设计所遗留下来的一些问题而已，而且能够解决的问题通常也比较有限。本章将就如何在 MySQL 数据库 Schema 设计的时候保证尽可能的高效，尽可能减少后期的烦恼。

高效的模型设计

对于基于性能的数据库 Schema 设计，我们并不能完全以规范化范式理论来作为唯一的指导。在设计过程中，应该从实际需求出发，以性能提升为根本目标来展开设计工作，很多时候为了尽可能提高性能，我们也不得不做反范式设计。

1、适度冗余 - 让 Query 尽两减少 Join

MySQL 的优化器虽然号称使用了新一代的优化器技术实现的非常优秀，但是由于目前 MySQL 所收集的数据统计信息还不是特别的多，所以起表现并不是特别的让人满意，不少时候对各表的访问顺序选择的并不合适，造成复杂 Query 的整体执行效率低下。所以，为了让我们的 Query 执行计划尽可能的最优化，最直接有效的方式就是尽量减少 Join，而要减少 Join，我们就不可避免的需要通过表字段的冗余来实现。

2、大字段垂直分拆 - summary 表优化

那到底什么样的字段适合于从表中拆分出去呢？

a、首要肯定是大字段。为什么？原因很简单，就是因为他的大。

b、其次是和表中其他字段相比访问频率明显要少很多。如果我们已经确定有大字

段需要分拆出主表的时候，对于其他的字段，只要满足访问频率和大字段一样相对于表中其他字段要低很多的都可以和大字段同时分拆出来。实际上，在有些时候，我们甚至都不一定非要大字段才能进行垂直分拆。在有些场景下，有的表中大部分字段平时都很少访问，而其中的某几个字段却是访问频率非常高。对于这种表，也非常适合通过垂直分拆来达到优化性能的目的。

3、大表水平分拆 - 基于类型的分拆优化

4、统计表 - 准实时优化

什么类型的统计信息适合通过准实时统计表来优化实现？

首先，统计信息的准确性要求并不是特别的严格；

其次，统计信息对时间并不是太敏感；

再次，统计信息的访问非常频繁，重复执行较多；

最后，参与统计数据量较大；

合适的数据类型

优化数据类型提高性能的主要原理在于以下几个方面：

1. 通过选用更“小”的数据类型减少存储空间，使查询相同数据需要的 IO 资源降低；

2. 通过合适的数据类型加速数据的比较；

规范的对象命名

规范的命名本身并不会对性能有任何影响，在这里单独列出一节来讲，主要是因为这是一个不太被人重视，但是对后期的数据库维护影响非常大的内容。

一般来说，我个人建议需要注意以下一些方面：

1、 数据库和表名应尽可能和所服务的业务模块名一致；

2、 服务于同一子模块的一类表尽量以子模块名（或部分单词）为前缀或后缀；

3、 表名应尽量包含与所存放数据相对应的单词；

4、 字段名称也尽量保持和实际数据相对应

5、 索引名称尽量包含所有的索引键字段名或者缩写，且各字段名在索引名中的顺序应与索引键在索引中的索引顺序一致，且尽量包含一个类似于 idx 或者 ind 之类的前缀或者后缀，以表名其对象类型是索引，同时还可以包含该索引所属表的名称；这样做最大的好处在于 DBA 在维护过程中能够非常直接清晰的通过索引名称就了解到该索引大部分的信息。

6、 约束等其他对象也应该尽可能包含所属表或其他对象的名称，以表名各自关系。