按期删除一些长时光未应用过的索引是一个异常好的习惯。

关于索引这个话题计算就此打住，最后要说一句，索引并不老是最好的对象，只有当索引赞助进步萌芽速度带来的好处大年夜于其带来的额外工作时，索引才是有效的。对于异常小的表，简单的全表扫描更高效。对于中到大年夜型的表，索引就异常有效。对于超大年夜型的表，建立和保护索引的价值随之增长，这时刻其他技巧也许更有效，比如分区表。最后的最后，explain 后再提测是一种美德。

特定类型萌芽优化

COUNT() 可能是被大年夜家误会最多的函数了，它有两种不合的感化，其一是统计某个列值的数量，其二是统计行数。统计列值瓯，请求列值长短空的，它不会统计 NULL。如不雅确认括号中的表达式弗成能为空时，实际上就是在统计行数。最简单的就是当应用 COUNT(*) 时，并不是我们所想象的那样扩大成所有的列，实际上，它会忽视所有的列而直接统计所有的行数。

我们最常见的误会也就在这儿，在括号内指定了一列却欲望统计结不雅是行数，并且还经常误认为前者的机能会更好。但实际并非如许，如不雅要统计行数，直接应用 COUNT(*)，意义清楚，且机能更好。

有时刻某些营业场景并不须要完全精确的 COUNT 值，可以用近似值来代替，EXPLAIN 出来的行数就是一个不错的近似值，并且履行 EXPLAIN 并不须要真正地去履行萌芽，所以成本异常低。平日来说，履行 COUNT() 都须要扫描大年夜量的行才能获取到精确的数据，是以很难优化，MySQL 层面还能做得也就只有覆盖索引了。如不雅不还能解决问题，只有大年夜架构层面解决了，比如添加汇总表，或者应用 redis 如许的外部缓存体系。

假设 MySQL 按照萌芽中的接洽关系次序 A、B 来进行接洽关系操作，那么可以用下面的伪代码表示 MySQL 若何完成这个萌芽：

outer_iterator = SELECT A.xx,A.c FROM A WHERE A.xx IN (5,6); 
 
outer_row = outer_iterator.next; 
 
while(outer_row) { 
 
inner_iterator = SELECT B.yy FROM B WHERE B.c = outer_row.c; 
 
inner_row = inner_iterator.next; 
 
while(inner_row) { 
 
output[inner_row.yy,outer_row.xx]; 
 
inner_row = inner_iterator.next; 
 
} 
 
outer_row = outer_iterator.next; 
 
} 

可以看到，最外层的萌芽是根据 A.xx 列来萌芽的，A.c 上如不雅有索引的话，全部接洽关系萌芽也不会应用。再看内层的萌芽，很明显 B.c 上如不雅有索引的话，可以或许加快萌芽，是以只须要在接洽关系次序中的第二张表的响应列上创建索引即可。 

3. 优 化 LIMIT 分页

当须要分页操作时，平日会应用 LIMIT 加上偏移量的办法实现，同时加上合适的 ORDER BY 字句。如不雅有对应的索引，平日效力会不错，不然，MySQL 须要做大年夜量的文件排序操作。

一个常见的问题是当偏移量异常大年夜的时刻，比如：LIMIT 10000 20 如许的萌芽，MySQL 须要萌芽 10020 笔记录然后只返回 20 笔记录，前面的 10000 条都将被摈弃，如许的价值异常高。

优化这种萌芽一个最简单的办法就是尽可能的应用覆盖索引扫描，而不是萌芽所有的列。然后根据须要做一次接洽关系萌芽再返回所有的列。对于偏移量很大年夜时，如许做的效力会晋升异常大年夜。推敲下面的萌芽：

SELECT film_id,description FROM film ORDER BY title LIMIT 50,5; 

SELECT film.film_id,film.description 
 
FROM film INNER JOIN ( 
 
SELECT film_id FROM film ORDER BY title LIMIT 50,5 
 
) AS tmp USING(film_id); 

这里的延迟接洽关系将大年夜大年夜晋升萌芽效力，让 MySQL 扫描尽可能少的页面，获取须要拜访的记录后在根据接洽关系列回原表萌芽所须要的列。

1. 优化 COUNT() 萌芽