瞬间带你了解如何优化 Mysql 数据库，老板再也不担心客户投诉了

一、优化方向

二、优化方法

1、监控分析

• 硬件资源监控
  • 关注的主要数据库服务器在IO和CPU方面的指标。
• mysql性能分析器
  • 可以利用 mysql profiling（mysql性能分析器）来优化sql语句，即查看SQL执行消耗系统资源的信息（需要开启才能应用该功能）。
• 慢查询分析
  • 通过慢日志查询可以知道哪些SQL语句执行效率低下，那些sql语句使用的频率高等。

对MySQL查询语句的监控、分析、优化是MySQL优化非常重要的一步。开启慢查询日志后，由于日志记录操作，在一定程度上会占用CPU资源影响mysql的性能，但是可以阶段性开启来定位性能瓶颈。

2、改变 SQL 执行计划

使用explain命令查看query语句的性能

• id：id主要是用来标识sql执行顺序，如果没有子查询，一般来说id只有1个，执行顺序也是从上到下。
• select_type：每个select子句的类型，主要分成下面几种：
  • SIMPLE：查询中不包含任何子查询或者union
  • PRIMARY：查询中包含了任何复杂的子部分，最外层的就会变成PRIMARY
  • SUBQUERY：在SELECT或者WHERE列表中包含了子查询
  • DERIVED：在FROM中包含了子查询
  • UNION：如果第二个SELECT出现在UNION之后，则被标记为UNION，如果UNION包含在FROM子句的子查询中，外层SELECT会被标记为：DERIVED
  • UNION RESULT从UNION表获取结果的select
• type：是指MySQL在表中找到所需行的方式，也就是访问行的“类型”，从 all 开始，效率逐渐上升：
  • all：全表扫描，效率最低
  • index：index会根据索引树遍历
  • range：索引范围扫描，返回匹配值域的行。
  • ref：非唯一性索引扫描，返回匹配某个单独值的所有行。一般是指多列的唯一索引中的某一列。
  • eq_ref：唯一性索引扫描，表中只有一条记录与之匹配。
  • const、system：主要针对查询中有常量的情况，如果结果只有一行会变成system
  • NULL：显而易见，既不走表，也不走索引
• possible_keys
  • possible_keys列预估了mysql能够为当前查询选择的索引，这个字段是完全独立于执行计划中输出的表的顺序，意味着在实际查询中可能用不到这些索引。
  • 如果该字段为空则意味着没有可使用的索引，这个时候你可以考虑为where后面的字段建立索引。
• key
  • 这个字段表示了mysql真实使用的索引（如果为NULL，则没有使用索引）。如果mysql优化过程中没有加索引，可以强制加hint使用索引。
• key_len
  • 索引长度字段顾名思义，表示了mysql查询中使用的索引的长度（最大可能长度），并非实际使用长度，理论上长度越短越好。key_len是根据表定义计算而得的，不是通过表内检索出的。
• ref
  • 这个字段一般是指一些常量用于选择过滤（显示索引的那一列被使用了，如果可能，是一个常量const）。
• rows
  • 预估结果集的条数，可能不一定完全准确（根据表统计信息及索引选用情况，大致估算出找到所需的记录所需要读取的行数）。
• Extra
  • 不适合在其他字段中显示，但是十分重要的额外信息：
    • Using filesort：mysql对数据使用一个外部的索引排序，而不是按照表内的索引进行排序读取。也就是说mysql无法利用索引完成的排序操作成为“文件排序”。
    • Using temporary：使用临时表保存中间结果，也就是说mysql在对查询结果排序时使用了临时表，常见于order by 和 group by。
    • Using index：表示相应的 select 操作中使用了覆盖索引（Covering Index），避免了访问表的数据行，这样提高了效率（不使用select *）；如果同时出现Using where，表明索引被用来执行索引键值的查找；如果没用同时出现Using where，表明索引用来读取数据而非执行查找动作。
    • Using join buffer：使用了链接缓存。
    • eq_ref:唯一性索引扫描，表中只有一条记录与之匹配。
    • Impossible WHERE：where子句的值总是false，不能用来获取任何元祖。
    • select tables optimized away：在没有group by子句的情况下，基于索引优化MIN/MAX操作或者对于MyISAM存储引擎优化COUNT（*）操作，不必等到执行阶段在进行计算，查询执行计划生成的阶段即可完成优化。
    • distinct：优化distinct操作，在找到第一个匹配的元祖后即停止找同样值得动作。

三、软优化

1、查询语句优化

• EXPLAIN或DESCRIBE(简写:DESC)命令分析一条查询语句的执行信息，查看其中的不足，予以改善

2、优化子查询

• 在MySQL中，尽量使用JOIN来代替子查询，因为子查询需要嵌套查询，嵌套查询时会建立一张临时表，临时表的建立和删除都会有较大的系统开销，而连接查询不会创建临时表，因此效率比嵌套子查询高。

3、使用索引

