MySQL 如何调优（下）

数据库大量应用程序开发项目中，大多数情况下，数据的操作性能成为整个应用的性能瓶颈。数据库的性能是程序员需要去关注的事情，当设计数据库表结果已经操作数据库（尤其是查询数据时），都需要注意数据操作的性能，本文我们以 MySQL 数据库为例进行讨论。

一、数据库优化目标

1. 减少 IO 次数

IO永远是数据库最容易瓶颈的地方，这是由数据库的职责所决定的，大部分数据库操作中超过 90% 的时间都是 IO 操作所占用，减少 IO 次数是 SQL 优化中需要第一优先考虑。当然，也是收效最明显的优化手段。

2. 降低 CPU 计算

除了 IO 瓶颈之外，SQL 优化中需要考虑的就是 CPU 运算量的优化了。ORDER BY，GROUP BY，DISTINST ... 都是消耗 CPU 的大户（这些操作基本上都是 CPU 处理内存中的数据比较运算）。当我们的 IO 优化做到一定阶段之后，降低 CPU 计算也就成为了我们sql 优化的重要目标。

MySQL查询过程.png

二、数据库优化方法

1. SQL 语句优化

明确了优化目标之后，我们需要确定达到我们的目标的方法。对于SQL语句来说，达到上述2个优化目标的方法其实只有一个，那就是改变SQL的执行计划，让他尽量"少走弯路"，尽量通过各种"捷径"来找到我们需要的数据，已达到“减少IO次数”和“降低CPU计算”的目标。

• 尽量少 join，MySQL 的优势在于简单，但这在某些方面其实也是劣势。MySQL 优化器效率高，但是由于其统计信息的量有限，优化器工作过程中出现变差的可能性也就更多。对于复杂的多表 Join，一方面由于其优化器受限，再者在 Join 这方面所下的功夫还不够，所以性能表现离 Oracle 等关系型数据库前辈还是有一定的距离。但如果是简单的单表查询，这一差距就会极小甚至在有些场景下要优于这些数据库前辈。
• 尽量少排序
• 排序操作会消耗较多的 CPU 资源，所以减少排序可以在缓存命中率高等IO能力足够的场景下会较大影响 SQL 的响应时间。
• 尽量避免使用 SELECT * ，并尽量使用 Join 代替子查询。
• 尽量少使用 “OR” 关键字
  当 where 子句中存在多个条件以 “OR” 并存的时候，MySQL 的优化器并没有很好的解决其执行计划优化问题，再加上 MySQL 特有的 SQL 与 Storage 分成架构方式，造成了其性能比较低下，很多时候使用 UNION ALL 或者是 UNION （必要的时候）的方式来代替 “OR” 会得到更好的效果。
• 尽量用 UNION ALL 代替 UNION
  union 和 union all 的差异主要是前者需要要将两个或多个结果集合并后在进行唯一性过滤操作，这就会涉及到排序，增加大量的 CPU 运算，加大资源消耗及延迟。所以当我们可以确认不可能出现重复结果集或者不在乎重复结果集的时候，尽量使用 union all 而不是 union。
• 避免类型转换
• 能用 DISTINCT 的就不用 GROUP BY
• 尽量不要用 SELECT INTO 语句
• 从全局出发优化，而不是片面调整

SQL 优化不能是单独针对某一个进行，而应充分考虑系统中所有 SQL，尤其是在调整索引优化 SQL 的执行计划的时候，千万不能顾此失彼，因小失大。

2. 表结构优化

MySQL 数据库时基于行（Row）存储的数据库，而数据库操作 IO 的时候是以 page（block）的方式，也就是说，如果我们每条记录所占用的空间量减小，就会使每个 page 中可存放的数据行数增大，那么每次 IO 可访问的行数也就增多了。反过来说，处理相同行数的数据，需要访问的 page 就会减少，也就是 IO 操作次数降低，直接提升性能。

数据类型选择

