一、MySQL 索引原理

1. 索引的定义

索引是一种数据结构，通过建立索引可以快速定位和访问数据库中的数据。

2. B-Tree 索引

MySQL 使用 B-Tree（B 树）作为默认的索引类型。B-Tree 是一种平衡多路搜索树，它能够在对数时间内完成查找、插入和删除操作。

3. 索引分类

1) 主键索引

用于唯一标识每条记录，并自动创建。主键索引不允许为空值。

2) 唯一索引

用于保证列中的值是唯一的。

3) 普通索引

最基本的索引类型，没有唯一性或主键约束。

4. 索引存储方式

1) 聚集索引

数据行的物理顺序与索引的逻辑顺序一致。InnoDB 存储引擎的主键索引就是聚集索引。

2) 非聚集索引

数据行的物理顺序与索引的逻辑顺序不一致。InnoDB 存储引擎的普通索引就是非聚集索引。

5. 创建索引的注意事项

1) 选择适当的列

索引应选择区分度高的列，能够尽量减少查询时遍历的数据量。

2) 避免过多的索引

索引会占用磁盘空间并影响写操作性能，所以不宜创建过多的索引。

3) 避免对索引列进行计算

对索引列进行计算会导致无法使用索引。

二、MySQL 索引优化策略

1. 分析查询语句

了解查询的条件和顺序，根据查询的特点来选择合适的索引类型和列。

2. 联合索引

根据多个列的组合来创建索引，可以使得多个条件同时生效，提高查询效率。

3. 索引覆盖

选择合适的索引以实现索引覆盖，即查询结果可以从索引中获取，而不需要回表查询数据行。

4. 避免全表扫描

通过合理的索引设计和查询条件优化，避免全表扫描，提高查询效率。

5. 定期维护索引

删除不再使用的索引，避免索引过多导致查询性能下降。同时，定期进行索引重建和碎片整理，提高索引的利用率和查询性能。

6. 使用 EXPLN 分析查询计划

通过使用 EXPLAIN 语句来查看查询计划，了解查询的执行情况和可能存在的性能问题。

7. 合理使用索引提示

对于复杂的查询语句，可以通过使用索引提示（IndexHint）来指定使用特定的索引，以优化查询性能。

总结

MySQL 索引是提高数据库查询性能的重要手段。Java 开发者应当了解 MySQL 索引的原理和优化策略，并根据具体场景选择合适的索引类型和列，以提高数据库的查询效率和响应速度。同时，定期维护索引，并使用工具进行性能分析和调优，以确保系统的稳定性和可靠性。

---

「Mysql索引原理（六）」聚簇索引

本节课主要关注InnoDB，但是这里讨论的原理对于任何支持聚簇索引的存储引擎都是适用的。

叶子节点包含了全部数据，其他节点只包含索引列。InnoDB将通过主键聚集数据，也就是说上图中的“被索引的列”就是主键列。如果没有定义主键，InnoDB会选择一个唯一的非空索引代替。如果没有这样的索引InnoDB会隐式定义一个主键来作为聚簇索引。

如果主键比较大的话，那辅助索引将会变的更大，因为 辅助索引的叶子存储的是主键值；过长的主键值，会导致非叶子节点占用占用更多的物理空间

所以建议使用int的auto_increment作为主键

主键的值是顺序的，所以 InnoDB 把每一条记录都存储在上一条记录的后面。当达到页的最大值时，下一条记录就会写入新的页中。一旦数据按照这种顺序的方式加载，主键页就会近似于被顺序的记录填满。聚簇索引的数据的物理存放顺序与索引顺序是一致的，即：只要索引是相邻的，那么对应的数据一定也是相邻地存放在磁盘上的。如果主键不是自增id，那么可以想 象，它会干些什么，不断地调整数据的物理地址、分页，当然也有其他一些措施来减少这些操作，但却无法彻底避免。但，如果是自增的，那就简单了，它只需要一 页一页地写，索引结构相对紧凑，磁盘碎片少，效率也高。因为MyISAM的主索引并非聚簇索引，那么他的数据的物理地址必然是凌乱的，拿到这些物理地址，按照合适的算法进行I/O读取，于是开始不停的寻道不停的旋转。聚簇索引则只需一次I/O。（强烈的对比）不过，如果涉及到大数据量的排序、全表扫描、count之类的操作的话，还是MyISAM占优势些，因为索引所占空间小，这些操作是需要在内存中完成的。