• 根据情况，创建合适的索引
  • 主键、唯一键会自动创建索引
  • 外键也必须有索引，因为外键是子表的主键关连建，能更快速的定位子表内容
  • 使用唯一性较好的、更新不是很频繁的、经常与其他表进行连接的字段作为索引
  • 经常出现在 where 语句中的字段，需要做索引，会更好的方便我们处理日常事务，节约时间成本
  • 选择性较高的字段需要做索引
  • 超长字段，建议做全文索引，或者不建立索引

4、分解表

• 对于字段较多的表，如果某些字段使用频率较低，此时应当，将其分离出来从而形成新的表。
• 大表拆分成多个小表，之间进行外键关联，提高查询效率。

5、增加中间表

• 对于将大量连接查询的表可以创建中间表，从而减少在查询时造成的连接耗时。

6、增加冗余字段

• 类似于创建中间表，增加冗余也是为了减少连接查询。

7、选择合适的引擎

• 根据不同的使用场景，分配不同的数据库引擎，提高效率。

8、分析表、检查表、优化表

• 分析表主要是分析表中关键字的分布，检查表主要是检查表中是否存在错误，优化表主要是消除删除或更新造成的表空间浪费。

9、视图的使用

• 把表的一个子集进行排序并创建视图，有时能加速查询（特别是要被多次执行的查询）。它有助于避免多重排序操作，而且在其他方面还能简化优化器的工作。视图中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘I/O，所以查询工作量可以得到大幅减少。

四、硬优化

1、CPU、内存、磁盘

• 配置多核心和频率高的cpu,多核心可以执行多个线程.
• 配置大内存,提高内存,即可提高缓存区容量,因此能减少磁盘I/O时间,从而提高响应速度.
• 配置高速磁盘或合理分布磁盘:高速磁盘提高I/O,分布磁盘能提高并行操作的能力.

2、参数（提高资源利用率——》提高MySQL服务器性能）

• key_buffer_size：索引缓冲区大小
• table_cache：能同时打开表的个数
• query_cache_size和query_cache_type：前者是查询缓冲区大小，后者是前面参数的开关，0表示不使用缓冲区，1表示使用缓冲区，但可以在查询中使用SQL_NO_CACHE表示不要使用缓冲区，2表示在查询中明确指出使用缓冲区才用缓冲区，即SQL_CACHE
• sort_buffer_size：排序缓冲区

3、分库分表

• 当遇到高并发环境时，数据库压力可能过大，系统性能可能会降低，因为数据库负载过高对性能会有影响，可能导致数据库宕机
• 为防止宕机情况发生，可以把一个库拆分为多个库，部署在多个数据库服务上，这时作为主库承载写入请求。然后每个主库都挂载至少一个从库，由从库来承载读请求。

五、架构优化

1、主从复制

主从复制简单地说，就是主服务器通过dump线程把数据写入二进制日志，然后从服务器通过IO线程的请求，把二进制日志同步到自身的中继日志中，接着通过SQL线程，把SQL语句在自己的库执行一遍，以达到数据同步的目的。

①、异步复制

默认复制为异步复制，主库在执行完客户端提交的事务后立即返回客户端，并不需要等待从服务器是否同步完成，这样就有一个时间差，这时候如果出现了主服务器出现灾难性问题，可能会导致从服务器数据没有完全同步完成，造成数据的丢失

②、全同步复制

当主库在执行完客户端提交的事务后，会等待所有从服务器也执行完该事务后，才能返回客户端，所以全同步复制的性能必然会受到严重的影响。

③、半同步复制

介于异步和全同步之间，主库在执行完客户端提交的事务后，会等待至少一个从库接收并写入中继日志后才会返回客户端。
相对于异步复制，半同步复制提高了数据的安全性，但也相对的造成了一定程度的延迟

2、读写分离

读写分离简单的说是把对数据库读和写的操作分开对应不同的数据库服务器，这样能有效地减轻数据库压力，也能减轻IO压力。主数据库提供写操作，从数据库提供读操作，其实在很多系统中，主要是读的操作。当主数据库进行写操作时，数据要同步到从的数据库，这样才能有效保证数据库完整性

3、MHA高可用

MHA（MasterHigh Availability）是一套优秀的MySQL高可用环境下故障切换和主从复制的软件。当主服务器出现故障时，MHA能做到0-30秒内自动完成故障切换操作，让VIP漂移到备选的服务器上，以保证服务的不中断运行，给我们争取了抢修主服务器的时间。

4、proxySQL代理

• proxySQL代理功能：
  • 最基本的读/写分离，且方式有多种
  • 可定制基于用户、基于schema、基于语句的规则对SQL语句进行路由。换句话说，规则很灵活。基于schema和与语句级的规则，可以实现简单的sharding(分库分表)
  • 可缓存查询结果。虽然ProxySQL的缓存策略比较简陋，但实现了基本的缓存功能，绝大多数时候也够用了。
  • 监控后端节点。ProxySQL可以监控后端节点的多个指标，包括：ProxySQL和后端的心跳信息，后端节点的read-only/read-write，slave和master的数据同步延迟性(replication lag)