原则是：数据行的长度不要超过 8020 字节，如果超过了这个长度的话在物理页中数据会占用两行从而造成存储碎片，降低查询效率；字段的长度在最大限度的满足可能的需要的前提下，应该尽可能的设的短一些；这样可以提高查询的效率，而且在建立索引的时候也可以减少资源的消耗。

• 数字类型：非万不得已不要使用 DOUBLE ，不仅仅只是存储长度的问题，同时还会存在精确性的问题。同样，固定精度的小数，也不建议使用 DECIMAL，建议乘以固定倍数转换成整数存储，可以大大节省存储空间，且不会带来任何附加维护成本。
• 字符类型：定长类型，建议使用 CHAR 类型（CHAR 查询快，但是耗存储空间，可用于用户名，密码等长度变化不大的字段），不定长字段尽量使用 VARCHAR （VARCHAR 查询相对慢一些但是节省存储空间，可用于评论等长度变化大的字段），且仅仅设定适当 的最大长度，而不是非常随意 的给一个很大的最大长度限定，因为不同的长度范围，MySQL也会有不一样的存储处理。
• 时间类型：尽量使用 TIMESTAMPl 类型，因为其存储空间只需要 DATATIME 类的一半。对于只需要精确到某一天的数据类型，建议使用 DATE 类型，因为他的存储空间只需要 3 个字节，比 TIMESTAMP 还少。不建议通过 INT 类型存储一个 unix timestamp 的值，因为这不太直观，会给维护带来不必要的麻烦，同时还不会带来任何好处。
• ENUM & SET：对于状态字段，可以尝试使用 ENUM 来存放，因为可以极大的降低存储空间，而且即使需要增加新的类型，只要增加与末尾，修改结构也不需要重建表数据。

字符编码

字符集直接决定了数据在 MySQL 中的存储编码方式，由于同样的内容使用不同字符集表示所占用的空间大小会有较大的差异，所以通过使用合适的字符集，可以帮助我们尽可能减少数据量，进而减少 IO 操作次数。

尽量使用 NOT NULL

NULL 类型比较特殊，SQL 难优化。虽然 MySQL NULL 类型和 Oracle 的 NULL 有差异，会进入索引中，但如果是一个组合索引，那么这个 NULL 类型的字段会极大影响整个索引的效率。虽然 NULL 空间上可能确实有一定节省，倒是带来了很多其他的优化问题，不但没有将 IO 量省下来，反而加大了 SQL 的 IO 量。所以尽量确保 DEFAULT 值不是 NULL ，也是一个很好的表结构设计优化习惯。

3. 数据库架构优化

分布式和集群化

• 负载均衡：负载均衡集群是由一组相互独立的计算机系统构成，通过常规网络或专用网络进行连接，由路由器衔接在一起，个节点相互协作，共同负载，均衡压力，对客户端来说，整个集群可以视为一台具有超高性能的独立服务器。MySQL一般部署的是高可用性负载均衡集群，具备读写分离，一般只对读进行负载均衡。
• 读写分离：读写分离简单的说是把对数据库读和写操作分开对应不同的数据库服务器，这样能有效地减轻数据库压力，也能减轻 IO 压力。主数据库提供写操作，从数据库提供读操作，其实在很多系统中，主要是读的操作。当主数据库进行写操作时，数据要同步到从的数据库，这样才能有效保证数据库的完整性。
• 数据切分：通过某种特定的条件，将存放在同一个数据库中的数据分散存放在多个数据库上，实现分布存储，通过路由规则路由访问特定的数据库，这样每次访问面对的就不是单台服务器了，而是N台服务器，这样就可以降低单台机器的负载压力。

4. 其他优化

• 适当使用视图加速查询。把表的一个子集进行排序并创建视图，有时候能加速查询（特别是要被多次执行的查询）。它有助于避免多重排序操作，而且在其他方面还能简化优化器的工作。视图中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘 IO，所以查询工作量可以得到大幅度的减少。
• 算法优化：尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。使用基于游标的方法或临时表方法之前，应该先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。与临时表一样，游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。
• 封装存储过程：经编译和优化后存储在数据库服务器中，运行效率高，可以降低客户机和服务器之间的通信量，有利于集中控制，易于维护。