MySQL性能调优：提升性能的关键步骤-每日运维

调优维度

当我们讨论对数据库进行优化时，很多人第一反应想到的就是SQL优化，如何创建索引，如何改写SQL，他们把数据库优化与SQL优化划上了等号。

那今天我们站在架构的角度来聊聊这一问题，数据库优化可以从哪些维度入手？

正如上图所示，数据库优化可以从架构优化，硬件优化，DB优化，SQL优化四个维度入手。

一般来说在高并发的场景下对架构层进行优化其效果最为明显，常见的优化手段有：分布式缓存，读写分离，分库分表等，每种优化手段又适用于不同的应用场景。

有句老话说的好，性能不够，缓存来凑。当需要在架构层进行优化时我们第一时间就会想到缓存这个神器，在应用与数据库之间增加一个缓存服务，如Redis。

一主多从，读写分离，主动同步，是一种常见的数据库架构优化手段。

水平切分，也是一种常见的数据库架构优化手段。

当你的应用业务数据量很大，单库容量成为性能瓶颈后，采用水平切分，可以降低数据库单库容量，提升数据库写性能。

1.读写分离主要是用于解决 “数据库读性能问题”
2.水平切分主要是用于解决“数据库数据量大的问题”
3.分布式缓存架构可能比读写分离更适用于高并发、大数据量大场景。

对硬件设备和操作系统设置进行优化，例如调整操作系统参数、禁用 swap、增加内存、升级固态硬盘等等。

我们使用数据库，不管是读操作还是写操作，最终都是要访问磁盘，所以说磁盘的性能决定了数据库的性能。一块PCIE固态硬盘的性能是普通机械硬盘的几十倍不止。这里我们可以从吞吐率、IOPS两个维度看一下机械硬盘、普通固态硬盘、PCIE固态硬盘之间的性能指标。

吞吐率：单位时间内读写的数据量

机械硬盘：约100MB/s ～ 200MB/s
普通固态硬盘：200MB/s ～ 500MB/s
PCIE固态硬盘：900MB/s ～ 3GB/s

IOPS：每秒IO操作的次数

机械硬盘：100 ～200
普通固态硬盘：30000 ～ 50000
PCIE固态硬盘：数十万

通过上面的数据可以很直观的看到不同规格的硬盘之间的性能差距非常大，当然性能更好的硬盘价格会更贵，在资金充足并且迫切需要提升数据库性能时，尝试更换一下数据库的硬盘不失为一个非常好的举措，你之前遇到SQL执行缓慢问题在你更换硬盘后很可能将不再是问题。

通过InnoDB架构概述对于DB优化主要优化各种buffer、log。

SQL执行慢有时候不一定完全是SQL问题，手动安装一台数据库而不做任何参数调整，再怎么优化SQL都无法让其性能最大化。要让一台数据库实例完全发挥其性能，首先我们就得先优化数据库的实例参数。

数据库实例参数优化遵循三句口诀：日志不能小、缓存足够大、连接要够用。

数据库事务提交后需要将事务对数据页的修改刷（ fsync）到磁盘上，才能保证数据的持久性。这个刷盘，是一个随机写，性能较低，如果每次事务提交都要刷盘，会极大影响数据库的性能。数据库在架构设计中都会采用如下两个优化手法：

先将事务写到日志文件RedoLog（WAL），将随机写优化成顺序写
加一层缓存结构Buffer，将单次写优化成顺序写
所以日志跟缓存对数据库实例尤其重要。而连接如果不够用，数据库会直接抛出异常，系统无法访问。

接下来我们看下MySQL参数该如何配置。

SQL优化很容易理解，就是通过建立合适的表结构、给查询字段添加索引或者改写SQL提高其执行效率，一般而言，SQL编写有以下几个通用的技巧：
重点来看前两个纬度，要点如下图所示。

合理使用索引

索引少了查询慢；
索引多了占用空间大，执行增删改语句的时候需要动态维护索引，影响性能
选择率高（重复值少）且被where频繁引用需要建立B树索引；
JOIN字段建议建立索引；
复杂文档类型查询采用全文索引效率更好；
索引的建立要在查询和DML性能之间取得平衡；
复合索引创建时要注意基于非前导列查询的情况；
创建联合索引时要根据最左原则考虑索引的复用能力，不要重复创建索引；要为保证数据不能重复的字段创建唯一索引等等。不过要注意索引对插入、更新等写操作是有代价的，不要滥用索引，比如像性别这样唯一很差的字段就不适合建立索引。

表拆分

要在设计表结构时，考虑数据库的水平与垂直扩展能力，提前规划好未来1年的数据量、读写量的增长，规划好分库分表方案。比如设计用户信息表，预计 1 年后用户数据 10亿条，写 QPS 约 5000，读 QPS 30000，可以设计按 UID 纬度进行散列，分为 4 个库每个库 32 张表，单表数据量控制在 KW 级别。
可以将字段多的表分解成多个表，必要时增加中间表进行关联。假如一张表有 40～50 个字段显然不是一个好的设计。
一般来说，设计关系数据库时需要满足第三范式，但为了满足第三范式，我们可能会拆分出多张表。而在进行查询时需要对多张表进行关联查询，有时为了提高查询效率，会降低范式的要求，在表中保存一定的冗余信息，也叫做反范式。但要注意反范式一定要适度。

选择合适数据类型

要为字段选择合适的数据类型，在保留扩展能力的前提下，优先选用较小的数据结构。例如保存年龄的字段，要使用 TINYINT 而不要使用 INT。
尽可能使用not null。MySQL 难以对使用 null 的列进行查询优化，允许 null 会使索引、索引统计和值更加复杂，允许 null 值的列需要更多的存储空间，还需要 MySQL 内部进行特殊处理。

确定合适的索引：