mysql 优化（5）索引与排序

排序可能发生2种情况:

1: 对于覆盖索引,直接在索引上查询时,就是有顺序的, using index   ， 也可能是在查询时候沿着索引字段排序查询 。 此时排序代价低

2: 先取出数据,形成临时表做filesort(文件排序,但文件可能在磁盘上,也可能在内存中)

 

我们的争取目标-----取出来的数据本身就是有序的! 利用索引来排序.

 

比如: goods商品表, (cat_id,shop_price)组成联合索引,

where cat_id=N order by shop_price ,可以利用索引来排序,

select goods_id,cat_id,shop_price from goods order by shop_price;

// using where,按照shop_price索引取出的结果,本身就是有序的.

 

select goods_id,cat_id,shop_price from goods order by click_count;

// using filesort 用到了文件排序,即取出的结果再次排序

mysim  执行时全找到 然后排序 然后去回行取  只要有索引走索引 其实不大   联合索引 点击量 和 id  可以建索引  

innodb    就在叶子底下

重复索引无意义 

冗余索引 提高效率 两个索引会发挥场合不同 租用不一样 左键；  

索引的碎片和维护

大网站基本不去删除数据 在磁盘上会产生一个洞； 并且不容易被再次利用的短字节会不容易再次利用 

内存的碎片化 ；

修复漏洞 

在长期的数据更改过程中, 索引文件和数据文件,都将产生空洞,形成碎片.

我们可以通过一个nop操作(不产生对数据实质影响的操作), 来修改表.

比如: 表的引擎为innodb , 可以 alter table xxx engine innodb  本质上对数据并没有任何影响 来修改表   但是会重新整理一遍数据

 

optimize table 表名 ,也可以修复.  优化这张表 帮你去修复 ； 

 

注意: 修复表的数据及索引碎片,就会把所有的数据文件重新整理一遍,使之对齐.

这个过程,如果表的行数比较大,也是非常耗费资源的操作.

所以,不能频繁的修复.  周期较长一点！！！！

 

如果表的Update操作很频率,可以按周/月,来修复.

如果不频繁,可以更长的周期来做修复.