MySQL的执行流程
1.MySQL请求收到之后,MYSQL服务器会得到相关的SQL语句,执行前还需要做权限的判断等
2.通过权限之后,SQL就到MySQL内部。首先判断msyql缓存是否开启（默认是不开启的）。如果开启，它会先查询缓存中,看该SQL有没有执行过,如果有查询过,则把缓存结果返回。这个查询缓存要求SQL和参数都要一样,所以这个命中率是非常低的（基本没什么用）。
3.如果我们没有开启查询缓存,并且没有命中缓存，或者未开启查询缓存,那么就到了MYSQL解析器,解析器主要对SQL语法进行解析。
4.解析结束后就变成一颗解析树。
5.得到解析树之后对解析数预处理,也就是说,这棵树,我没有经过任何优化的树,预处理器会这这棵树进行一些预处理,比如常量放在哪里，有计算的，先把计算结果计算出来等。
6.预处理完毕之后,这就是一颗比较规范的树了，但是MYSQL还会对他进行一些优化。
7.查询优化器，是MySQL里面最关键的东西。MySQL能够计算最佳的可能查询计划，如果要不要走索引，查询哪些索引才能尽量扫描更少的数据。怎么做到较少的计算和磁盘输入输出。
8.通过查询优化器，得到查询执行计划
9.查询执行计划会传给查询执行引擎,执行引擎选择存储引擎来执行这一份传过来的计划,到磁盘中的文件中去查询,这个时候重点来了,影响这个查询性能最根本的原因是什么?就是硬盘的机械运动,也就是我们平时熟悉的IO,所以一条查询语句是快还是慢,就是根据这个时间的IO来确定的.那怎么执行IO又是什么来确定的?就是传过来的这一份执行计划.
10.如果开了查询缓存,则返回结果给客户端,并且查询缓存也放一份。
MYSQL内存优化
一、InnoDB内存优化
InnoDB用一块内存区域做I/O缓存池，该缓存池不仅用来缓存InnoDB的索引块，而且也用来缓存InnoDB的数据块。
1、innodb_log_buffer_size
决定了InnoDB重做日志缓存的大小，可以避免InnoDB在事务提交前就执行不必要的日志写入磁盘操作。
2、设置Innodb_buffer_pool_size
改变量决定了InnoDB存储引擎表数据和索引数据的最大缓存区大小。
二、MyISAM内存优化
MyISAM存储引擎使用key_buffer缓存索引模块，加速索引的读写速度。对于MyISAM表的数据块，mysql没有特别的缓存机制，完全依赖于操作系统的IO缓存。
1、read_rnd_buffer_size
对于需要做排序的MyISAM表查询，如带有order by子句的sql，适当增加read_rnd_buffer_size的值，可以改善此类的sql性能。但需要注意的是read_rnd_buffer_size独占的，如果默认设置值太大，就会造成内存浪费。
2、key_buffer_size设置
key_buffer_size决定MyISAM索引块缓存分区的大小。直接影响到MyISAM表的存取效率。对于一般MyISAM数据库，建议1/4可用内存分配给key_buffer_size:
key_buffer_size=2G
3、read_buffer_size
如果需要经常顺序扫描MyISAM表，可以通过增大read_buffer_size的值来改善性能。但需要注意的是read_buffer_size是每个seesion独占的，如果默认值设置太大，就会造成内存浪费。
三、调整MySQL参数并发相关的参数
1、调整max_connections
提高并发连接
2、调整thread_cache_size
加快连接数据库的速度，MySQL会缓存一定数量的客户服务线程以备重用，通过参数thread_cache_size可控制mysql缓存客户端线程的数量。
3、innodb_lock_wait_timeout
控制InnoDB事务等待行锁的时间，对于快速处理的SQL语句，可以将行锁等待超时时间调大，以避免发生大的回滚操作。（技术文）
史上最全的 MySQL 高性能优化实战总结，这个推荐看一下。一下内容为转载内容
一、前言
MySQL 对于很多 Linux 从业者而言，是一个非常棘手的问题，多数情况都是因为对数据库出现问题的情况和处理思路不清晰。在进行 MySQL 的优化之前必须要了解的就是 MySQL 的查询过程，很多的查询优化工作实际上就是遵循一些原则让MySQL 的优化器能够按照预想的合理方式运行而已。
今天给大家体验 MySQL 的优化实战，助你高薪之路顺畅！
图 - MySQL查询过程
二、优化的哲学
注意：优化有风险，涉足需谨慎！
1. 优化可能带来的问题
- 优化不总是对一个单纯的环境进行，还很可能是一个复杂的已投产的系统。
- 优化手段本来就有很大的风险，只不过你没能力意识到和预见到！
- 任何的技术可以解决一个问题，但必然存在带来一个问题的风险！
- 对于优化来说解决问题而带来的问题,控制在可接受的范围内才是有成果。
- 保持现状或出现更差的情况都是失败！
2. 优化的需求
- 稳定性和业务可持续性,通常比性能更重要！
- 优化不可避免涉及到变更，变更就有风险！
- 优化使性能变好，维持和变差是等概率事件！
- 切记优化，应该是各部门协同，共同参与的工作，任何单一部门都不能对数据库进行优化！
- 所以优化工作,是由业务需要驱使的！！！
3. 优化由谁参与
在进行数据库优化时，应由数据库管理员、业务部门代表、应用程序架构师、应用程序设计人员、应用程序开发人员、硬件及系统管理员、存储管理员等，业务相关人员共同参与。
三、优化思路
1. 优化什么
在数据库优化上有两个主要方面：即安全与性能。
- 安全 ---> 数据可持续性
- 性能 ---> 数据的高性能访问
2. 优化的范围有哪些
存储、主机和操作系统方面:
- 主机架构稳定性
- I/O 规划及配置
- Swap 交换分区
- OS 内核参数和网络问题
应用程序方面:
- 应用程序稳定性
- SQL 语句性能
- 串行访问资源
- 性能欠佳会话管理
- 这个应用适不适合用 MySQL
数据库优化方面:
- 内存
- 数据库结构(物理&逻辑)
- 实例配置
说明：不管是在设计系统，定位问题还是优化，都可以按照这个顺序执行。
3. 优化维度
数据库优化维度有四个：
硬件、系统配置、数据库表结构、SQL 及索引。
优化选择：
- 优化成本:硬件>系统配置>数据库表结构>SQL 及索引
- 优化效果:硬件<系统配置<数据库表结构<SQL 及索引
四、优化工具有啥
1. 数据库层面
检查问题常用工具：
不常用但好用的工具：
2. 数据库层面问题解决思路
一般应急调优的思路：
针对突然的业务办理卡顿，无法进行正常的业务处理！需要立马解决的场景！
- 1、show processlist
- 2、explain select id ,name from stu where name='clsn'; # ALL id name age sex select id,name from stu where id=2-1 函数 结果集>30; show index from table;
- 3、通过执行计划判断，索引问题(有没有、合不合理)或者语句本身问题
- 4、show status like '%lock%'; # 查询锁状态 kill SESSION_ID; # 杀掉有问题的session
常规调优思路：
针对业务周期性的卡顿，例如在每天 10-11 点业务特别慢，但是还能够使用，过了这段时间就好了。《MySQL 调优/优化的 101 个建议！》了解下。
- 1、查看 slowlog，分析 slowlog，分析出查询慢的语句。
- 2、按照一定优先级，进行一个一个的排查所有慢语句。
- 3、分析 top sql，进行 explain 调试，查看语句执行时间。
- 4、调整索引或语句本身。
3. 系统层面
cpu方面：
vmstat、sar top、htop、nmon、mpstat
内存：
free 、ps -aux 、
IO 设备(磁盘、网络)：
iostat 、 ss 、 netstat 、 iptraf、iftop、lsof、
vmstat 命令说明：
- Procs：r 显示有多少进程正在等待 CPU 时间。b 显示处于不可中断的休眠的进程数量。在等待 I/O
- Memory：swpd 显示被交换到磁盘的数据块的数量。未被使用的数据块，用户缓冲数据块，用于操作系统的数据块的数量
- Swap：操作系统每秒从磁盘上交换到内存和从内存交换到磁盘的数据块的数量。s1 和 s0 最好是 0
- Io：每秒从设备中读入 b1 的写入到设备 b0 的数据块的数量。反映了磁盘 I/O
- System：显示了每秒发生中断的数量(in)和上下文交换(cs)的数量
- Cpu：显示用于运行用户代码，系统代码，空闲，等待 I/O 的 CPU 时间
iostat 命令说明
实例命令： iostat -dk 1 5
iostat -d -k -x 5 (查看设备使用率(%util)和响应时间(await))
- tps：该设备每秒的传输次数。“一次传输”意思是“一次 I/O 请求”。多个逻辑请求可能会被合并为“一次 I/O 请求”。
- iops ：硬件出厂的时候，厂家定义的一个每秒最大的 IO 次数,"一次传输"请求的大小是未知的。
- kB_read/s：每秒从设备(drive expressed)读取的数据量；
- KB_wrtn/s：每秒向设备(drive expressed)写入的数据量；
- kB_read：读取的总数据量；
- kB_wrtn：写入的总数量数据量；这些单位都为 Kilobytes。
4. 系统层面问题解决办法
你认为到底负载高好，还是低好呢？
在实际的生产中，一般认为 cpu 只要不超过 90% 都没什么问题 。《MySQL数据库开发的 36 条军规！》了解下。
当然不排除下面这些特殊情况：
问题一：cpu 负载高，IO 负载低
- 内存不够
- 磁盘性能差
- SQL 问题 ------>去数据库层，进一步排查 sql 问题
- IO 出问题了(磁盘到临界了、raid 设计不好、raid 降级、锁、在单位时间内 tps 过高)
- tps 过高: 大量的小数据 IO、大量的全表扫描
问题二：IO 负载高，cpu 负载低
- 大量小的 IO 写操作：
- autocommit ，产生大量小 IO
- IO/PS 磁盘的一个定值，硬件出厂的时候，厂家定义的一个每秒最大的 IO 次数。
- 大量大的 IO 写操作
- SQL 问题的几率比较大
问题三：IO 和 cpu 负载都很高
硬件不够了或 SQL 存在问题
五、基础优化
1. 优化思路
定位问题点:
硬件 --> 系统 --> 应用 --> 数据库 --> 架构(高可用、读写分离、分库分表)
处理方向：
明确优化目标、性能和安全的折中、防患未然
2. 硬件优化
主机方面：
- 根据数据库类型，主机 CPU 选择、内存容量选择、磁盘选择
- 平衡内存和磁盘资源
- 随机的 I/O 和顺序的 I/O
- 主机 RAID 卡的 BBU(Battery Backup Unit)关闭
cpu 的选择：
- cpu 的两个关键因素：核数、主频
- 根据不同的业务类型进行选择：
- cpu 密集型：计算比较多，OLTP 主频很高的 cpu、核数还要多
- IO 密集型：查询比较，OLAP 核数要多，主频不一定高的
内存的选择：
- OLAP 类型数据库，需要更多内存，和数据获取量级有关。
- OLTP 类型数据一般内存是 cpu 核心数量的 2 倍到 4 倍，没有最佳实践。
存储方面：
- 根据存储数据种类的不同，选择不同的存储设备
- 配置合理的 RAID 级别(raid 5、raid 10、热备盘)
- 对与操作系统来讲，不需要太特殊的选择，最好做好冗余(raid1)(ssd、sas 、sata)
raid 卡：主机 raid 卡选择：
- 实现操作系统磁盘的冗余(raid1)
- 平衡内存和磁盘资源
- 随机的 I/O 和顺序的 I/O
- 主机 RAID 卡的 BBU(Battery Backup Unit)要关闭
网络设备方面：
使用流量支持更高的网络设备(交换机、路由器、网线、网卡、HBA 卡)
注意：以上这些规划应该在初始设计系统时就应该考虑好。
3. 服务器硬件优化
- 1、物理状态灯：
- 2、自带管理设备：远程控制卡(FENCE 设备：ipmi ilo idarc)，开关机、硬件监控。
- 3、第三方的监控软件、设备(snmp、agent)对物理设施进行监控
- 4、存储设备：自带的监控平台。EMC2(hp 收购了)， 日立(hds)，IBM 低端 OEM hds，高端存储是自己技术，华为存储
4. 系统优化
Cpu：
基本不需要调整，在硬件选择方面下功夫即可。
内存：
基本不需要调整，在硬件选择方面下功夫即可。
SWAP：
MySQL 尽量避免使用 swap。阿里云的服务器中默认 swap 为 0
IO ：
- raid、no lvm、 ext4 或 xfs、ssd、IO 调度策略
- Swap 调整(不使用 swap 分区)
这个参数决定了 Linux 是倾向于使用 swap，还是倾向于释放文件系统 cache。在内存紧张的情况下，数值越低越倾向于释放文件系统 cache。当然，这个参数只能减少使用 swap 的概率，并不能避免 Linux 使用 swap。
修改 MySQL 的配置参数 innodb_flush_method，开启 O_DIRECT 模式。这种情况下，InnoDB 的 buffer pool 会直接绕过文件系统 cache 来访问磁盘，但是redo log 依旧会使用文件系统 cache。值得注意的是，Redo log 是覆写模式的，即使使用了文件系统的 cache，也不会占用太多。
IO 调度策略：
5. 系统参数调整
Linux 系统内核参数优化：
用户限制参数(MySQL 可以不设置以下配置)：
6. 应用优化
业务应用和数据库应用独立,防火墙：iptables、selinux 等其他无用服务(关闭)：
安装图形界面的服务器不要启动图形界面 runlevel 3,另外，思考将来我们的业务是否真的需要 MySQL，还是使用其他种类的数据库。用数据库的最高境界就是不用数据库。《MySQL 调优/优化的 101 个建议！》了解下。
六、数据库优化
SQL 优化方向：
执行计划、索引、SQL 改写
架构优化方向：
高可用架构、高性能架构、分库分表
1. 数据库参数优化
调整：
实例整体(高级优化，扩展)
连接层(基础优化)
设置合理的连接客户和连接方式
SQL 层(基础优化)
- query_cache_size： 查询缓存
- OLAP 类型数据库,需要重点加大此内存缓存
- 但是一般不会超过 GB
- 对于经常被修改的数据，缓存会立马失效
- 我们可以实用内存数据库(redis、memecache)，替代他的功能
2.存储引擎层(innodb 基础优化参数)
随着系统用户量的不断增加，MySQL 索引的重要性不言而喻，对于后端工程师，只有在了解索引及其优化的规则，并应用于实际工作中后，才能不断的提升系统性能，开发出高性能、高并发和高可用的系统。
