MySQL索引是什么

这就是坑：过度索引，忽略选择性，可能导致性能下降。

别信：认为索引越多越好，忽略了写入成本。

别这么干：不分析查询模式，随意创建索引。
实操提醒：先EXPLAIN，再索引，关注索引选择性。

Mysql 索引简介

说白了，MySQL索引就像是图书馆的目录，它能帮你快速找到书页，而不是一页一页地翻。
其实很简单，索引就是数据库中一种数据结构，用于加快数据检索速度。

先说最重要的，索引的核心作用就是加速查询。
比如去年我们跑的那个项目，表里大概有3 000万条数据，没有索引的话，每次查询都要全表扫描，效率极低。
而有了索引，就像是有了目录，查询速度能快上几十倍。
另外一点，索引还能优化排序操作，因为如果索引已经包含了排序字段，数据库就可以直接利用这个索引来进行排序，而不需要再进行一次全表的排序操作。

我一开始也以为，所有的索引都是一样的，后来发现不对，索引其实有好多不同的模型，比如哈希模型、数组模型和N叉树模型（B+树）。
哈希模型适合等值查询，比如查找某个特定的ID；数组模型适合静态数据，可以进行快速的范围查询；而B+树模型是MySQL InnoDB的默认索引结构，它支持高效的范围查询，且减少磁盘I/O。

等等，还有个事，InnoDB的索引实现中，有一种叫索引组织表（IOT），它把表数据和索引存储在一起，如果表没有定义主键，InnoDB会自动生成一个ROWID作为聚簇索引。
而B+树索引结构中，非叶子节点存储键值和子节点指针，叶子节点存储数据记录或主键值。

索引优化要点也很关键，比如覆盖索引可以避免回表查询，提高效率；索引选择性高的列更适合建索引；联合索引要遵循最左前缀原则。
但要注意，索引也有局限性，比如会增加空间开销，可能会降低写入性能，还有可能在某些场景下失效。

所以，合理设计索引，比如使用覆盖索引和联合索引，避免失效场景，是提升数据库性能的关键。
你觉得还有哪些方法可以进一步提升索引效率呢？

一篇文章讲清楚MySQL的聚簇/联合/覆盖索引、回表、索引下推

哎哟，咱们聊聊MySQL里那些索引的玩意儿，这玩意儿啊，就像咱们生活中的各种工具，用得好能事半功倍，用不好那可就麻烦了。

先说聚簇索引，这玩意儿啊，就像咱们家的大衣柜，把所有的衣服都按颜色、款式整齐地放在一起。
在MySQL里，InnoDB引擎的聚簇索引就是这样的，它把一整行数据都存放在索引的叶子节点里。
比如说，如果你的表里有个主键索引，那这个主键索引就是聚簇索引。
没有主键？没关系，MySQL会给你整一个隐藏的主键，然后这个隐藏的主键就是聚簇索引。
这玩意儿的好处就是，做范围查询的时候，效率特别高。

那非聚簇索引呢？这就好比咱们家里的抽屉，每个抽屉只放一类东西，比如一个抽屉放袜子，一个放内裤。
在MySQL里，非聚簇索引的叶子节点只存索引字段和主键ID，不是完整的行数据。
这样做的目的是为了节省空间，但是查询的时候，你得先找到主键ID，然后再去抽屉里找到完整的行数据。

再来说联合索引，这就像咱们家的多功能柜，一个柜子可以放衣服、鞋子、杂物。
联合索引就是由多个字段组成的索引，创建的时候得指定字段的顺序。
这个顺序很重要，决定了索引的排序方式和查询时的匹配原则。
联合索引的好处是，能减少扫描的行数，提高查询效率。
但是，你得注意最左匹配原则，就是查询条件中的字段顺序必须跟联合索引的字段顺序一致，或者至少是一部分一致。

然后是覆盖索引和回表查询。
覆盖索引就像是多功能柜里的抽屉，你直接从抽屉里就能拿到你想要的东西，不需要打开柜子。
在MySQL里，如果查询的字段都在索引里，那就不需要回表查询完整的行数据，直接用索引就能解决问题。
而回表查询就像是打开柜子找东西，效率低，还费事。

最后说说索引下推。
这就像是咱们在购物的时候，店员直接在货架上帮你筛选，而不是让你自己去翻。
MySQL5 .6 以后，索引下推这个特性就出来了，它允许在索引层面做更多的条件过滤，减少回表查询的行数，提高查询效率。

总之，这些索引啊，都是为了让数据库查询更高效。
但是，用得好不好，还得看具体情况，得根据你的需求来定制。
说实话，我当时也没想明白这些，后来慢慢实践，慢慢就明白了。