首页 / MYSQL / MySQL 千万 级数据量根据（索引）优化 查询 速度

MySQL 千万 级数据量根据（索引）优化 查询 速度

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了MySQL 千万 级数据量根据（索引）优化 查询 速度，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含12846字，纯文字阅读大概需要19分钟。

内容图文

TABLE IF EXISTS `test_user`; CREATE TABLE `test_user` ( `id` bigint(20) PRIMARY key not null AUTO_INCREMENT, `username` varchar(50) DEFAULT NULL, `email` varchar(30) DEFAULT NULL, `password` varchar(32) DEFAULT NULL, `status` tinyint(1) NULL DEFAULT 0 ) ENGINE=MyISAM DEFAULT CHARSET=utf8;  

存储引擎使用MyISAM是因为此引擎没有事务，插入速度极快，方便我们快速插入千万条测试数据，等我们插完数据，再把存储类型修改为InnoDB。

 

2).  使用存储过程插入1千万条数据

create procedure myproc()
begin   
    declare num int;   
    set num=1;   
    while num <= 10000000 do   
        insert into test_user(username,email,password) values(CONCAT(‘username_‘,num), CONCAT(num ,‘@qq.com‘), MD5(num));   
        set num=num+1;  
    end while;  
end

3).  执行  call myproc();  

由于使用的MyISAM引擎，插入1千万条数据，仅耗时246秒，若是InnoDB引擎，插入100万条数据就要花费数小时了。

MyISAM引擎之所以如此之快，一个原因是使用了三个文件来存储数据，frm后缀存储表结构、MYD存储真实数据、MYI存储索引数据。

每次进行插入时，MYD的内容是递增插入，MYI是一个B+树结构，每次的索引变更需要重新组织数据。

但相对于InnoDB来说，MyISAM更快。

 

4). sql测试

1. SELECT id,username,email,password FROM test_user WHERE id=999999

耗时：0.114s。

因为我们建表的时候，将id设成了主键，所以执行此sql的时候，走了主键索引，查询速度才会如此之快。

 

2. 我们再执行： SELECT id,username,email,password FROM test_user WHERE username=‘username_9000000‘
耗时：4.613s。

用EXPLAIN分析一下：

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

信息显示进行了全表扫描。

 

3. 那我们给username列加上普通索引。

ALTER TABLE `test_user` ADD INDEX index_name(username) ;

此时，Mysql开始对test_user表建立索引，查看mysql 数据目录：

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

 

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

查看目录文件列表，可以看到新建了三个临时文件，新的临时数据表MYD文件大小并未变更，临时索引文件MYI文件大小增加了很多。

查看执行结果：

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

此过程大约耗时 221.792s,建索引的过程会全表扫描，逐条建索引，当然慢了。

等执行完毕后，mysql把旧的数据库文件删除，再用新建立的临时文件替换掉之。(删除索引过程也是同样的步骤)。

 

4. 再来执行：select id,username,email,password from test_user where username=‘username_9000000‘
耗时：0.001s。

可见查询耗时提高的很可观。

用EXPLAIN分析一下：

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

Extra 字段告诉我们使用到了索引 index_name，和之前的EXPLAIN结果对比，未建立索引前进行了全部扫描，建立索引后使用到了索引，查询耗时对比明显。 

 

5. 再用username和password来联合查询

SELECT id, username, email, PASSWORD FROM test_user WHERE `password` = ‘7ece221bf3f5dbddbe3c2770ac19b419‘ AND username = ‘username_9000000‘;

耗时：0.001s

执行 EXPLAIN ：

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

显示使用到了 index_name 索引，条件语句不分password、useranme先后顺序，结果都是一样。说明sql优化器优先用索引命中。

 

6. 我们再执行：SELECT id, username, email, PASSWORD FROM test_user WHERE `password` = ‘7ece221bf3f5dbddbe3c2770ac19b419‘ OR username = ‘username_900000‘

此时虽然我们已经对 username 加了索引，但是password列未加索引，索引执行password筛选的时候，还是会全表扫描，因此此时查询速度立马降了下来。

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

耗时：5.118s。

EXPLAIN一下：

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

使用OR条件的时候，虽然WHERE 语句中有用到索引字段，但还是进行了全表扫描。

 

 

7. 当我们的sql有多个列的筛选条件的时候，就需要对查询的多个列都加索引组成聚合索引：

加上聚合索引：ALTER TABLE `test_user` ADD INDEX index_union_name_password(username,password)

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

通过临时文件的大小来看，索引文件的大小已经超过了数据文件很多了。索引侧面来说，索引要合理利用，索引就是用空间换时间。

[SQL]ALTER TABLE `test_user` ADD INDEX index_union_name_password(username,password)

