京东三面：我要查询千万级数据量的表，怎么操作？

> 本文由 [简悦 SimpRead](http://ksria.com/simpread/) 转码， 原文地址 [www.tuicool.com](https://www.tuicool.com/articles/meu26fQ)

前言

*   面试官： 来说说，一千万的数据，你是怎么查询的？
*   我：直接分页查询，使用 limit 分页。
*   面试官：有实操过吗？
*   我：肯定有呀

此刻献上一首《凉凉》

也许有些人没遇过上千万数据量的表，也不清楚查询上千万数据量的时候会发生什么。

今天就来带大家实操一下，这次是基于 **MySQL 5.7.26** 做测试

准备数据
----

没有一千万的数据怎么办？

创建呗

代码创建一千万？那是不可能的，太慢了，可能真的要跑一天。可以采用数据库脚本执行速度快很多。

创建表
---

CREATE TABLE `user_operation_log` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`user_id` varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,

`ip` varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,

`op_data` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,

`attr1` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,

`attr2` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,

`attr3` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,

`attr4` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,

`attr5` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,

`attr6` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,

`attr7` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,

`attr8` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,

`attr9` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,

`attr10` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,

`attr11` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,

`attr12` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,

PRIMARY KEY (`id`) USING BTREE

) ENGINE = InnoDB AUTO_INCREMENT = 1 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci ROW_FORMAT = Dynamic;

创建数据脚本
------

采用批量插入，效率会快很多，而且每 1000 条数就 commit，数据量太大，也会导致批量插入效率慢

DELIMITER ;

;

CREATE PROCEDURE batch_insert_log()BEGIN DECLARE i iNT DEFAULT 1;

DECLARE userId iNT DEFAULT 10000000;

set @execSql = 'INSERT INTO `test`.`user_operation_log`(`user_id`, `ip`, `op_data`, `attr1`, `attr2`, `attr3`, `attr4`, `attr5`, `attr6`, `attr7`, `attr8`, `attr9`, `attr10`, `attr11`, `attr12`) VALUES';

set @execData = '';

WHILE i<=10000000 DO set @attr = "'测试很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长很长的属性'";

set @execData = concat(@execData, "(", userId + i, ",'10.0.69.175','用户登录操作'",",", @attr,",", @attr,",", @attr,",", @attr,",", @attr,",", @attr,",", @attr,",", @attr,",", @attr,",", @attr,",", @attr,",", @attr,")");

if i % 1000 = 0 then set @stmtSql = concat(@execSql, @execData,";");

prepare stmt from @stmtSql;

execute stmt;

DEALLOCATE prepare stmt;

commit;

set @execData = ""; else set @execData = concat(@execData,",");

end if;

SET i=i+1;

END WHILE;

END;

;

DELIMITER ;

开始测试

哥的电脑配置比较低：win10 标压渣渣 i5 读写约 500MB 的 SSD

由于配置低，本次测试只准备了 3148000 条数据，占用了磁盘 5G(还没建索引的情况下)，跑了 38min，电脑配置好的同学，可以插入多点数据测试

SELECT count(1) FROM `user_operation_log`

返回结果：3148000

三次查询时间分别为：

*   14060 ms
*   13755 ms
*   13447 ms

普通分页查询
------

MySQL 支持 LIMIT 语句来选取指定的条数数据， Oracle 可以使用 ROWNUM 来选取。

MySQL 分页查询语法如下：

SELECT * FROM table LIMIT [offset,] rows | rows OFFSET offset

*   第一个参数指定第一个返回记录行的偏移量
*   第二个参数指定返回记录行的最大数目

下面我们开始测试查询结果：

SELECT * FROM `user_operation_log` LIMIT 10000, 10

查询 3 次时间分别为：

*   59 ms
*   49 ms
*   50 ms

这样看起来速度还行，不过是本地数据库，速度自然快点。

换个角度来测试

相同偏移量，不同数据量
-----------

SELECT * FROM `user_operation_log` LIMIT 10000, 10

SELECT * FROM `user_operation_log` LIMIT 10000, 100

SELECT * FROM `user_operation_log` LIMIT 10000, 1000

SELECT * FROM `user_operation_log` LIMIT 10000, 10000

SELECT * FROM `user_operation_log` LIMIT 10000, 100000

SELECT * FROM `user_operation_log` LIMIT 10000, 1000000

查询时间如下：

