MySQL性能优化

写在前面：最近有朋友和我反馈说，网上找到的mysql优化相关的都是说一些规范，注意事项之类的，没有具体的文章，所以打算写mysql优化相关的专题文章围绕mysql性能进行展开。大家可以点赞关注，后续持续为大家更新。

MySQL性能优化

一 优化介绍

​ 在进行优化讲解之前，先请大家记住不要听信你看到的关于优化的“绝对真理”，而应该是在实际的业务场景下通过测试来验证你关于执行计划以及响应时间的假设。本文章只是给大家提供一些优化方面的方向和思路，而具体业务场景的不同，使用的MySQL服务版本不同，都会使得优化方案的制定也不同。

1.1 MySQL介绍

​ MySQL凭借着出色的性能、低廉的成本、丰富的资源，已经成为绝大多数互联网公司的首选关系型数据库。可以看到Google，Facebook，Twitter，百度，新浪，腾讯，淘宝，网易，久游等绝大多数互联网公司数据库都是用的MySQL数据库，甚至将其作为核心应用的数据库系统。

​ 虽然性能出色，但所谓“好马配好鞍”，如何能够更好的使用它，已经成为开发工程师的必修课，我们经常会从招聘需求描述上看到诸如“精通MySQL”、“SQL语句优化”、“了解数据库原理”等要求。我们知道一般的应用系统，读写比例在10:1左右，而且插入操作和一般的更新操作很少出现性能问题，遇到最多的，也是最容易出问题的，还是一些复杂的查询操作，所以查询语句的优化显然是重中之重。

我们将这里进行一个较为全面的分析，让大家了解到MySQL的性能到底与哪些地方有关，以便于让大家寻找出其性能问题的根本原因，而尽可能清楚的知道该如何去优化自己的数据库。

1.2 优化要考虑的问题

注意：优化有风险，涉足需谨慎！

1.2.1 优化可能带来的问题

• 优化不总是对一个单纯的环境进行，还很可能是一个复杂的已投产的系统！
• 优化手段有很大的风险，一定要意识到和预见到！
• 任何的技术可以解决一个问题，但必然存在带来一个问题的风险！
• 对于优化来说调优而带来的问题,控制在可接受的范围内才是有成果。
• 保持现状或出现更差的情况都是失败！

1.2.2 优化的需求

• 稳定性和业务可持续性,通常比性能更重要！
• 优化不可避免涉及到变更，变更就有风险！
• 优化使性能变好，维持和变差是等概率事件！
• 优化应该是各部门协同，共同参与的工作，任何单一部门都不能对数据库进行优化！

所以优化工作,是由业务需要驱使的！！！

1.3 优化的思路

1.3.1 优化的方向

在数据库优化上有两个主要方向：即安全与性能。

• 安全 —> 数据安全性
• 性能 —> 数据的高性能访问

安全: 数据库账号权限, 数据库访问权限(白名单\黑名单)

本文章主要是在性能优化方向进行介绍

1.3.2 优化的维度

从上图中可以看出，我们把数据库优化分为四个纬度：硬件，系统配置，数据库表结构，SQL及索引

硬件 ： CPU、内存、存储、网络设备等

系统配置： 服务器系统、数据库服务参数等

数据库表结构： 高可用、分库分表、读写分离、存储引擎、表设计等

Sql及索引： sql语句、索引使用等

• 从优化成本进行考虑：硬件>系统配置>数据库表结构>SQL及索引
• 从优化效果进行考虑：硬件<系统配置<数据库表结构<SQL及索引

1.3.3 优化的工具

检查问题常用工具

msyqladmin		#mysql客户端，可进行管理操作  
mysqlshow		#功能强大的查看shell命令  
show [SESSION | GLOBAL] variables	#查看数据库参数信息  
SHOW [SESSION | GLOBAL] STATUS		#查看数据库的状态信息  
SHOW ENGINE INNODB STATUS Innodb	#引擎的所有状态  
information_schema	#获取元数据的方法
SHOW PROCESSLIST	#查看当前所有连接session状态  
explain		#获取查询语句的执行计划
show index	#查看表的索引信息  
slow-log	#记录慢查询语句  
mysqldumpslow	#分析slowlog文件的 

我们主要关注的是:

explain #获取查询语句的执行计划

mysqldumpslow #分析slowlog文件的

不常用但好用的工具

zabbix		#监控主机、系统、数据库（部署zabbix监控平台）
mysqlslap	#分析慢日志
sysbench	#压力测试工具
workbench	#管理、备份、监控、分析、优化工具（比较费资源）
pt-query-digest	#分析慢日志
mysql profiling	#统计数据库整体状态工具
Performance Schema mysql	#性能状态统计的数据

1.3.4 数据库使用优化思路

​ 本文章尽可能的全面介绍数据库的调优思路，但是在多数时候，我们进行调优不需要进行这么全面、大范围的调优，一般情况下，我们进行数据库层面的优化就可以了，那我们该如何调优的呢？

应急调优的思路：

针对突然的业务办理卡顿，无法进行正常的业务处理！需要立马解决的场景！

1. show processlist（查看链接session状态）

2. explain(分析查询计划)，show index from table（分析索引）

3. 通过执行计划判断，索引问题（有没有、合不合理）或者语句本身问题

4. show status like ‘%lock%’; # 查询锁状态

5. SESSION_ID; # 杀掉有问题的session

常规调优的思路：

针对业务周期性的卡顿，例如在每天10-11点业务特别慢，但是还能够使用，过了这段时间就好了。

1. 查看slowlog(慢查询日志)，分析slowlog，分析出查询慢的语句。
2. 按照一定优先级，进行一个一个的排查所有慢语句。
3. 分析top sql，进行explain调试，查看语句执行时间。
4. 调整索引或语句本身。

下一篇准备写关于查询优化