在进行MySQL的优化之前，必须要了解的就是MySQL的查询过程，很多查询优化工作实际上就是遵循一些原则，让MySQL的优化器能够按照预想的合理方式运行而已。
一、优化的哲学
1、优化可能带来的问题
- 优化不总是对一个单纯的环境进行，还很可能是一个复杂的已投产的系统；
- 优化手段本来就有很大的风险，只不过你没能力意识到和预见到；
- 任何的技术可以解决一个问题，但必然存在带来一个问题的风险；
- 对于优化来说解决问题而带来的问题，控制在可接受的范围内才是有成果；
- 保持现状或出现更差的情况都是失败！
2、优化的需求
- 稳定性和业务可持续性，通常比性能更重要；
- 优化不可避免涉及到变更，变更就有风险；
- 优化使性能变好，维持和变差是等概率事件；
- 切记优化，应该是各部门协同，共同参与的工作，任何单一部门都不能对数据库进行优化！
所以优化工作，是由业务需要驱使的！
3、优化由谁参与
在进行数据库优化时，应由数据库管理员、业务部门代表、应用程序架构师、应用程序设计人员、应用程序开发人员、硬件及系统管理员、存储管理员等，业务相关人员共同参与。
二、优化思路
1、优化什么
在数据库优化上有两个主要方面：即安全与性能。
- 安全->数据可持续性；
- 性能->数据的高性能访问。
2、优化的范围有哪些
存储、主机和操作系统方面：
- 主机架构稳定性；
- I/O规划及配置；
- Swap交换分区；
- OS内核参数和网络问题。
应用程序方面：
- 应用程序稳定性；
- SQL语句性能；
- 串行访问资源；
- 性能欠佳会话管理；
- 这个应用适不适合用MySQL。
数据库优化方面：
- 内存；
- 数据库结构（物理&逻辑）；
- 实例配置；
3、优化维度
数据库优化维度有四个：
硬件、系统配置、数据库表结构、SQL及索引。
优化选择：
三、优化工具有啥？
1、数据库层面
检查问题常用工具：
不常用但好用的工具：
2、数据库层面问题解决思路
一般应急调优的思路：针对突然的业务办理卡顿，无法进行正常的业务处理，需要立马解决的场景。
常规调优思路：针对业务周期性的卡顿，例如在每天10-11点业务特别慢，但是还能够使用，过了这段时间就好了。
3、系统层面
Cpu方面：
vmstat、sar top、htop、nmon、mpstat；内存：
free、ps-aux；IO设备（磁盘、网络）：
iostat、ss、netstat、iptraf、iftop、lsof；vmstat命令说明：
iostat命令说明：
4、系统层面问题解决办法
你认为到底负载高好，还是低好呢？在实际的生产中，一般认为Cpu只要不超过90%都没什么问题。
当然不排除下面这些特殊情况：
Cpu负载高，IO负载低：
IO负载高，Cpu负载低：
IO和cpu负载都很高：
四、基础优化
1、优化思路
定位问题点吮吸：硬件-->系统-->应用-->数据库-->架构（高可用、读写分离、分库分表）。
处理方向：明确优化目标、性能和安全的折中、防患未然。
2、硬件优化
主机方面：
CPU的选择：
内存的选择：
存储方面：
主机raid卡选择：
实现操作系统磁盘的冗余（raid1）；
平衡内存和磁盘资源；
随机的I/O和顺序的I/O；
主机raid卡的BBU（Battery Backup Unit）要关闭。
网络设备方面：
3、服务器硬件优化
4、系统优化
Cpu：
内存：
SWAP：
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调度策略:
#echo deadline>/sys/block/sda/queue/scheduler 临时修改为deadline永久修改
vi /boot/grub/grub.conf
更改到如下内容:
kernel /boot/vmlinuz-2.6.18-8.el5 ro root=LABEL=/ elevator=deadline rhgb quiet5、系统参数调整
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 655356、应用优化
业务应用和数据库应用独立；
防火墙：iptables、selinux等其他无用服务（关闭）：
chkconfig --level 23456 acpid off
chkconfig --level 23456 anacron off
chkconfig --level 23456 autofs off
chkconfig --level 23456 avahi-daemon off
chkconfig --level 23456 bluetooth off
chkconfig --level 23456 cups off
chkconfig --level 23456 firstboot off
chkconfig --level 23456 haldaemon off
chkconfig --level 23456 hplip off
chkconfig --level 23456 ip6tables off
chkconfig --level 23456 iptables off
chkconfig --level 23456 isdn off
chkconfig --level 23456 pcscd off
chkconfig --level 23456 sendmail off
chkconfig --level 23456 yum-updatesd off安装图形界面的服务器不要启动图形界面runlevel 3。
另外，思考将来我们的业务是否真的需要MySQL，还是使用其他种类的数据库。用数据库的最高境界就是不用数据库。
五、数据库优化
SQL优化方向：执行计划、索引、SQL改写。
架构优化方向：高可用架构、高性能架构、分库分表。
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层（基础优化）
2、存储引擎层（innodb基础优化参数）
default-storage-engine
innodb_buffer_pool_size # 没有固定大小，50%测试值，看看情况再微调。但是尽量设置不要超过物理内存70%
innodb_file_per_table=(1,0)
innodb_flush_log_at_trx_commit=(0,1,2) # 1是最安全的，0是性能最高，2折中
binlog_sync
Innodb_flush_method=(O_DIRECT, fdatasync)
innodb_log_buffer_size # 100M以下
innodb_log_file_size # 100M 以下
innodb_log_files_in_group # 5个成员以下,一般2-3个够用（iblogfile0-N）
innodb_max_dirty_pages_pct # 达到百分之75的时候刷写 内存脏页到磁盘。
log_bin
max_binlog_cache_size # 可以不设置
max_binlog_size # 可以不设置
innodb_additional_mem_pool_size #小于2G内存的机器，推荐值是20M。32G内存以上100M