数量第一次第二次第三次 10 条 53ms52ms47ms100 条 50ms60ms55ms1000 条 61ms74ms60ms10000 条 164ms180ms217ms100000 条 1609ms1741ms1764ms1000000 条 16219ms16889ms17081ms

从上面结果可以得出结束： **数据量越大，花费时间越长**

相同数据量，不同偏移量
-----------

SELECT * FROM `user_operation_log` LIMIT 100, 100

SELECT * FROM `user_operation_log` LIMIT 1000, 100

SELECT * FROM `user_operation_log` LIMIT 10000, 100

SELECT * FROM `user_operation_log` LIMIT 100000, 100

SELECT * FROM `user_operation_log` LIMIT 1000000, 100

偏移量第一次第二次第三次 10036ms40ms36ms100031ms38ms32ms1000053ms48ms51ms100000622ms576ms627ms10000004891ms5076ms4856ms

从上面结果可以得出结束： **偏移量越大，花费时间越长**

SELECT * FROM `user_operation_log` LIMIT 100, 100

SELECT id, attr FROM `user_operation_log` LIMIT 100, 100

如何优化

既然我们经过上面一番的折腾，也得出了结论，针对上面两个问题：偏移大、数据量大，我们分别着手优化

优化偏移量大问题
--------

采用子查询方式
-------

我们可以先定位偏移位置的 id，然后再查询数据

SELECT * FROM `user_operation_log` LIMIT 1000000,

10SELECT id FROM `user_operation_log` LIMIT 1000000,

1SELECT * FROM `user_operation_log` WHERE id >= (

SELECT id FROM `user_operation_log` LIMIT 1000000,

1

) LIMIT 10

查询结果如下：

sql 花费时间第一条 4818ms 第二条 (无索引情况下)4329ms 第二条 (有索引情况下)199ms 第三条 (无索引情况下)4319ms 第三条 (有索引情况下)201ms

从上面结果得出结论：

*   第一条花费的时间最大，第三条比第一条稍微好点
*   子查询使用索引速度更快

缺点：只适用于 id 递增的情况

id 非递增的情况可以使用以下写法，但这种缺点是分页查询只能放在子查询里面

注意：某些 mysql 版本不支持在 in 子句中使用 limit，所以采用了多个嵌套 select

SELECT * FROM `user_operation_log` WHERE id IN (

SELECT t.id FROM (

SELECT id FROM `user_operation_log` LIMIT 1000000,

10

) AS t

)

采用 id 限定方式

这种方法要求更高些，id 必须是连续递增，而且还得计算 id 的范围，然后使用 between，sql 如下

SELECT * FROM `user_operation_log` WHERE id between 1000000 AND 1000100 LIMIT 100SELECT * FROM `user_operation_log` WHERE id >= 1000000 LIMIT 100

查询结果如下：

sql 花费时间第一条 22ms 第二条 21ms

从结果可以看出这种方式非常快

注意：这里的 LIMIT 是限制了条数，没有采用偏移量

优化数据量大问题
--------

返回结果的数据量也会直接影响速度

SELECT * FROM `user_operation_log` LIMIT 1, 1000000

SELECT id FROM `user_operation_log` LIMIT 1, 1000000

SELECT id, user_id, ip, op_data, attr1, attr2, attr3, attr4, attr5, attr6, attr7, attr8, attr9, attr10, attr11, attr12 FROM `user_operation_log` LIMIT 1, 1000000

查询结果如下：

sql 花费时间第一条 15676ms 第二条 7298ms 第三条 15960ms

从结果可以看出减少不需要的列，查询效率也可以得到明显提升

第一条和第三条查询速度差不多，这时候你肯定会吐槽，那我还写那么多字段干啥呢，直接 * 不就完事了

注意本人的 MySQL 服务器和客户端是在 _同一台机器_ 上，所以查询数据相差不多，有条件的同学可以测测客户端与 MySQL 分开

SELECT * 它不香吗？
--------------

在这里顺便补充一下为什么要禁止 SELECT *。难道简单无脑，它不香吗？

主要两点：

1.  用 "SELECT *" 数据库需要解析更多的对象、字段、权限、属性等相关内容，在 SQL 语句复杂，硬解析较多的情况下，会对数据库造成沉重的负担。
2.  增大网络开销，* 有时会误带上如 log、IconMD5 之类的无用且大文本字段，数据传输 size 会几何增长。特别是 MySQL 和应用程序不在同一台机器，这种开销非常明显。

结束
--

最后还是希望大家自己去实操一下，肯定还可以收获更多，欢迎留言！！

创建脚本我给你正好了，你还在等什么！！！