Mysql索引底层数据结构与算法

目录

1. 索引概念

2. 索引结构

3. MyISAM和InnoDB的索引实现

4. 联合索引

5. 什么情况下应不建或少建索引

6. MySql在建立索引优化时需要注意的问题

---

1. 索引概念

索引概念: 索引是帮助MySQL高效获取数据的排好序的数据结构, 更通俗的说数据库索引好比是一本书的目录，能加快数据库的查询速度

索引结构: 二叉树, 红黑树, HASH, BTREE

数据库索引为什么要用BTREE而不用红黑树, 二叉树, HASH呢?

1. AVL树和红黑树这些二叉树结构的数据结构可以达到最高的查询效率这是毋庸置疑的。

    既然如此，那么数据库索引为什么不用 AVL树或者红黑树呢？

    这就牵扯到一个问题了, AVL数和红黑树基本都是存储在内存中才会使用的数据结构，那磁盘中会有什么不同呢？

    由于操作系统读写磁盘的基本单位是扇区，而文件系统的基本单位是簇(Cluster)。也就是说，磁盘读写有一个最少内容的限制，即使我们只需要这个簇上的一个字节的内容，也需要把一整个簇上的内容读完。

    那么，现在问题就来了

   一个父节点只有 2 个子节点，并不能填满一个簇上的所有内容啊？那多余的内容岂不是要浪费了？我们怎么才能把浪费的这部分内容利用起来呢？答案就是 B+ 树。

   由于 B+ 树分支比二叉树更多，所以相同数量的内容，B+ 树的深度更浅，深度更浅也就代表这磁盘 io 次数少！数据库设计的时候 B+ 树有多少个分支都是按照磁盘一个簇上最多能放多少节点设计的啊！

   所以，涉及到磁盘上查询的数据结构一般都用 B+ 树

2. 二叉树就更不用说了, 有红黑数相同的缺陷外, 在一些极端的数据规则下, 二叉树的深度会变得很深, 使IO次数大大增加

3. Hash的话是存在致命缺陷的, 也就是没有办法进行范围查询和Hash冲突,所以在一些不存在范围查询的字段上可以使用Hash来作为索引结构

2. 索引结构

2.1 B-Tree

• 度(Degree)-节点的数据存储个数
• 叶节点具有相同的深度
• 叶节点的指针为空
• 节点中的数据key从左到右递增排列

2.2 B+Tree

• 非叶子节点不存储data，只存储key，可以增大度
• 叶子节点不存储指针
• 顺序访问指针，提高区间访问的性能

B+Tree索引的性能分析

• 一般使用磁盘I/O次数评价索引结构的优劣
• 预读：磁盘一般会顺序向后读取一定长度的数据(页的整数倍)放入内存
• 局部性原理：当一个数据被用到时，其附近的数据也通常会马上被使用
• B+Tree节点的大小设为等于一个页，每次新建节点直接申请一个页的空间，这样就保证一个节点物理上也存储在一个页里，就实现了一个节点的载入只需一次I/O
• B+Tree的度d一般会超过100，因此h非常小(一般为3到5之间)

3. MyISAM和InnoDB的索引实现

3.1 MyISAM索引实现(非聚集)

注意: MyISAM索引文件和数据文件是分离的

3.2 InnoDB索引实现(聚集)

• 数据文件本身就是索引文件
• 表数据文件本身就是按B+Tree组织的一个索引结构文件
• 聚集索引-叶节点包含了完整的数据记录
• 为什么InnoDB表必须有主键，并且推荐使用整型的自增主键？
• 为什么非主键索引结构叶子节点存储的是主键值？(一致性和节省存储空间)
   

问题: InnoDB 的辅助索引叶子节点为什么不直接保存的记录地址而要存主键键值?

4. 联合索引

联合索引: 联合索引是指对表上的多个列进行索引，联合索引也是一棵B+树，不同的是联合索引的键值数量不是1，而是大于等于2