受影响的行: 10024725。
时间: 1399.785s。

 


8. 再来执行：[SQL] SELECT id, username, email, PASSWORD FROM test_user WHERE username = ‘username_900000‘ OR `password` = ‘7ece221bf3f5dbddbe3c2770ac19b419‘

耗时：4.416s。

EXPLAIN：

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

竟然是全表扫描，不可思议！！！ 使用 OR 语句竟然没有启用聚合索引，也没使用到单索引username，，，

 

 

9. 再来执行：[SQL] SELECT id, username, email, PASSWORD FROM test_user WHERE username = ‘username_900000‘ AND `password` = ‘7ece221bf3f5dbddbe3c2770ac19b419‘

耗时：0.001s。

EXPLAIN：

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

AND 语句才使用到了聚合索引，聚合索引必须使用AND条件，同时要符合最左原则，请戳我。

 

10. 主键区间查询

[SQL]EXPLAIN SELECT id, username, email, PASSWORD FROM test_user WHERE id > 8999990 AND id < 8999999
受影响的行: 0
时间: 0.001s。

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

命中7行，查询时间很短。

 

[SQL]SELECT id, username, email, PASSWORD FROM test_user WHERE id > 8999900 AND id < 8999999
受影响的行: 0
时间: 0.010s

 

[SQL]SELECT id, username, email, PASSWORD FROM test_user WHERE id > 8999000 AND id < 8999999
受影响的行: 0
时间: 0.029s

 

[SQL]SELECT id, username, email, PASSWORD FROM test_user WHERE id > 8990000 AND id < 8999999
受影响的行: 0
时间: 0.139s

 

通过不断加大区间来看，查询时间跟查询的数据量成相对的正比增长，同时使用到了主键索引。

 

11. 字符串区间查询

[SQL]SELECT id, username, email, PASSWORD FROM test_user WHERE username > ‘username_800000‘ AND `password` > ‘7ece221bf3f5dbddbe3c2770ac19b419‘
受影响的行: 0
时间: 6.059s

EXPLAIN: 

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

未使用索引和聚合索引，进行了全表扫描。

 

[SQL]SELECT id, username, email, PASSWORD FROM test_user WHERE username > ‘username_900000‘ AND `password` > ‘7ece221bf3f5dbddbe3c2770ac19b419‘
受影响的行: 0
时间: 11.488s

EXPLAIN: 

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

也使用到了索引和聚合索引。

对比得出，字符串进行区间查询，是否能使用到索引的条件得看mysql是如何优化查询语句的。

 

12.最左原则

1]. 新建 A、B、C 聚合索引

[SQL]ALTER TABLE `test_user` ADD INDEX index_union_name_email_password(username,email,password)

受影响的行: 10024725
时间: 3171.056s

2]. SQL 测试 

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

慎用 OR 条件，可能将会导致全表扫描。

 

 

覆盖了 A、B、C 索引：

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

该语句使用了覆盖索引，WHERE 语句的先后顺序并不影响。MySQL会对SQL进行查询优化，最终命中ABC索引。

 

 

命中了 A、B、C 索引中的 AB组合，查询耗时很短：

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

 

 没有命中到 A、B、C 索引，所以进行了全表扫描，查询耗时长。

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

 

小结：

要使用覆盖索引必须都是 AND 条件，慎用 OR 条件。

要使用覆盖索引如ABC，需满足条件语句中有 A、AB、ABC才会使用覆盖索引，采用最左原则。

 

 

（三）、InnoDB引擎测试

1). 新建 InnoDB  表

根据上文的步骤，新建一个 test_user_innodb  表，引擎使用MyISAM，然后将存储引擎修改回InnDB。

使用如下命令：  ALTER TABLE test_user_innodb ENGINE=InnoDB; 此命令执行时间大约耗时5分钟，耐心等待。

[SQL]ALTER TABLE test_user_innodb ENGINE=InnoDB;
受影响的行: 10024725
时间: 692.475s

 

执行完毕后， test_user_innodb 表由之前的 三个文件 变为 两个文件，test_user_innodb.frm 和 test_user_innodb.idb。

其中frm文件记录表结构，idb文件记录表中的数据，其实就是一个B+树索引文件，不过该树的叶子节点中的数据域记录的是整行数据记录。

所以 Innodb 的查找次数比 MyISAM 表减少一次磁盘IO查找逻辑，但相对来说，插入数据也就没有MyISAM 快了，有所求就有所得吧！

同时 InnoDB 支持行锁、表锁，InnoDB 的锁机制是建立在索引上的，所以如果没命中索引，那么将是加表锁。

 

2). SQL 测试 

