[InnoDB]性别字段为什么不适合加索引

栏目: 数据库 · 发布时间: 5年前

内容简介:id为主键,id为奇数sex=1,id为偶数sex=0 sex=0,50000条数据;sex=1,50000条数据添加的索引类型可以看到相同的sql,加索引之后比不加索引慢许多。

id为主键,id为奇数sex=1,id为偶数sex=0 sex=0,50000条数据;sex=1,50000条数据

[InnoDB]性别字段为什么不适合加索引
[InnoDB]性别字段为什么不适合加索引
CREATE TABLE `people` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  `sex` tinyint(1) unsigned DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=100001 DEFAULT CHARSET=utf8;
复制代码
CREATE DEFINER=`root`@`localhost` PROCEDURE `proc_initData`()
BEGIN
    DECLARE i INT DEFAULT 1;
    WHILE i<=100000 DO
        INSERT INTO people(name, sex) VALUES(CONCAT('姓名',i),0);
        SET i = i+1;
    END WHILE;
END

CALL proc_initData();
UPDATE people SET sex = 1 WHERE MOD(id,2) = 1;
复制代码

添加的索引类型

[InnoDB]性别字段为什么不适合加索引

测试结果:

SELECT * FROM people WHERE sex = 0;
SELECT * FROM people WHERE sex = 1;
复制代码
无sex索引 有sex索引
sex=0
[InnoDB]性别字段为什么不适合加索引
[InnoDB]性别字段为什么不适合加索引
sex=1
[InnoDB]性别字段为什么不适合加索引
[InnoDB]性别字段为什么不适合加索引

可以看到相同的sql,加索引之后比不加索引慢许多。

原因

在InnoDB中每一个表都会有聚集索引,如果表定义了主键,则主键就是聚集索引。一个表只有一个聚集索引,其余为普通索引。 索引的结构是B+树,非叶子节点存储key,叶子节点存储value。

  1. 聚集索引,叶子节点存储行记录,InnoDB索引和记录是存储在一起的。
  2. 普通索引,叶子节点存储了主键的值。

以上表的索引结构示例如下(PS:索引结构仅供参考) 聚集索引

[InnoDB]性别字段为什么不适合加索引

sex列普通索引

[InnoDB]性别字段为什么不适合加索引
在使用普通索引查询时,会先加载普通索引,通过普通索引查询到实际行的主键。再使用主键通过聚集索引查询相应的行。以此循环查询所有的行。 若直接全量搜索聚集索引,则不需要在普通索引和聚集索引中来回切换。 相比两种操作的总开销可能扫描全表效率更高。

以上所述就是小编给大家介绍的《[InnoDB]性别字段为什么不适合加索引》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

移动交互设计精髓

移动交互设计精髓

班格 (Cameron Banga)、温霍尔德 (Josh Weinhold) / 傅小贞、张颖鋆 / 电子工业出版社 / 2015-4-1 / CNY 89.00

越来越多的人正涌入移动应用领域,而设计和体验将是移动应用成败的关键。作者通过上百款应用的设计实践,系统化地梳理了移动应用的设计方法论,在理解用户、跨平台和适配设计、移动组件应用、界面视觉感染力、简约设计等方面都进行了深入阐述。此外,作者还介绍了一些非常实用的移动设计工具,分享了设计师该如何与开发工程师协同工作,以及如何收集用户反馈、甄别版本迭代的更新需求等。 《移动交互设计精髓——设计完美的......一起来看看 《移动交互设计精髓》 这本书的介绍吧!

JS 压缩/解压工具
JS 压缩/解压工具

在线压缩/解压 JS 代码

URL 编码/解码
URL 编码/解码

URL 编码/解码

HSV CMYK 转换工具
HSV CMYK 转换工具

HSV CMYK互换工具