两分钟让你彻底明白MySQL聚簇索引和非聚簇索引

聚簇索引啊，这个得搞明白。
InnoDB存储引擎里头，聚簇索引就是主键索引。
它决定了数据怎么物理存放。
叶子节点直接存数据全信息，不是存指针。
比如2 02 2 年，我在上海，有个student表，id是主键，那id就是聚簇索引。
我跑个sql，select from student where id=1 ，MySQL直接从聚簇索引里找到数据，不用再翻来覆去找。
这效率高吧？但改主键可费劲了，可能得动一大片数据。

非聚簇索引呢，也叫二级索引。
叶子节点存的是主键值，不是全数据。
得再通过主键索引去找数据。
还是student表，我给no加个唯一索引，那no就是非聚簇索引。
我查select no, name from student where no='test'，MySQL先在no索引里找到主键值，再回去找完整数据。
但要是查select no from student where no='test'，就省事了，直接在no索引里拿数据，不用回表。
这种情况下，看起来像聚簇索引，其实还是非聚簇的，因为它叶子节点还是存主键值。

总之，主键必是聚簇索引。
非聚簇索引叶子节点存主键值，得回表。
特殊情况，比如只查索引字段，可以不用回表。
MyISAM引擎没聚簇索引这概念，数据是按插入顺序存的。

给我一分钟，让你彻底明白MySQL聚簇索引和非聚簇索引

这事儿我得跟你唠唠。
十年前刚搞MySQL那会儿，真是把头发薅不少。
聚簇索引和非聚簇索引，听着挺玄乎，其实就那么回事儿。

我当年在杭州搞一个电商系统，表特别多，数据量也大。
有一段时间，查询特别慢，后台小哥天天哭。
我一看，嚯，几百个表里，好几个表的主键选得不对。
你想想，主键就是聚簇索引，数据就跟着它一块儿物理存储的。

聚簇索引，说白了，就是索引和数据放一块儿。
比如你那个学生表，用id当主键，id就是聚簇索引。
你用id查，数据库直接从硬盘上把那一行数据给你捞出来了，嗖一下，快得很。
我当年那个学生表，主键是自增的student_id，查一个学生信息，直接从索引里拿到数据，比啥都快。
这就叫“高效的数据访问”。

但是，聚簇索引也有坑。
你要是改主键，那数据得跟着挪位置。
我见过一次，一个表主键是用户名，用户改了昵称，数据库整个表都得重排，CPU直接飙升到2 00%。
那叫一个惨。
所以，主键选完了，就别轻易改，特别是大表，改起来跟要命似的。

非聚簇索引，就是索引和数据没放一块儿。
比如你那个学生表，用no当唯一索引，no就是非聚簇索引。
你用no查，数据库先在no的索引里找，找到no是'test'的那条记录，然后看它存的主键是多少，再回去student_id索引里找那一行数据。
这叫“回表”。
我当年那个电商系统，商品表有个sku_code，查询特别多，我就给它加了非聚簇索引。
这样查sku_code的时候，不用回表，直接查到就行。
这就叫“适用于频繁查询的列”。

不过，非聚簇索引也占地方。
每个非聚簇索引都得存一份主键，索引结构也得多一层。
我那个商品表，加了sku_code索引，硬盘空间直接多出来几百G。
所以，索引不是越多越好，看你啥场景下用得多。

总结一下：
主键一定是聚簇索引，别瞎改。
非聚簇索引需要回表，但可以加速某些查询。
选主键要慎重，别选经常变的列。
MyISAM没聚簇索引，那玩意儿现在基本不用了。

我当年踩的坑就是，一个表加了太多非聚簇索引，最后查询反而慢了，因为每次都要回表。
后来删了几个不常用的，才快起来。
所以，索引加之前，先想清楚你啥时候用，用得多不多。
别瞎加，也别瞎删。

你看，就这么回事儿。
别想得太复杂，实际用起来，场景为王。

mysql聚簇索引和非聚簇索引的区别

这就是坑：不要在非聚簇索引上进行范围查询。

实操提醒：确保聚簇索引用于主键查询和范围查询。