关于MySQL的表最多能建多少个索引

老实说，看到这个问题的瞬间我是有点懵的状态，我原本只只知道Innodb引擎的表，最多只有1017列（至于为什么不是1024，可以百度一下）， 下意识地就觉得索引最多可以创建1017个，但是仔细一想，不对啊， 索引可以是复合索引啊，那绝对不止1017，难道索引的数量会是1个很大的数据吗? 再仔细想想，以Innodb的抠门个性，不可能会是1个大的数值，然后去翻了下官方文档，看到如下内容。 This section describes limits for InnoDB tables, indexes, tablespaces, and other aspects of the InnoDB storage engine. 上面就清楚地写着， 1个表最大只能创建64个2级索引。 加上主键，那么上面的问题就有了答案，65个。 我试着填了65 的答案上去之后，点击提交，网站给我的回复是错误，我花了1个积分查看了正确答案【我回答是为了赚积分，没想到还赔了1个积分！！】 网站给的答案是：16. 纳尼！ 怎么比官方的64还低！ 然后我往刚才官方文档下面拉一拉，发现看了一个跟16的数字有关的描述： A maximum of 16 columns is permitted for multicolumn indexes. Exceeding the limit returns an error. ERROR 1070 (42000): Too many key parts specifiedmax 16 parts allowed 上面写的是，复合索引最多只能16列，超过就会报错。 有意思的是，然后我又在百度上搜索了相关的问题，没想到好几个答案都是写着16，我觉得16的应该是被别人给误导了，这个网站出题的这个作者，应该 也是百度了下，看到答案是16就给了个16的答案。 有心反馈这个问题，可惜没有渠道反馈，然后就在这里写下一点心得，关于技术的东西，发现有疑问或者怀疑的时候， 还是得翻一翻官方文档为好，起码能保证不会出错。

在实际开发中使用数据库时，难免会遇到一些大表数据，对这些数据进行查询时，有时候SQL会查询得特别慢，这时候，有经验的老师傅会告诉你，你看一下哪几个字段查的多，加一个索引就好了。

那么，怎么合理地建立索引呢？这里分享一下我的一些经验，如有不妥之处，欢迎批评指正。

1、不要盲目建立索引 ， 先分析再创建

索引虽然能大幅度提升我们的查询性能，但也要知道，在你进行增删改时，索引树也要同样地进行维护。所以，索引不是越多越好，而是按需建立。最好是在一整块模块开发完成后，分析一下，去针对大多数的查询，建立联合索引。

2、使用联合索引尽量覆盖多的条件

这是说在一个慢sql里假如有五个where ，一个 order by ，那么我们的联合索引尽量覆盖到这五个查询条件，如果有必要，order by 也覆盖上 。

3、小基数字段不需要索引

这个意思是，如果一张表里某个字段的值只有那么几个，那么你针对这个字段建立的索引其实没什么意义，比如说，一个性别字段就两种结果，你建了索引，排序也没什么意思（也就是索引里把男女给分开了）

所以说，索引尽量选择基数大的数据去建立，能最大化地利用索引

4、长字符串可以使用前缀索引

我们建立索引的字段尽量选择字段类型较小的，比如一个varchar(20)和varchar(256)的，我们在20的上面建立的索引和在256上就有明显的差距（字符串那么长排序也不好排呀，唉）。

当然，如果一定是要对varchar(256)建立索引,我们可以选择里面的前20个字符放在索引树里（这里的20不绝对，选择能尽量分辨数据的最小字符字段设计），类似这样KEY index(name(20),age,job) ，索引只会对name的前20个字符进行搜索，但前缀索引无法适用于order by 和 group by。

5、对排序字段设计索引的优先级低

如果一个SQL里我们出现了范围查找，后边又跟着一个排序字段，那么我们优先给范围查找的字段设置索引，而不是优先排序。

6、如果出现慢SQL，可以设计一个只针对该条SQL的联合索引。

不过慢SQL的优化，需要一步步去进行分析，可以先用explain查看SQL语句的分析结果，再针对结果去做相应的改进。explain的东西我们下次再讲。

PS：在 select 语句之前增加 explain 关键字，MySQL 会在查询上设置一个标记，执行查询会返回执行计划的信息，而不是 执行这条SQL。

---