1. [SQL]SELECT id,username,email,password FROM test_user_innodb WHERE username=‘username_9000000‘

受影响的行: 0
时间: 14.540s

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

显示进行了全表扫描，但跟MyISAM表对比来说，扫描的行数小了很多，可能这就是底层B+树布局不一样导致的吧。

 

2. 那我们给username列加上普通索引。

ALTER TABLE `test_user_innodb` ADD INDEX index_name(username) ;

此时，Mysql开始对 test_user_innodb 表建立索引，查看mysql 数据目录：

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

仔细观察，发现只生成了一个表结构临时文件。ibd文件容量在不断增大。这个跟MyISAM表加索引逻辑不一样。

[SQL]ALTER TABLE `test_user_innodb` ADD INDEX index_name(username) ;
受影响的行: 0
时间: 157.679s

此过程大约耗时 157.679s, 貌似建索引的过程未进行全表扫描，对比MyISAM表减少60s左右。为何如何？估计需要看底层实现了！ 

 

3. 再执行 SELECT id,username,email,password FROM test_user_innodb WHERE username=‘username_9000000‘

[SQL]SELECT id,username,email,password FROM test_user_innodb WHERE username=‘username_9000000‘

受影响的行: 0
时间: 0.001s

可见查询耗时减少的很可观，对比与未加索引。用EXPLAIN分析一下，和MyISAM表没有多少差别。

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

 

4. 再用username和password来联合查询

SELECT id, username, email, PASSWORD FROM test_user_innodb  WHERE `password` = ‘7ece221bf3f5dbddbe3c2770ac19b419‘ AND username = ‘username_9000000‘;

耗时：0.001s

执行 EXPLAIN ：

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

 

显示使用到了 index_name 索引，条件语句不分password、useranme先后顺序，结果都是一样。说明sql优化器优先用索引命中。

 

5. 我们再执行：SELECT id, username, email, PASSWORD FROM test_user_innodb WHERE `password` = ‘7ece221bf3f5dbddbe3c2770ac19b419‘ OR username = ‘username_900000‘

此时虽然我们已经对 username 加了索引，但是password列未加索引，索引执行password筛选的时候，还是会全表扫描，因此此时查询速度立马降了下来。

[SQL]SELECT id, username, email, PASSWORD FROM test_user_innodb WHERE `password` = ‘7ece221bf3f5dbddbe3c2770ac19b419‘ OR username = ‘username_900000‘

受影响的行: 0
时间: 10.719s

EXPLAIN一下：

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

使用OR条件的时候，虽然WHERE 语句中有用到索引字段，但还是进行了全表扫描。

对比MyISAM 表来说，没有多大却别，唯一的就是rows行数不一样。

 

6. 加上聚合索引：ALTER TABLE `test_user_innodb` ADD INDEX index_union_name_password(username,password)

 此时，Mysql开始对 test_user_innodb 表建立索引，查看mysql 数据目录，和之前的一样，新增了一个临时表结构文件，ibd文件不断增大。

[SQL]ALTER TABLE `test_user_innodb` ADD INDEX index_union_name_password(username,password)

受影响的行: 0
时间: 348.613s

建立索引的时间比MyISAM 快。

 

7. 再来执行：[SQL]SELECT id, username, email, PASSWORD FROM test_user_innodb WHERE `password` = ‘7ece221bf3f5dbddbe3c2770ac19b419‘ OR username = ‘username_900000‘

受影响的行: 0
时间: 10.357s

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

对比MyISAM 竟然是慢了6s左右？ 和MyISAM 的全表扫描无差别。

InnoDB的OR查询性能没有MyISAM 快，应该是为了实现事务导致的性能损失？

 

8. 再来执行：[SQL] SELECT id, username, email, PASSWORD FROM test_user WHERE username = ‘username_900000‘ AND `password` = ‘7ece221bf3f5dbddbe3c2770ac19b419‘

耗时：0.001s。

EXPLAIN：

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

AND 语句才使用到了聚合索引，聚合索引必须使用AND条件，同时要符合最左原则，请戳我。

 

9. 主键区间查询

[SQL]SELECT id, username, email, PASSWORD FROM test_user_innodb WHERE id > 8999990 AND id < 8999999

受影响的行: 0
时间: 0.000s

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

 

[SQL]SELECT id, username, email, PASSWORD FROM test_user_innodb WHERE id > 8999900 AND id < 8999999

受影响的行: 0
时间: 0.001s

 

[SQL]SELECT id, username, email, PASSWORD FROM test_user_innodb WHERE id > 8999000 AND id < 8999999

受影响的行: 0
时间: 0.003s

 

[SQL]SELECT id, username, email, PASSWORD FROM test_user_innodb WHERE id > 8990000 AND id < 8999999

