前面几篇文章和小伙伴们聊的基本上都是从索引的角度去优化 MySQL 查询，然而，索引创建的好，并不意味着查询就一定快，影响查询效率的因素特别多，今天我们就来聊一聊这些可能影响到查询的因素。

1. 查询流程

上篇文章结尾和小伙伴们留了一个小问题，就是关于 optimize table 命令，今天我想花点时间再来和小伙伴们聊一聊这个话题。

1. 删除空洞

[TOC]

关于 MySQL 中的索引，松哥前面已经和小伙伴们聊了不少了，不过在索引使用的时候，还是有一些需要注意的细节，如果忽略了这些细节，可能会让索引的使用效果大打折扣。

[TOC]

前面跟小伙伴们分享的索引相关的内容，基本上都是在 where 子句中使用索引，实际上，索引也还有另外一个大的用处，那就是在排序中使用索引，今天我们就来聊聊这个话题。

如果你的查询中用到了索引，这是一个进步，如果能够更进一步，用到了覆盖索引，那么就更牛了！当我们设计一个索引的时候，如果能够从一个更加全面的角度去设计这个索引，不仅考虑到 where 中的条件，还能够考虑到整个 SQL，那么无疑这个索引的设计将是非常成功的。

当然不能为了覆盖而覆盖。

前面一篇文章，松哥和大家聊了 MySQL 中的索引合并，虽然 MySQL 提供了索引合并机制来提升 SQL 执行的效率，然而在具体实践中，如果能避免发生索引合并是最好的，毕竟这是没办法的办法，是一个下下策。发生索引合并大概率是因为我们索引在设计的时候就有问题，设计好联合索引，我们就能在一定程度上避免发生索引合并问题。

[TOC]

在前面的文章中，松哥和小伙伴们分享了 MySQL 中，InnoDB 存储引擎的数据结构，小伙伴们知道，当我们使用索引进行搜索的时候，每一次的搜索都是在某一棵 B+Tree 中搜索的，如果使用了二级索引的话，可能还会涉及到回表。

[TOC]

我们在项目的具体实践中，有时候会遇到一些比较特殊的字段，例如身份证号码。

在上篇文章中，松哥和小伙伴们分享了 MySQL 的聚簇索引，也顺便和小伙伴们分析了为什么在 MySQL 中主键不应该使用随机字符串。但是主键不用随机字符串用什么？主键自增？主键自增就是最佳方案吗？有没有其他坑？今天我们就来讨论下这个话题。

为什么是再次理解呢？因为松哥之前写过相关的文章介绍过聚簇索引，但是感觉还不够，因此今天想再来和小伙伴们聊一聊这个话题。