MySQL数据库优化

---

一、查询优化

常见的查询优化策略如下，其中1至5为代数优化，6涉及物理优化：

1. 选择运算和投影运算尽可能先做：因为满足选择条件的元组或投影后的元组一般是原来关系的子集，从而使计算的中间结果变小。
2. 将投影运算和选择运算同时进行：如有若干投影和选择运算，并且它们都对同一个关系操作，则可以将这些一元运算一起执行以避免重复扫描关系。如SELECT SNAME FROM XS WHERE SNO = '001101'。
3. 把投影同其前或其后的双目运算结合起来执行：双目运算包括连接运算和笛卡尔积，双目运算会筛选出关系中的部分元组，没有必要为了投影运算而单独扫描一遍关系。如SELECT SNAME FROM XS JOIN CJ。
4. 把某些选择同在它前面要执行的笛卡尔积结合起来成为一个连接运算：连接（特别是等连接）运算要比在同样关系上的笛卡尔积产生的结果小得多，执行代价也小得多，当R$\times$S前有选择运算且选择条件是R和S属性间的比较运算时，可以将其转换为连接运算节省时间。如SELECT * FROM XS JOIN CJ ON XS.SNO = '001101。
5. 找出公共子表达式：先计算一次公共子表达式并把其结果保存起来共享，以避免重复计算公共子表达式。当查询的是视图时，定义视图的表达式就是公共子表达式的情况。
6. 选取合适的连接算法：连接操作是关系操作中最费时的操作，可以通过索引连接算法、排序合并算法、Hash连接算法等连接算法提高查询效率。

---

二、范式化和反范式化

函数依赖：

• 函数依赖：设R(U)是属性集U上的关系模式，X与Y是U的子集，如果对于X的每一个具体值，Y都有唯一的值与之对应，则称X函数决定Y或Y函数依赖于X，记作X→Y。函数依赖是关系模式中属性之间的逻辑依赖关系。
• 决定因子与依赖因子：如果X决定Y，则X为决定因子，Y为依赖因子。
• 非平凡的函数依赖：如果X决定Y，但Y不是X的子集，则称X决定Y是非平凡的函数依赖。如(学号，课程号)决定成绩。
• 平凡的函数依赖：如果X决定Y，且Y是X的子集，则称X决定Y是平凡的函数依赖。如(学号，课程号)决定学号。
• 完全函数依赖：如果X决定Y，并且X的任何一个真子集都无法决定Y，则称Y完全函数依赖于X。如(学号，课程号)决定成绩。
• 部分函数依赖：如果X决定Y，并且X的某一个真子集可以决定Y，则称Y部分函数依赖于X，如(学号，课程号)决定姓名。如果Y部分函数依赖于X，则X必定是组合属性。
• 传递函数依赖：如果X决定Y，Y不是X的子集且Y无法决定X，Y决定Z，Z不是Y的子集，则称Z传递函数依赖于X。如学号决定班级，班级决定系。

范式理论：

• 第一范式：对于一个关系模式，如果其所有的属性都是不可分的基本数据项，则称其属于第一范式，简称1NF。在任何一个关系数据库系统中，第一范式是对关系模式最起码的要求。不满足第一范式的数据库模式不能称为关系数据库。如：(学号，课程号，系，系主任)。
• 第二范式：对于一个属于第一范式的关系模式，如果其所有非主属性都完全函数依赖于码，则称其属于第二范式，简称2NF。第二范式即关系模式中不存在非主属性对主属性的部分函数依赖问题。如：(学号，系，系主任)。
• 第三范式：对于一个属于第二范式的关系模式，如果其所有非主属性都不传递函数依赖于码，则称R属于第三范式，简称3NF。第三范式解决了关系模式中非主属性对主属性的传递函数依赖问题。如：(学号，系)。
• BCNF范式：对于一个属于第三范式的关系模式，如果其所有主属性都不部分和传递函数依赖于码，则称其属于BCNF范式。如：(学号，系)。

范式优化是指合理化表的设计，比如令其符合3NF、消除冗余、节省空间。而反范式化则允许信息冗余或者存放在多个不同的数据表。

范式设计和反范式设计都有优点和缺点:

• 通常在遇到性能问题的时候，会推荐使用范式设计，因为范式设计数据表更新相比反范式而言会更快。同时由于没有冗余数据，因此需要更改的数据更少，单表存储空间也更小。此外由于缺乏冗余数据，意味着使用DISTINCT和GROUP BY的查询的需求会更少，可以通过直接查询相关的主表完成这类操作。范式表的缺点在于通常会需要至少一次的联表查询，甚至多张表联合查询。这种查询不但代价高，还可能导致有些索引策略失效。
• 反范式表最大的特点是同一张表包含了所有信息，因此避免了联合查询。如果不使用联合查询的话，在不使用索引的前提下大部分查询的最糟糕的情况是全表扫描，但即便是这样，也会比没有命中缓存的联合查询快，因为这样避免了随机I/O访问。此外反范式表的单表索引策略会更有效。当然，反范式设计也会有其缺点，一是数据表冗余后会存储空间会变大。二是如果冗余列对应的主表发生了变更，可能需要进行大量的数据行更新。

---

三、数据拆分

数据拆分主要分为分表和分库，二者又各自对应水平拆分和垂直拆分。

垂直角度（改变结构不改变记录数量）：

• 垂直分表：将一个表字段拆分成多个表，每个表存储部分字段。好处是避免I/O时锁表的次数，分离热点字段和非热点字段，避免大字段I/O导致性能下降。原则是业务经常组合查询的字段一个表，不常用字段一个表，文本类型单独分表。
• 垂直分库：根据业务类型将表分类放到不同的数据库服务器上。好处是避免表之间竞争同一个物理机的资源。原则是根据业务相关性进行划分。

水平角度（改变记录数量不改变结构）：

• 水平分库：把同个表的数据按照一定规则分到不同的数据库中，数据库在不同的服务器上。好处是通过多个数据库降低了系统压力。原则是选择合适的分片键和分片策略，和业务场景配合，避免数据热点和访问不均衡，避免二次扩容难度大。
• 水平分表：同个数据库内，把一个表的数据按照一定规则拆分到多个表中，对数据进行拆分，不影响表结构。好处是单个表的数据量少了，业务SQL执行效率高，降低了系统压力。原则与水平分库类似。

---

四、读写分离

MySQL读写分离是指修改操作在主库上执行，而对于查询操作可以在从库上执行。主要目的是分担主库的业务压力，进一步提升数据库的负载性能。对于高访问量的业务场景，MySQL读写分离显得格外重要。读写分离主要借助于数据库中间件来实现。