参考：http://blog.chinaunix.net/uid-11640640-id-3426908.html
MySQL优化：
慢查询分析mysqldumpslow
我们可以通过打开log文件查看得知哪些SQL执行效率低下
[root@localhost mysql]# more slow-query.log
# Time: 081026 19:46:34
# User@Host: root[root] @ localhost []
# Query_time: 11 Lock_time: 0 Rows_sent: 1 Rows_examined: 6552961
select count(*) from t_user;
从日志中，可以发现查询时间超过5 秒的SQL，而小于5秒的没有出现在此日志中。
如果慢查询日志中记录内容很多，可以使用mysqldumpslow工具（MySQL客户端安装自带）来对慢查询日志进行分类汇总。mysqldumpslow对日志文件进行了分类汇总，显示汇总后摘要结果。
进入log的存放目录，运行
[root@mysql_data]#mysqldumpslow slow-query.log
Reading mysql slow query log from slow-query.log
Count: 2 Time=11.00s (22s) Lock=0.00s (0s) Rows=1.0 (2), root[root]@mysql
select count(N) from t_user;
mysqldumpslow命令
/path/mysqldumpslow -s c -t 10 /database/mysql/slow-query.log
这会输出记录次数最多的10条SQL语句，其中：
-s, 是表示按照何种方式排序，c、t、l、r分别是按照记录次数、时间、查询时间、返回的记录数来排序，ac、at、al、ar，表示相应的倒叙；
-t, 是top n的意思，即为返回前面多少条的数据；
-g, 后边可以写一个正则匹配模式，大小写不敏感的；
例如：
/path/mysqldumpslow -s r -t 10 /database/mysql/slow-log
得到返回记录集最多的10个查询。
/path/mysqldumpslow -s t -t 10 -g “left join” /database/mysql/slow-log
得到按照时间排序的前10条里面含有左连接的查询语句。
使用mysqldumpslow命令可以非常明确的得到各种我们需要的查询语句，对MySQL查询语句的监控、分析、优化是MySQL优化非常重要的一步。开启慢查询日志后，由于日志记录操作，在一定程度上会占用CPU资源影响mysql的性能，但是可以阶段性开启来定位性能瓶颈。
explain分析查询使用 EXPLAIN 关键字可以模拟优化器执行SQL查询语句，从而知道MySQL是如何处理你的SQL语句的。这可以帮你分析你的查询语句或是表结构的性能瓶颈。通过explain命令可以得到:
– 表的读取顺序
– 数据读取操作的操作类型
– 哪些索引可以使用
– 哪些索引被实际使用
– 表之间的引用
– 每张表有多少行被优化器查询
确认需求，先明确当前的运行状态，是否真的需要进行优化，别没事找事；
常见瓶颈：
绝大多数瓶颈在于I/O子系统；
若CPU很高，90%以上是因为索引不当；
发生swap时，可能因为内存分配太小或过大；
iowait太高时，想办法从索引角度入手优化，以及提高I/O设备性能，增加内存，减少排序，减少SELECT一次性读取数据量。
常用优化策略
瞬间并发很高，采用thread pool；
频繁order bygroup by，索引入手；
适当调整内存，不要太大或太小。一般ibp设置为50% ~ 70%为宜；
iowait高，加内存，提高iops，减少数据读写。
制定方案时，重点解决发生频率高的问题（量变更容易引起质变）；回顾反馈，整理文档，回顾总结，从零散资料中总结出规律，预防风险再次出现。
一般采用下面几个瓶颈分析工具：
绝大多数情况下，有经验的工程师靠sysstat工具集中的就足够了，很多问题一看现象大概就能知道瓶颈何在。
在MySQL层面，有哪些确认瓶颈的手段呢？
硬件、系统优化
我们继续MySQL优化之旅。先来看看从硬件以及OS层面，都有哪些可以优化的。首先主要是BIOS中关于CPU和内存的参数调整，其次是RAID方面的优化。
再来看看几个参考配置图：
1、CPU选择最大性能模式，避免节能模式导致性能不足。
2、关闭NUMA，降低swap概率。
3、采用RAID-10，并且选择FORCE WB。
在OS层面，可以有几个优化手段：
调整IO Scheduler
使用XFS
调整其他内核选项备
备注：
vm.swappiness，降低发生swap的几率；
vm.dirty_background_ratio & vm.dirty_ratio，避免瞬间大量I/O请求导致系统卡死。
从这个压测结果可以看到noop/deadline有明显优势。
这个io scheduler还可以在线修改的哦，还等神马？
echo deadline > /sys/block/sdc/queue/scheduler
在用PCIe SSD设备做测试时，XFS的IOPS能跑到ext4的4倍，表现非常好。
还有什么理由不用XFS呢？
xfs挂载参数：
/dev/sdc1 /data xfs defaults,noatime,nodiratime,nobarrier 0 0
格式化参数不用特别指定，默认的即可。
MySQL配置优化
前面讲到，给MySQL分配的内存不要太大或太小，那么多少合适呢。
首先，要搞清楚MySQL的内存都由哪些部分组成：
global buffers和oracle的SGA一个意思，就是全局一次分配，多个线程间共享。
thread buffers和oracle的PGA一个意思，每个线程单独分配，线程间不能相互共享，因此不要分配过大，避免内存不够使用，发生OOM。
原则： 对这些选项调整时，不要照猫画虎随便调整，要先做到心里有数，了解其具体作用才动手。
看看innodb_flush_log_at_trx_commit分别为0、1、2的性能对比如：
如果再启用binlog后的对比：
最后，再加上sync_binlog选项不同设置的对比：
备注： 这3个测试结果图均来自Percona。
结论&建议：
想要保证数据安全，就设置 trx_commit =1 & sync_binlog = 1
在slave上或非关键场景，可以都改成0
SCHEMA设计优化
接下来看看MySQL的模式（SCHEMA）设计优化要点：
要点：
默认地，使用InnoDB引擎，别上MyISAM给自己找事；
InnoDB必须要有自增（或类似自增）属性的主键；
不使用或少使用TEXT/BLOB列；
NOT NULL主要是为了优化索引效率；
若无特殊需求，均可使用latin1字符集，否则用utf8utf8mb4等大字符集保证通用性。
其他要点：
SQL优化
SQL优化层面有几个要点：
以及 COUNT(*)、大分页 的优化要点：
接下来，我们来看看EXPLAIN的结果中，有哪些关键信息要注意的。首先看下EXPLAIN结果的type列，都可以给我们什么信息：
再看看Extra列有哪些状态要引起重视：
MySQL的慢日志可用下面的工具来进行解析和管理：
pt-query-digest + Box Anemometer的案例，可以对slow log进行便捷管理。
关于JOIN优化有下面的几个关键点：
接下来看看哪些情况下，无法有效使用索引的：
再看看几个杀手级SQL的案例及其优化建议：
在平时，我们登入MySQL服务器后，如果觉得有问题，可以重点关注下面的一些线程状态：
其他优化
关于DBA的利器，常用percona-toolkit工具简介：
附：关于MariaDB及Percona分支版本的简介
Q&A
Q1: 多实例，进程会不会抢占？每个事例都是单独起的。
A：除了OS层面的资源会相互影响外，其他的不会。比如某个实例消耗特别多cpu资源的话，那么其他实例也会跟着受影响，这是必然的，除非用虚拟化等方式做隔离。
Q2: SSD建议单盘还是Raid？
A：如果不担心丢数据，单盘呗。如果怕丢的话，那显然不能单盘了。随机io很高的话，Raid5就不合适了。不过除非采用SSD，用Raid5也不怕了。事实上，Raid卡反而会影响（降低）SSD性能的发挥，但为了数据可靠性，没办法，还好影响不算特别大。
Q3: 能介绍一下哪些业务场景适合哪种RAID吗？
A：1、高随机IO，用Raid10；2、需要大容量，用Raid5。基本就这两种方案，事实上，因为SSD的IOPS性能已经很不错了，很多企业会选择直接用3块盘构建Raid5。毋庸置疑，上了PCIE SSD，可以避免很多问题，或者DBA可以少干很多活，至少可以缓解。
Q4: nnodb_buffer_pool_instances应该如何设置？
A：ibp的instance一般不超过8为宜，超过8的话，可能有反作用，不过多个instance的前提是，平均到每个instance的ibp不能小于2G，否则也没啥意义。
Q5: No text,or in compressed是指如果使用text的话，建议压缩吗？在压缩数据方面，叶老师有什么经验吗？
A：对的，建议不要在InnoDB中存储大量文本。需要的话，事先压缩好再存进去。不需要检索的文本，可以统统压缩后存进去，不是用InnoDB的压缩格式哦，是事先外部压缩后存储，文本内容在存储进去前先压缩好，不是用InnoDB的compressed这种row format，那会被坑惨的，性能损失9层，只有一半压缩比，还不如用TokuDB算了。
Q6: MariaDB和MySQL的优缺点，以及大神怎么看Maria有否取代MySQL的趋势？
A：想要取代还早呢，没那么容易，而且也没必要取代，作为补充就ok。除非哪天MySQL官方版本闭源了，或者支持很差。
Q7: 新的业务系统，是建议继续用MySQL5.5或以上，还是用mariaDB？
A：建议优先Percona 5.6，其次是MySQL 5.6，最末才是MariaDB。
Q8: 你们的数据库备份是用Percona的工具进行吗？每周一全备，每天一增量？用这些工具备份，会不会出现恢复不了的情况？这个有没有办法验证备份是否“正常” ？
A：工具则以xtrabackup为主，mysqldump为辅，数量不是巨大的话，每天一全备，大多有slave做热备，所以就没定期增备了。Mydumper也有些不太爽的，也比较小众就是，备份文件一定要做恢复性测试，千万别只备份不恢复测试，关键时刻会死人的。
Q9:恢复性测试怎么做 有流程方案指导一下吗？
A：简单的：数据恢复，简单查询验证数量，关键数据什么的；复杂的：搭测试环境呗。
Q10: 有没有什么效率较高的验证备份有效性的工具或者方法？还是只好把库恢复出来核对？
A：mysqldump或mydumper备份的文件，可以用grep简单快速验证；xtrabackup的话，只能看文件大小，或者做全量恢复了。