​CREATE TABLE `test` (
  `id` varchar(20) NOT NULL,
  `staff_id` varchar(20) NOT NULL,
  `staff_name` varchar(20) NOT NULL,
  `date` varchar(20) NOT NULL,
  `remark` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_test` (`staff_id`,`staff_name`,`date`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

 联合索引使用原则:

1. 需要加索引的字段，要在where条件中
2. 数据量少的字段不需要加索引。最窄的字段放在键的左边
3. 如果where条件中是OR关系，必须所有的or条件都必须是独立索引，否则加索引不起作用。见：mysql关于or的索引问题
4. 最左前缀原则
5. 只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL

最左前缀原则:

1. b+ 树的数据项是复合的数据结构，比如 (name,age,sex) 的时候，b+ 树是按照从左到右的顺序来建立搜索树的，比如当 (张三,20,F) 这样的数据来检索的时候，b+ 树会优先比较 name 来确定下一步的所搜方向，如果 name 相同再依次比较 age 和 sex，最后得到检索的数据；但当 (20,F) 这样的没有 name 的数据来的时候，b+ 树就不知道第一步该查哪个节点，因为建立搜索树的时候 name 就是第一个比较因子，必须要先根据 name 来搜索才能知道下一步去哪里查询

3. 比如当 (张三, F) 这样的数据来检索时，b+ 树可以用 name 来指定搜索方向，但下一个字段 age 的缺失，所以只能把名字等于张三的数据都找到，然后再匹配性别是 F 的数据了， 这个是非常重要的性质，即索引的最左匹配特性。（这种情况无法用到联合索引）

---

5. 什么情况下应不建或少建索引

5.1 表记录太少

如果一个表只有5条记录，采用索引去访问记录的话，那首先需访问索引表，再通过索引表访问数据表，一般索引表与数据表不在同一个数据块，这种情况下ORACLE至少要往返读取数据块两次。而不用索引的情况下ORACLE会将所有的数据一次读出，处理速度显然会比用索引快。

如表zl_sybm（使用部门）一般只有几条记录，除了主关键字外对任何一个字段建索引都不会产生性能优化，实际上如果对这个表进行了统计分析后ORACLE也不会用你建的索引，而是自动执行全表访问。如：

select * from zl_sybm where sydw_bh=’5401’（对sydw_bh建立索引不会产生性能优化）

5.2 经常插入、删除、修改的表

对一些经常处理的业务表应在查询允许的情况下尽量减少索引，如zl_yhbm，gc_dfss，gc_dfys，gc_fpdy等业务表。

5.3 数据重复且分布平均的表字段

假如一个表有10万行记录，有一个字段A只有T和F两种值，且每个值的分布概率大约为50%，那么对这种表A字段建索引一般不会提高数据库的查询速度。

5.4 经常和主字段一块查询但主字段索引值比较多的表字段

如gc_dfss（电费实收）表经常按收费序号、户标识编号、抄表日期、电费发生年月、操作 标志来具体查询某一笔收款的情况，如果将所有的字段都建在一个索引里那将会增加数据的修改、插入、删除时间，从实际上分析一笔收款如果按收费序号索引就已 经将记录减少到只有几条，如果再按后面的几个字段索引查询将对性能不产生太大的影响。

对千万级MySQL数据库建立索引的事项及提高性能的手段

一、注意事项：

首先，应当考虑表空间和磁盘空间是否足够。我们知道索引也是一种数据，在建立索引的时候势必也会占用大量表空间。因此在对一大表建立索引的时候首先应当考虑的是空间容量问题。

其次，在对建立索引的时候要对表进行加锁，因此应当注意操作在业务空闲的时候进行。

二、性能调整方面：

首当其冲的考虑因素便是磁盘I/O。物理上，应当尽量把索引与数据分散到不同的磁盘上（不考虑阵列的情况）。逻辑上，数据表空间与索引表空间分开。这是在建索引时应当遵守的基本准则。

其次，我们知道，在建立索引的时候要对表进行全表的扫描工作，因此，应当考虑调大初始化参数db_file_multiblock_read_count的值。一般设置为32或更大。

再次，建立索引除了要进行全表扫描外同时还要对数据进行大量的排序操作，因此，应当调整排序区的大小。

    9i之前，可以在session级别上加大sort_area_size的大小，比如设置为100m或者更大。

    9i以后，如果初始化参数workarea_size_policy的值为TRUE，则排序区从pga_aggregate_target里自动分配获得。

最后，建立索引的时候，可以加上nologging选项。以减少在建立索引过程中产生的大量redo，从而提高执行的速度。

6. MySql在建立索引优化时需要注意的问题

设计好MySql的索引可以让你的数据库飞起来，大大的提高数据库效率。设计MySql索引的时候有一下几点注意：

6.1 创建索引

对于查询占主要的应用来说，索引显得尤为重要。很多时候性能问题很简单的就是因为我们忘了添加索引而造成的，或者说没有添加更为有效的索引导致。如果不加

索引的话，那么查找任何哪怕只是一条特定的数据都会进行一次全表扫描，如果一张表的数据量很大而符合条件的结果又很少，那么不加索引会引起致命的性能下

降。但是也不是什么情况都非得建索引不可，比如性别可能就只有两个值，建索引不仅没什么优势，还会影响到更新速度，这被称为过度索引。

6.2 复合索引

比如有一条语句是这样的：select * from users where area=’beijing’ and age=22;

如果我们是在area和age上分别创建单个索引的话，由于mysql查询每次只能使用一个索引，所以虽然这样已经相对不做索引时全表扫描提高了很多效

率，但是如果在area、age两列上创建复合索引的话将带来更高的效率。如果我们创建了(area, age,

salary)的复合索引，那么其实相当于创建了(area,age,salary)、(area,age)、(area)三个索引，这被称为最佳左前缀

特性。因此我们在创建复合索引时应该将最常用作限制条件的列放在最左边，依次递减。

6.3 索引不会包含有NULL值的列

只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。

6.4 使用短索引

对串列进行索引，如果可能应该指定一个前缀长度。例如，如果有一个CHAR(255)的 列，如果在前10 个或20 个字符内，多数值是惟一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。

6.5 排序的索引问题

mysql查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。

6.6 like语句操作

一般情况下不鼓励使用like操作，如果非使用不可，如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。

6.7 不要在列上进行运算

select * from users where

YEAR(adddate)

6.8 不使用NOT IN和 != 操作

NOT IN和 != 操作都不会使用索引将进行全表扫描。NOT IN可以NOT EXISTS代替，id != 3则可使用id>3 or id < 3

来替换。

参考播客: 【推荐】mysql联合 索引(复合索引)的探讨