MyISM使用的是非聚簇索引， 非聚簇索引的两棵B+树看上去没什么不同 ，节点的结构完全一致只是存储的内容不同而已，主键索引B+树的节点存储了主键，辅助键索引B+树存储了辅助键。表数据存储在独立的地方，这两颗B+树的叶子节点都使用一个地址指向真正的表数据，对于表数据来说，这两个键没有任何差别。由于 索引树是独立的，通过辅助键检索无需访问主键的索引树 。所以说，聚簇索引性能最好而且具有唯一性，所以非常珍贵，必须慎重设置。 一般要根据这个表最常用的SQL查询方式来进行选择，某个字段作为聚簇索引，或组合聚簇索引 ，这个要看实际情况。

聚簇索引和非聚簇索引的数据分布有区别，主键索引和二级索引的数据分布也有区别，通常会让人感到困扰和以外，下面通过一个列子来讲解InnoDB和MyISAM是如何存储数据的：

该表的主键取值1~，按照随机顺序插入并使用optimize table命令做了优化。换句话说，数据在磁盘上的存储方式已是最优，但行的顺序是随机的。列col2的值是从1~100之间随机赋值，所以有很多重复的值。

MyISAM的数据分布很简单，所以先介绍它。MyISAM按照数据插入的顺序存储在磁盘上，如下图所示：

在行的旁边显示行号，从0开始递增。因为行是定长的，所以MyISAM可以从表的开头跳过所需的字节找到需要的行。

col2上的索引

事实上，MyISAM中主键索引和其他索引在结构上没有什么不同。主键索引就是一个名为PRIMARY的唯一非空索引。

InnoDB支持聚簇索引，所以使用不同的方式存储同样的数据。

第一眼看上去，感觉和前面的没什么区别，但是该图显示了整个表，而不是只有索引。因为在InnoDB中，聚簇索引就是表，所以不像MyISAM那样需要独立的行存储，这也是为什么MyISAM索引和数据结构是分开的。聚簇索引的每一个叶子节点都包含了主键值。事务ID、用于事务和MVCC的回滚指针以及所有的剩余列。如果主键是一个列前缀索引，InnoDB也会包含完整的主键列和剩下的其他列。还有一点和MyISAM不同的是，InnoDB的二级索引和聚簇索引很不相同。InnoDB的二级索引的叶子节点中存储的不是“行指针”，而是主键值，并以此作为指向行的“指针”。这样的策略减少了当出现行移动或者数据页分裂时二级索引的维护工作。使用主键值当作指针会让二级索引占用更多的空间，换来的好处是，InnoDB在移动时无需更新二级索引中的这个“指针”。

我们在来看一下 col2索引 。

每一个叶子节点包含了索引列（这里是col2），紧接着是主键值（col1），上图我们省略了非叶子节点这样的细节。InnoDB非叶子节点包含了索引列和一个指向下一级节点的指针。最后，以一张图表示InnoDB和MyISAM保存数据和索引的区别。

前面讲过，最好使用AUTO_INCREMENT自增列来聚集数据，避免随机的、不连续的、值分布范围大的列做聚簇索引，特别是对于I/O密集型的应用。例如，从性能角度考虑，使用UUID来作为聚簇索引则会很糟糕：他使得聚簇索引的插入变得完全随机，这是最坏的情况，使得数据没有任何聚集特性。

为了展示这一点，我们做两个基准测试：

1、使用证书ID插入userinfo表，和uuid作为主键的userinfo_uuid表

userinfo_uuid表跟userinfo表除了主键给为UUID，其他字段都一样

测试这两个表的设计，首先在一个有足够内存容纳索引的服务器上向这两个表各插入100万条记录。然后向两个表继续插入300万数据，使索引的大小超过服务器的内存容量。测试结果如下：

向UUID主键插入行不仅花费的时间更长，而且索引占用的空间也更大。这一方面是由于主键字段更长，另一方面毫无疑问是由于页分裂和碎片导致的。

为了明白为什么会这样，来看看往第一个表中插入数据时，索引发生了什么变化。

自整型主键插入

因为主键是顺序的，所以InnoDB把每一条记录都存在上一条记录的后面。当达到页的最大容量后，下一条记录就会写入到新的页中。一旦数据按照这种顺序的方式加载，主键页就会近似于被顺序的记录填满，这也正是所期望的结果。

UUID插入

因为新行的主键值不一定比之前插入的大，所以InnoDB无法简单的总是把新行插入到索引的最后，而是需要为新的行寻找合适的位置，通常是已有数据的中间位置，并且分配空间。这会正价很多的额外工作，并导致数据分布不够优化。

