上一篇文章MySQL中IS NULL、IS NOT NULL、!=不能用索引?胡扯!中唠叨了在WHERE子句中出现IS NULL、IS NOT NULL、!=这些条件时仍然可能使用索引,强调了一个查询成本的问题,不少同学反映对这个查询成本还是没啥概念,我们今天再来稍微深入的唠叨一下。
B+树结构
我们说对于InnoDB存储引擎来说,表中的数据都存储在所谓的B+树中,我们每多建立一个索引,就相当于多建立一棵B+树。
对于聚簇索引对应的B+树来说,叶子节点处存储了完整的用户记录(所谓完整用户记录,就是指一条聚簇索引记录中包含所有用户定义的列已经一些内建的列),并且这些聚簇索引记录按照主键值从小到大排序。
对于二级索引对应的B+树来说,叶子节点处存储了不完整的用户记录(所谓不完整用户记录,就是指一条二级索引记录只包含索引列和主键),并且这些二级索引记录按照索引列的值从小到大排序。
我们向表中存储了多少条记录,每一棵B+树的叶子节点中就包含多少条记录(注意是“每一棵”,包括聚簇索引对应的B+树以及二级索引对应的B+树)。
示例
我们举个例子:
CREATE TABLE t (
id INT UNSIGNED NOT NULL AUTO_INCREMENT,
key1 INT,
common_field VARCHAR(100),
PRIMARY KEY (id),
KEY idx_key1 (key1)
) Engine=InnoDB CHARSET=utf8;
复制代码
这个表就包含2个索引(也就是2棵B+树):
以id列为主键对应的聚簇索引。
为key1列建立的二级索引idx_key1。
我们向表中插入一些记录:
INSERT INTO t VALUES
(1, 30, 'b'),
(2, 80, 'b'),
(3, 23, 'b'),
(4, NULL, 'b'),
(5, 11, 'b'),
(6, 53, 'b'),
(7, 63, 'b'),
(8, NULL, 'b'),
(9, 99, 'b'),
(10, 12, 'b'),
(11, 66, 'b'),
(12, NULL, 'b'),
(13, 66, 'b'),
(14, 30, 'b'),
(15, 11, 'b'),
(16, 90, 'b');
复制代码
所以现在s1表的聚簇索引示意图就是这样: