一文搞定MySQL性能调优( 二 ) _MySQL

磁盘调度策略
1.cfq (完全公平队列策略，Linux2.6.18之后内核的系统默认策略)
该模式按进程创建多个队列，各个进程发来的IO请求会被cfq以轮循方式处理，对每个IO请求都是公平的。该策略适合离散读的应用。
2.deadline (截止时间调度策略)
deadline，包含读和写两个队列，确保在一个截止时间内服务请求（截止时间是可调整的），而默认读期限短于写期限。这样就防止了写操作因为不能被读取而饿死的现象，deadline对数据库类应用是最好的选择。
3.noop (电梯式调度策略)
noop只实现一个简单的FIFO队列，倾向饿死读而利于写，因此noop对于闪存设备、RAM及嵌入式系统是最好的选择。
4.anticipatory (预料I/O调度策略)
本质上与deadline策略一样，但在最后一次读操作之后，要等待6ms，才能继续进行对其它I/O请求进行调度。它会在每个6ms中插入新的I/O操作，合并写入流，用写入延时换取最大的写入吞吐量。anticipatory适合于写入较多的环境，比如文件服务器。该策略对数据库环境表现很差。
查看调度策略的方法：
cat /sys/block/devname/queue/scheduler
修改调度策略的方法：
echo <schedulername> > /sys/block/devname/queue/scheduler
MySQL的参数配置请阅读笔者的CSDN博客《MySQL服务器参数配置》，点击跳转。如无法跳转，请查看原文即可查看。
MySQL表结构与SQL优化索引优化规则
结合笔者的上一篇博客——《彻底搞懂MySQL的索引》，可以很容易理解索引优化的原理。
1.使用最左前缀规则
如果使用联合索引，要遵守最左前缀规则。即要求使用联合索引进行查询，从索引的最左前列开始，不跳过索引中的列并且不能使用范围查询(>、<、between、like) 。

文章插图

索引失效示例
2.模糊查询不能利用索引(like '%XX'或者like '%XX%')
假如索引列code的值为'AAA','AAB','BAA','BAB'，如果where code like '%AB'条件，由于条件前面是模糊的，所以不能利用索引的顺序，必须逐个查找，看是否满足条件。这样会导致全索引扫描或者全表扫描。
如果是where code like 'A%'，就可以查找code中A开头的数据，当碰到B开头的数据时，就可以停止查找了，因为后面的数据一定不满足要求，这样可以提高查询效率。
3.不要过多创建索引
过多的索引会占用更多的空间，而且每次增、删、改操作都会重建索引。
在一般的互联网场景中，查询语句的执行次数远远大于增删改语句的执行次数，所以重建索引的开销可以忽略不计。但在大数据量导入时，可以考虑先删除索引，批量插入数据，然后添加索引。

尽量扩展索引，比如现有索引(a)，现在又要对(a,b)进行索引，那么只需要修改索引(a)即可，避免不必要的索引冗余。

4.索引长度尽量短
短索引可以节省索引空间，使查找的速度得到提升，同时内存中也可以装载更多的索引键值。

太长的列，可以选择建立前缀索引

5.索引更新不能频繁
更新非常频繁的数据不适宜建索引，因为维护索引的成本。
6.索引列不能参与计算
不要在索引列上做任何的操作，包括计算、函数、自动或者手动类型的转换，这样都会导致索引失效。
比如，where from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本太大。所以语句应该写成where create_time = unix_timestamp(’2014-05-29’) 。
查询时的优化
小表驱动大表