I. Introduction
MySQL tuning for many programmers, is a very difficult problem, because in most cases the situation and deal with problems with the idea of the database is not clear. Before MySQL optimization must understand it is that the MySQL query process, a lot of query optimization actually follow some principles to make MySQL optimizer can run in a reasonable manner expected of it.
Today to explain MySQL optimization combat, to help smooth the road to paying you!
Figure - MySQL query process
Second, the optimization of philosophy
Note: Optimizing risk, involved need to be cautious!
2.1, the optimization problem may bring
1, optimization is not always a simple environment, is also likely to be a complex system already in operation.
2, optimization methods, there have been a great risk, but you do not have the ability to recognize and anticipate!
3, any technology can solve a problem, but a problem of the inevitable risks exist!
4, the optimization problem to solve the problem is brought about, which was within the acceptable range is fruitful.
5, to maintain the status quo or worse situation is a failure!
2.2, optimized demand
1, the stability and sustainability of the business, are often more important than the performance!
2, optimize inevitably involve change, there is the risk of change!
3, optimizing the performance better, maintain and poor are equal probability event!
4, remember optimization, all departments should be coordinated, to participate in the work of any single department can not optimize the database!
5, the optimization work, driven by business needs! ! !
2.3, optimizing who participate
During database optimization, should the database administrator, business sector representatives, application architects, application designers, application developers, hardware and system administrators, storage administrators and other business related personnel to participate. Reorganization: micro-channel public number, search cloud library technology team, ID: souyunku
Third, optimization ideas
3.1, optimizing what
There are two main aspects on database optimization: the security and performance.
1, security ---> Data sustainability
2, the performance ---> high performance data access
3.2, which optimize the range
Storage, and host operating systems:
1, the stability of the host architecture 2, I / O programming and configuration
3, Swap Swap
4, OS kernel parameters and network problems
Application areas:
1, the application stability
2, SQL statement performance
3, serial access resources
4, poor performance session management
5, this application is suitable to use MySQL
Database optimization:
1, memory
2、数据库结构(物理&逻辑)
3、实例配置
说明：不管是在，设计系统，定位问题还是优化，都可以按照这个顺序执行。
3.3、优化维度
数据库优化维度有四个：
硬件、系统配置、数据库表结构、SQL及索引。
优化选择：
1、优化成本: 硬件>系统配置>数据库表结构>SQL及索引
2、优化效果: 硬件<系统配置<数据库表结构<SQL及索引
四、优化工具有啥？
4.1、数据库层面
检查问题常用工具：
mysql msyqladmin mysql客户端，可进行管理操作 mysqlshow 功能强大的查看shell命令 show [SESSION | GLOBAL] variables 查看数据库参数信息 SHOW [SESSION | GLOBAL] STATUS 查看数据库的状态信息 information_schema 获取元数据的方法 SHOW ENGINE INNODB STATUS Innodb 引擎的所有状态 SHOW PROCESSLIST 查看当前所有连接session状态 explain 获取查询语句的执行计划 show index 查看表的索引信息 slow-log 记录慢查询语句 mysqldumpslow 分析slowlog文件的
不常用但好用的工具：
zabbix 监控主机、系统、数据库（部署zabbix监控平台） pt-query-digest 分析慢日志 mysqlslap 分析慢日志 sysbench 压力测试工具 mysql profiling 统计数据库整体状态工具 Performance Schema mysql性能状态统计的数据 workbench 管理、备份、监控、分析、优化工具（比较费资源）
4.2、数据库层面问题解决思路
一般应急调优的思路：
针对突然的业务办理卡顿，无法进行正常的业务处理！需要立马解决的场景！
常规调优思路：
针对业务周期性的卡顿，例如在每天10-11点业务特别慢，但是还能够使用，过了这段时间就好了。
1、查看slowlog，分析slowlog，分析出查询慢的语句。
2、按照一定优先级，进行一个一个的排查所有慢语句。
3、分析top sql，进行explain调试，查看语句执行时间。
4、调整索引或语句本身。整编：微信公众号，搜云库技术团队，ID：souyunku
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/OMemory：swpd显示被交换到磁盘的数据块的数量。未被使用的数据块，用户缓冲数据块，用于操作系统的数据块的数量Swap：操作系统每秒从磁盘上交换到内存和从内存交换到磁盘的数据块的数量。s1和s0最好是0Io：每秒从设备中读入b1的写入到设备b0的数据块的数量。反映了磁盘I/OSystem：显示了每秒发生中断的数量(in)和上下文交换(cs)的数量Cpu：显示用于运行用户代码，系统代码，空闲，等待I/O的CPU时间
iostat命令说明
实例命令：iostat -dk 1 5
iostat -d -k -x 5 （查看设备使用率（%util）和响应时间（await））
1、tps：该设备每秒的传输次数。“一次传输”意思是“一次I/O请求”。多个逻辑请求可能会被合并为“一次I/O请求”。
2、iops ：硬件出厂的时候，厂家定义的一个每秒最大的IO次数,"一次传输"请求的大小是未知的。
3、kBread/s：每秒从设备（drive expressed）读取的数据量；
4、KBwrtn/s：每秒向设备（drive expressed）写入的数据量；
5、kBread：读取的总数据量；7、kBwrtn：写入的总数量数据量；这些单位都为Kilobytes。
4.4、系统层面问题解决办法
你认为到底负载高好，还是低好呢？
在实际的生产中，一般认为 cpu只要不超过90%都没什么问题 。
当然不排除下面这些特殊情况：
问题一：cpu负载高，IO负载低
1、内存不够
2、磁盘性能差
3、SQL问题 ------>去数据库层，进一步排查sql问题
4、IO出问题了（磁盘到临界了、raid设计不好、raid降级、锁、在单位时间内tps过高）
5、tps过高: 大量的小数据IO、大量的全表扫描
问题二：IO负载高，cpu负载低
1、大量小的IO 写操作：2、autocommit ，产生大量小IO
3、IO/PS,磁盘的一个定值，硬件出厂的时候，厂家定义的一个每秒最大的IO次数。4、大量大的IO 写操作
5、SQL问题的几率比较大
问题三：IO和cpu负载都很高
硬件不够了或sql存在问题
五、基础优化
5.1、优化思路
定位问题点:
硬件 --> 系统 --> 应用 --> 数据库 --> 架构（高可用、读写分离、分库分表）
处理方向：
明确优化目标、性能和安全的折中、防患未然
5.2、硬件优化
主机方面：
1、根据数据库类型，主机CPU选择、内存容量选择、磁盘选择
2、平衡内存和磁盘资源
3、随机的I/O和顺序的I/O
4、主机 RAID卡的BBU(Battery Backup Unit)关闭
cpu的选择：
1、cpu的两个关键因素：核数、主频
2、根据不同的业务类型进行选择：3、cpu密集型：计算比较多，OLTP 主频很高的cpu、核数还要多
4、IO密集型：查询比较，OLAP 核数要多，主频不一定高的
内存的选择：
1、OLAP类型数据库，需要更多内存，和数据获取量级有关。2、OLTP类型数据一般内存是cpu核心数量的2倍到4倍，没有最佳实践。
存储方面：
1、根据存储数据种类的不同，选择不同的存储设备
2、配置合理的RAID级别(raid5、raid10、热备盘)
3、对与操作系统来讲，不需要太特殊的选择，最好做好冗余（raid1）（ssd、sas 、sata）
raid卡：主机raid卡选择：
1、实现操作系统磁盘的冗余（raid1）
2、平衡内存和磁盘资源
3、随机的I/O和顺序的I/O
4、主机 RAID卡的BBU(Battery Backup Unit)要关闭。
网络设备方面：
使用流量支持更高的网络设备（交换机、路由器、网线、网卡、HBA卡）
注意：以上这些规划应该在初始设计系统时就应该考虑好。
5.3、服务器硬件优化
1、物理状态灯：
2、自带管理设备：远程控制卡（FENCE设备：ipmi ilo idarc），开关机、硬件监控。
3、第三方的监控软件、设备（snmp、agent）对物理设施进行监控
4、存储设备：自带的监控平台。EMC2（hp收购了）， 日立（hds），IBM低端OEM hds，高端存储是自己技术，华为存储
5.4、系统优化
Cpu：
基本不需要调整，在硬件选择方面下功夫即可。
内存：
基本不需要调整，在硬件选择方面下功夫即可。
SWAP：
MySQL尽量避免使用swap。阿里云的服务器中默认swap为0
IO ：
1、raid、no lvm、 ext4或xfs、ssd、IO调度策略
1、Swap调整(不使用swap分区)
/proc/sys/vm/swappiness的内容改成0（临时） /etc/sysctl.conf上添加vm.swappiness= 0 （永久）
这个参数决定了Linux是倾向于使用swap，还是倾向于释放文件系统cache。在内存紧张的情况下，数值越低越倾向于释放文件系统cache。当然，这个参数只能减少使用swap的概率，并不能避免Linux使用swap。修改MySQL的配置参数innodbflushmethod，开启O_DIRECT模式。这种情况下，InnoDB的buffer pool会直接绕过文件系统cache来访问磁盘，但是redo log依旧会使用文件系统cache。值得注意的是，Redo log是覆写模式的，即使使用了文件系统的cache，也不会占用太多。整编：微信公众号，搜云库技术团队，ID：souyunku
IO调度策略：
vi /boot/grub/grub.conf 更改到如下内容: kernel /boot/vmlinuz- 2.6 . 18 - 8.el5 ro root=LABEL=/ elevator=deadline rhgb quiet
5.5、系统参数调整
Linux系统内核参数优化：
vim /etc/sysctl.conf net.ipv4.ip_local_port_range = 1024 65535 # 用户端口范围 # 系统最大文件句柄，控制的是能打开文件最大数量 net.ipv4.tcp_max_syn_backlog = 4096 net.ipv4.tcp_fin_timeout = 30 fs.file-max= 65535
用户限制参数（mysql可以不设置以下配置）：
vim /etc/security/limits.conf * soft nproc 65535 * hard nproc 65535 * soft nofile 65535 * hard nofile 65535
5.6、应用优化
业务应用和数据库应用独立,防火墙：iptables、selinux等其他无用服务(关闭)：
安装图形界面的服务器不要启动图形界面 runlevel 3,另外，思考将来我们的业务是否真的需要MySQL，还是使用其他种类的数据库。用数据库的最高境界就是不用数据库。
六、数据库优化
SQL优化方向：
执行计划、索引、SQL改写
架构优化方向：
高可用架构、高性能架构、分库分表
6.1、数据库参数优化
调整：
实例整体（高级优化，扩展）
thread_concurrency # 并发线程数量个数 sort_buffer_size # 排序缓存 read_buffer_size # 顺序读取缓存 read_rnd_buffer_size # 随机读取缓存 key_buffer_size # 索引缓存 thread_cache_size # (1G—>8, 2G—>16, 3G—>32, >3G—>64)
连接层（基础优化）
设置合理的连接客户和连接方式
max_connections # 最大连接数，看交易笔数设置 max_connect_errors # 最大错误连接数，能大则大 connect_timeout # 连接超时 max_user_connections # 最大用户连接数 skip-name-resolve # 跳过域名解析 wait_timeout # 等待超时 back_log # 可以在堆栈中的连接数量
SQL层（基础优化）
querycachesize：查询缓存-->>>OLAP类型数据库,需要重点加大此内存缓存.
1、但是一般不会超过GB.
2、对于经常被修改的数据，缓存会立马失效。
3、我们可以实用内存数据库（redis、memecache），替代他的功能。
6.2、存储引擎层（innodb基础优化参数）