Heim >Java >JavaInterview Fragen >Interviewer: Wie haben Sie 10 Millionen Daten abgefragt?
Kürzlich habe ich Probeinterviews und Lebenslaufoptimierungen für alle durchgeführt und dabei festgestellt, dass viele Menschen weiche Knie bekommen, wenn sie Fragen wie zig Millionen Daten sehen.
Vielleicht sind einige Leute noch nie auf eine Tabelle mit zig Millionen Daten gestoßen und wissen nicht, was passiert, wenn sie zig Millionen Daten abfragen.
Heute werde ich Sie durch eine praktische Übung führen. Dieses Mal basiert sie auf MySQL 5.7.26 zum Testen
Was tun, wenn Sie nicht über 10 Millionen Daten verfügen? ?
Sie können es ohne Daten nicht selbst erstellen?
Ist es schwierig, Daten zu erstellen?
10 Millionen Code-Erstellung?
Das ist unmöglich, es ist zu langsam, man könnte wirklich einen ganzen Tag zum Laufen brauchen. Sie können Datenbankskripte verwenden, um sie viel schneller auszuführen.
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;
Mit der Stapeleinfügung wird die Effizienz viel schneller sein und alle 1000 Elemente werden festgeschrieben Das Einfügen von Stapeln wird ebenfalls langsam sein.
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 ;. Starten Sie den Test Für diesen Test wurden 3148000 Datenstücke vorbereitet, die 5G belegten (noch ohne Indizierung), und er lief 38 Minuten lang. Schüler mit guter Computerkonfiguration können mehrere Datenpunkte zum Testen einfügen
SELECT count(1) FROM `user_operation_log`
MySQL 支持 LIMIT 语句来选取指定的条数数据, Oracle 可以使用 ROWNUM 来选取。
MySQL分页查询语法如下:
SELECT * FROM table LIMIT [offset,] rows | rows OFFSET offset
下面我们开始测试查询结果:
SELECT * FROM `user_operation_log` LIMIT 10000, 10
查询3次时间分别为:
这样看起来速度还行,不过是本地数据库,速度自然快点。
换个角度来测试
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
查询时间如下:
Menge | Erstes Mal | Zweites Mal | Drittes Mal | ||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
10. Artikel | 53ms | 52ms | 47ms | ||||||||||||||||||||||||||||||||||||||||||||||||
100 Artikel | 50ms | 60ms | 55ms | ||||||||||||||||||||||||||||||||||||||||||||||||
100000 Artikel | 1609ms | 1741ms | |||||||||||||||||||||||||||||||||||||||||||||||||
1000000 Artikel | 16219ms | 16889ms | |||||||||||||||||||||||||||||||||||||||||||||||||
偏移量 | 第一次 | 第二次 | 第三次 |
---|---|---|---|
100 | 36ms | 40ms | 36ms |
1000 | 31ms | 38ms | 32ms |
10000 | 53ms | 48ms | 51ms |
100000 | 622ms | 576ms | 627ms |
1000000 | 4891ms | 5076ms | 4856ms |
从上面结果可以得出结束:偏移量越大,花费时间越长
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, 10 SELECT id FROM `user_operation_log` LIMIT 1000000, 1 SELECT * 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的范围,然后使用 between,sql如下
SELECT * FROM `user_operation_log` WHERE id between 1000000 AND 1000100 LIMIT 100 SELECT * 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 |
Aus den Ergebnissen geht hervor, dass durch die Reduzierung unnötiger Spalten auch die Abfrageeffizienz erheblich verbessert werden kann.
Die Geschwindigkeit der ersten und dritten Abfrage ist fast gleich, also warum sollte ich mich beschweren? So viele Felder schreiben? , einfach * und schon sind Sie fertig
Beachten Sie, dass sich mein MySQL-Server und mein MySQL-Client auf demselben Computer befinden, sodass qualifizierte Studenten den Client und MySQL separat testen können
Übrigens möchte ich hier hinzufügen, warum wir SELECT *
. Ist es nicht köstlich, weil es einfach und sinnlos ist? SELECT *
。难道简单无脑,它不香吗?
主要两点:
SELECT *
" 数据库需要解析更多的对象、字段、权限、属性等相关内容,在 SQL 语句复杂,硬解析较多的情况下,会对数据库造成沉重的负担。*
SELECT *
" Die Datenbank muss mehr Objekte, Felder, Berechtigungen, Attribute usw. analysieren. Inhalt: Wenn die SQL-Anweisung komplex ist und viele harte Analysen durchgeführt werden, wird die Datenbank stark belastet. *
Manchmal sind log, IconMD5 und dergleichen fälschlicherweise enthalten. Nutzlos und groß Bei Textfeldern nimmt die Datenübertragungsgröße exponentiell zu. Insbesondere da sich MySQL und die Anwendung nicht auf demselben Rechner befinden, ist dieser Overhead sehr offensichtlich. 🎜🎜🎜🎜Das obige ist der detaillierte Inhalt vonInterviewer: Wie haben Sie 10 Millionen Daten abgefragt?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!