缺点：

把这些随机值载入到聚簇索引后，也许需要做一次OPTIMIZE TABLE来重建表并优化页的填充。

结论 ：使用InnoDB时应尽可能地按主键顺序插入数据，并且尽可能地单调增加聚簇键的值来插入新行。

如何正确合理的建立MYSQL数据库索引

索引是快速搜索的关键。 MySQL索引的建立对于MySQL的高效运行是很重要的。 下面介绍几种常见的MySQL索引类型。 在数据库表中，对字段建立索引可以大大提高查询速度。 假如我们创建了一个 mytable表：CREATE TABLE mytable( IDINTNOT NULL, username VARCHAR(16) NOT NULL ); 我们随机向里面插入了条记录，其中有一条：5555, admin。 在查找username=admin的记录 SELECT * FROMmytable WHERE username=‘admin‘;时，如果在username上已经建立了索引，MySQL无须任何扫描，即准确可找到该记录。 相反，MySQL会扫描所有记录，即要查询条记录。 索引分单列索引和组合索引。 单列索引，即一个索引只包含单个列，一个表可以有多个单列索引，但这不是组合索引。 组合索引，即一个索包含多个列。 MySQL索引类型包括：（1）普通索引这是最基本的索引，它没有任何限制。 它有以下几种创建方式：◆创建索引CREATE INDEXindexName ON mytable(username(length)); 如果是CHAR，VARCHAR类型，length可以小于字段实际长度；如果是BLOB和TEXT类型，必须指定 length，下同。 ◆修改表结构ALTERmytable ADDINDEX[indexName] ON (username(length))◆创建表的时候直接指定CREATE TABLE mytable( IDINTNOT NULL, username VARCHAR(16) NOT NULL, INDEX [indexName] (username(length)) ); 删除索引的语法：DROP INDEX [indexName] ON mytable;（2）唯一索引它与前面的普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值。 如果是组合索引，则列值的组合必须唯一。 它有以下几种创建方式：◆创建索引CREATE UNIQUE INDEX indexName ON mytable(username(length))◆修改表结构ALTERmytable ADDUNIQUE [indexName] ON (username(length))◆创建表的时候直接指定CREATE TABLE mytable( IDINTNOT NULL, username VARCHAR(16) NOT NULL, UNIQUE [indexName] (username(length)) ); （3）主键索引它是一种特殊的唯一索引，不允许有空值。 一般是在建表的时候同时创建主键索引：CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, PRIMARY KEY(ID) ); 当然也可以用 ALTER命令。 记住：一个表只能有一个主键。 （4）组合索引为了形象地对比单列索引和组合索引，为表添加多个字段：CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, city VARCHAR(50) NOT NULL, age INT NOT NULL ); 为了进一步榨取MySQL的效率，就要考虑建立组合索引。 就是将 name, city, age建到一个索引里：ALTER TABLE mytable ADDINDEX name_city_age (name(10),city,age); 建表时，usernname长度为 16，这里用 10。 这是因为一般情况下名字的长度不会超过10，这样会加速索引查询速度，还会减少索引文件的大小，提高INSERT的更新速度。 如果分别在 usernname，city，age上建立单列索引，让该表有3个单列索引，查询时和上述的组合索引效率也会大不一样，远远低于我们的组合索引。 虽然此时有了三个索引，但MySQL只能用到其中的那个它认为似乎是最有效率的单列索引。 建立这样的组合索引，其实是相当于分别建立了下面三组组合索引：usernname,city,age usernname,city usernname 为什么没有 city，age这样的组合索引呢？这是因为MySQL组合索引“最左前缀”的结果。 简单的理解就是只从最左面的开始组合。 并不是只要包含这三列的查询都会用到该组合索引，下面的几个SQL就会用到这个组合索引：SELECT * FROMmytable WHREE username=admin AND city=郑州 SELECT * FROMmytable WHREE username=admin 而下面几个则不会用到：SELECT * FROM mytable WHREE age=20 AND city=郑州 SELECT * FROM mytable WHREE city=郑州（5）建立索引的时机到这里我们已经学会了建立索引，那么我们需要在什么情况下建立索引呢？一般来说，在WHERE和JOIN中出现的列需要建立索引，但也不完全如此，因为MySQL只对<，<=，=，>，>=，BETWEEN，IN，以及某些时候的LIKE才会使用索引。 例如：SELECT FROM mytable t LEFT JOINmytable m ON = WHERE =20 AND =‘郑州‘ 此时就需要对city和age建立索引，由于mytable表的userame也出现在了JOIN子句中，也有对它建立索引的必要。 刚才提到只有某些时候的LIKE才需建立索引。 因为在以通配符%和_开头作查询时，MySQL不会使用索引。 例如下句会使用索引：SELECT * FROM mytable WHERE username like‘admin%‘ 而下句就不会使用：SELECT * FROM mytable WHEREt Name like‘%admin‘ 因此，在使用LIKE时应注意以上的区别。 （6）索引的不足之处上面都在说使用索引的好处，但过多的使用索引将会造成滥用。 因此索引也会有它的缺点：◆虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。 因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件。 ◆建立索引会占用磁盘空间的索引文件。 一般情况这个问题不太严重，但如果你在一个大表上创建了多种组合索引，索引文件的会膨胀很快。 索引只是提高效率的一个因素，如果你的MySQL有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询语句。 （7）使用索引的注意事项使用索引时，有以下一些技巧和注意事项：◆索引不会包含有NULL值的列只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。 所以我们在数据库设计时不要让字段的默认值为NULL。 ◆使用短索引对串列进行索引，如果可能应该指定一个前缀长度。 例如，如果有一个CHAR(255)的列，如果在前10个或20个字符内，多数值是惟一的，那么就不要对整个列进行索引。 短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。 ◆索引列排序MySQL查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。 因此数据库默认排序可以符合要求的情况下不要使用排序操作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。 ◆like语句操作一般情况下不鼓励使用like操作，如果非使用不可，如何使用也是一个问题。 like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。 ◆不要在列上进行运算select * from users where YEAR(adddate)<2007; 将在每个行上进行运算，这将导致索引失效而进行全表扫描，因此我们可以改成select * from users where adddate<‘2007-01-01’; ◆不使用NOT IN和<>操作以上，就对其中MySQL索引类型进行了介绍。 提高mysql千万级大数据SQL查询优化30条经验（Mysql索引优化注意）1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。 2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：select id from t where num is null可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：select id from t where num=03.应尽量避免在 where 子句中使用!=或<>操作符，否则引擎将放弃使用索引而进行全表扫描。 4.应尽量避免在 where 子句中使用or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：select id from t where num=10 or num=20可以这样查询：select id from t where num=10 union all select id from t where num= 和 not in 也要慎用，否则会导致全表扫描，如：select id from t where num in(1,2,3)对于连续的数值，能用 between 就不要用 in 了：select id from t where num between 1 and 36.下面的查询也将导致全表扫描：select id from t where name like ‘李%‘若要提高效率，可以考虑全文检索。 7. 如果在 where 子句中使用参数，也会导致全表扫描。 因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。 然 而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。 如下面语句将进行全表扫描：select id from t where num=@num可以改为强制查询使用索引：select id from t with(index(索引名)) where num=@num8.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。 如：select id from t where num/2=100应改为:select id from t where num=100*29.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。 如：select id from t where substring(name,1,3)=‘abc‘，name以abc开头的id应改为:select id from t where name like ‘abc%‘10.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。 11.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。 12.不要写一些没有意义的查询，如需要生成一个空表结构：select col1,col2 into #t from t where 1=0这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：create table #t(...)13.很多时候用 exists 代替 in 是一个好的选择：select num from a where num in(select num from b)用下面的语句替换：select num from a where exists(select 1 from b where num=)14.并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。 15. 索引并不是越多越好，索引固然可 以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。 一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有 必要。 16. 应尽可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。 若应用系统需要频繁更新 clustered 索引数据列，那么需要考虑是否应将该索引建为 clustered 索引。 17.尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。 这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。 18.尽可能的使用 varchar/nvarchar 代替 char/nchar ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。 19.任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。 20.尽量使用表变量来代替临时表。 如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。 21.避免频繁创建和删除临时表，以减少系统表资源的消耗。 22.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。 但是，对于一次性事件，最好使用导出表。 23.在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。 24.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。 25.尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。 26.使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。 27. 与临时表一样，游标并不是不可使 用。 对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。 在结果集中包括“合计”的例程通常要比使用游标执行的速度快。 如果开发时 间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。 28.在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。 无需在执行存储过程和触发器的每个语句后向客户端发送DONE_IN_PROC 消息。 29.尽量避免大事务操作，提高系统并发能力。 30.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。 如何正确合理的建立MYSQL数据库索引标签：