受影响的行: 0
时间: 0.022s

 

通过不断加大区间来看，查询时间跟查询的数据量成相对的正比增长，同时使用到了主键索引。

相对于MyISAM 表来说，主键区间查询的耗时小很多很多！看来只能用底层的B+树的实现不一样来解释了！

MyISAM 的B+树子节点的叶子节点数据域，存储的是数据在MYD文件中的数据地址。

InnoDB  的B+树子节点的叶子节点数据域，存储的是整行数据记录，这个节省了一次硬盘IO操作，应该是这个特点导致了主键区间查询比MyISAM 快的原因。

原因请戳我

 

10. 字符串区间查询

[SQL]SELECT id, username, email, PASSWORD FROM test_user_innodb WHERE username > ‘username_800000‘ AND `password` > ‘7ece221bf3f5dbddbe3c2770ac19b419‘

受影响的行: 0
时间: 12.506s

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

未使用索引和聚合索引，进行了全表扫描。

 

缩小区间在查询 

[SQL]SELECT id, username, email, PASSWORD FROM test_user_innodb WHERE username > ‘username_900000‘ AND `password` > ‘7ece221bf3f5dbddbe3c2770ac19b419‘

受影响的行: 0
时间: 12.213s

 

[SQL]SELECT id, username, email, PASSWORD FROM test_user_innodb WHERE username > ‘username_1000000‘ AND `password` > ‘7ece221bf3f5dbddbe3c2770ac19b419‘

受影响的行: 0
时间: 19.793s

 

11.最左原则

1]. 新建 A、B、C 聚合索引

[SQL]ALTER TABLE `test_user_innodb` ADD INDEX index_union_name_email_password(username,email,password)

受影响的行: 0
时间: 588.579s

 

对比MyISAM 表来说，建立该索引的时间是其的1/6之一。建立索引的时间相对可观。磁盘占用来说InnoDB总量更小。

 

2]. SQL 测试 

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

和MyISAM 表对比，竟然没使用到全表扫描，而且使用到了聚合索引。

 

覆盖了 A、B、C 索引：

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

该语句使用了覆盖索引，WHERE 语句的先后顺序并不影响。MySQL会对SQL进行查询优化，最终命中ABC索引。

 

命中了 A、B、C 索引中的 AB组合，查询耗时很短：

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

 

没有命中到 A、B、C 索引最左原则，竟然不是全表扫描，而是使用了索引。

MySQL 千万 级数据量根据（索引）优化 查询 速度 - 文章图片

和MyISAM 表对比，MyISAM 表是全表扫描，而InnoDB却是使用到了索引。

 

 

六、总结

两大引擎MyISAM、InnoDB分析：

背景：

数据记录：10024725行

表索引：  主键、A、AB、ABC

 

相同点：

1.都是B+树的底层实现。

2.WHERE条件都符合索引最左匹配原则。

 

不同点：

1.MyISAM的存储文件有三个，frm、MYD、MYI 文件；InnoDB的存储文件就两个，frm、ibd文件。总文件大小InnoDB引擎占用空间更小。

2.InnoDB的存储文件本身就是索引构成，建立新索引的时间比MyISAM快。

3.MyISAM比InnoDB查询速度快，插入速度也快。

4.主键区间查询，InnoDB查询更快。字符串区间查询，MyISAM相对更快。

5.有A、AB、ABC索引的情况下，A OR B 查询，InnoDB查询性能比MyISAM慢。

6.InnoDB表没有命中到 A、B、C 索引最左原则时，BC组合查询命中了索引，但还是完全扫描，比全表扫描快些。MyISAM是全表扫描。

 

 

开篇也说过软件层面的优化一是合理加索引；二是优化执行慢的sql。

此二者相辅相成，缺一不可，如果加了索引，还是查询很慢，这时候就要考虑是sql的问题了，优化sql。

实际生产中的sql往往比较复杂，如果数据量过了百万，加了索引后效果还是不理想，使用集群、垂直或水平拆分。

 

 

ps：

MySQL中B+Tree索引原理

B+树原理及mysql的索引分析

 

MySQL 千万 级数据量根据（索引）优化 查询 速度

标签：1.7   额外   精确   库文件   引用   表数   关注   情况下   article   

本文系统来源：https://www.cnblogs.com/phpdragon/p/8231533.html

内容总结

以上是互联网集市为您收集整理的MySQL 千万 级数据量根据（索引）优化 查询 速度全部内容，希望文章能够帮你解决MySQL 千万 级数据量根据（索引）优化 查询 速度所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

扫描二维码推送至手机访问。

本文链接：https://qyyshop.com/info/496880.html

来源：【匿名】