優化實錄！如何將 MySQL 查詢時間從 190 秒縮減到 1 秒，輕松應對千萬數據
作者：編程疏影
當表的大小過大時，除了關注訪問此表的響應時間外，還應考慮表的維護成本（例如 DDL 操作所需的時間和刪除歷史數據的時間）。
最近，我在工作中遇到一個數據庫配置問題，涉及一個主從結構的數據庫實例。具體來說，該數據庫每天凌晨會觸發SLA（服務級別協議）警報。這個警報表明主從同步延遲顯著。這意味著如果在這個時間點嘗試從主庫切換到從庫，切換的完成時間會非常長。系統需要額外的時間來趕上并同步延遲的數據，以確保主庫和從庫之間的數據一致性。進一步分析顯示，這個問題的一個主要驅動因素是該數據庫實例中存在大量慢查詢。
這些慢查詢定義為執行時間超過1秒的SQL查詢。
我們發現，應用程序每晚執行的一個特定任務——刪除一個月前的舊數據——是這些慢查詢的主要來源。
分析
利用pt-query-digest工具分析最近一周的mysql-slow.log。
pt-query-digest --since=148h mysql-slow.log | less結果第二部分
圖片
在過去一周，總共記錄的慢查詢執行時間為25403秒，最長的慢SQL執行時間為266秒，平均每個慢SQL的執行時間為5秒，平均掃描的行數為1766萬。
結果第二部分
圖片
選擇arrival_record操作的慢查詢次數超過4萬次，平均響應時間為4秒。刪除arrival_record的記錄6次，平均響應時間為258秒。
select xxx_record語句
選擇arrival_record的慢查詢語句類似于以下，where子句中的參數字段相同，但參數值不同： *select count(*) from arrival_record where product_id=26 and receive_time between '2019-03-25 14:00:00' and '2019-03-25 15:00:00' and receive_spend_ms>=0\G*
圖片
選擇arrival_record的語句最多掃描了5600萬行，MySQL中的平均掃描行數為172萬，推斷出掃描行數過多導致執行時間長。
查看執行計劃
explain select count(*) from arrival_record where product_id=26 and receive_time between '2019-03-25 14:00:00' and '2019-03-25 15:00:00' and receive_spend_ms>=0\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: arrival_record
partitions: NULL
type: ref
possible_keys: IXFK_arrival_record
key: IXFK_arrival_record
key_len: 8
ref: const
rows: 32261320
filtered: 3.70
Extra: Using index condition; Using where
1 row in set, 1 warning (0.00 sec)使用了索引IXFK_arrival_record，但估算掃描的行數非常大，超過3000萬行。
show index from arrival_record;
+----------------+------------+---------------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+----------------+------------+---------------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| arrival_record | 0 | PRIMARY | 1 | id | A | 107990720 | NULL | NULL | | BTREE | | |
| arrival_record | 1 | IXFK_arrival_record | 1 | product_id | A | 1344 | NULL | NULL | | BTREE | | |
| arrival_record | 1 | IXFK_arrival_record | 2 | station_no | A | 22161 | NULL | NULL | YES | BTREE | | |
| arrival_record | 1 | IXFK_arrival_record | 3 | sequence | A | 77233384 | NULL | NULL | | BTREE | | |
| arrival_record | 1 | IXFK_arrival_record | 4 | receive_time | A | 65854652 | NULL | NULL | YES | BTREE | | |
| arrival_record | 1 | IXFK_arrival_record | 5 | arrival_time | A | 73861904 | NULL | NULL | YES | BTREE | | |
+----------------+------------+---------------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
show create table arrival_record;
..........
arrival_spend_ms bigint(20) DEFAULT NULL,
total_spend_ms bigint(20) DEFAULT NULL,
PRIMARY KEY (id),
KEY IXFK_arrival_record (product_id,station_no,sequence,receive_time,arrival_time) USING BTREE,
CONSTRAINT FK_arrival_record_product FOREIGN KEY (product_id) REFERENCES product (id) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB AUTO_INCREMENT=614538979 DEFAULT CHARSET=utf8 COLLATE=utf8_bin |- 表中包含超過1億條記錄，只有一個復合索引。product_id字段的基數非常低，選擇性差，不適合查詢。
- 提供的過濾條件where product_id=26 and receive_time between '2019-03-25 14:00:00' and '2019-03-25 15:00:00' and receive_spend_ms>=0中并未包含station_no字段，因此未能利用復合索引IXFK_arrival_record的字段product_id、station_no、sequence和receive_time。
- 根據左前綴原則，選擇arrival_record只使用復合索引IXFK_arrival_record的第一個字段product_id，其選擇性差，導致掃描的行數較多，執行時間較長。
- receive_time字段具有較高的基數和良好的選擇性，單獨為該字段創建索引是有益的。然后，選擇arrival_record的SQL將會利用這個索引。
現在我們知道arrival_record的慢查詢日志中的where語句包含了字段product_id、receive_time、receive_spend_ms的參數，我們想知道是否還有其他字段用于過濾訪問這個表？
強大工具tcpdump的登場時間
使用tcpdump捕獲一段時間內針對該表的select語句的數據包。
tcpdump -i bond0 -s 0 -l -w - dst port 3316 | strings | grep select | egrep -i 'arrival_record' >/tmp/select_arri.log捕獲 select 語句中 from 后的條件語句。
IFS_OLD=$IFS
IFS=$'\n'
for i in `cat /tmp/select_arri.log`; do echo ${i#*'from'}; done | less
IFS=$IFS_OLD
arrival_record arrivalrec0_ where arrivalrec0_.sequence='2019-03-27 08:40' and arrivalrec0_.product_id=17 and arrivalrec0_.station_no='56742'
arrival_record arrivalrec0_ where arrivalrec0_.sequence='2019-03-27 08:40' and arrivalrec0_.product_id=22 and arrivalrec0_.station_no='S7100'
arrival_record arrivalrec0_ where arrivalrec0_.sequence='2019-03-27 08:40' and arrivalrec0_.product_id=24 and arrivalrec0_.station_no='V4631'
arrival_record arrivalrec0_ where arrivalrec0_.sequence='2019-03-27 08:40' and arrivalrec0_.product_id=22 and arrivalrec0_.station_no='S9466'
arrival_record arrivalrec0_ where arrivalrec0_.sequence='2019-03-27 08:40' and arrivalrec0_.product_id=24 and arrivalrec0_.station_no='V4205'
arrival_record arrivalrec0_ where arrivalrec0_.sequence='2019-03-27 08:40' and arrivalrec0_.product_id=24 and arrivalrec0_.station_no='V4105'
arrival_record arrivalrec0_ where arrivalrec0_.sequence='2019-03-27 08:40' and arrivalrec0_.product_id=24 and arrivalrec0_.station_no='V4506'
arrival_record arrivalrec0_ where arrivalrec0_.sequence='2019-03-27 08:40' and arrivalrec0_.product_id=24 and arrivalrec0_.station_no='V4617'
arrival_record arrivalrec0_ where arrivalrec0_.sequence='2019-03-27 08:40' and arrivalrec0_.product_id=22 and arrivalrec0_.station_no='S8356'
arrival_record arrivalrec0_ where arrivalrec0_.sequence='2019-03-27 08:40' and arrivalrec0_.product_id=22 and arrivalrec0_.station_no='S8356'表的 where 條件包含 product_id、station_no 和 sequence 字段，可以利用復合索引 IXFK_arrival_record 的前三個字段。
總結來說，優化方法是刪除復合索引 IXFK_arrival_record，創建一個新的復合索引 idx_sequence_station_no_product_id，并建立單獨的索引 indx_receive_time。
刪除 xxx_record 語句
刪除操作的平均掃描量為 1.1 億行，平均執行時間為 262 秒。
下面是刪除語句，每個慢查詢記錄不同的參數值：
delete from arrival_record where receive_time < STR_TO_DATE('2019-02-23', '%Y-%m-%d')\G執行計劃：
explain select * from arrival_record where receive_time < STR_TO_DATE('2019-02-23', '%Y-%m-%d')\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: arrival_record
partitions: NULL
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 109,501,508
filtered: 33.33
Extra: Using where
1 row in set, 1 warning (0.00 sec)該刪除語句未使用索引（沒有合適的索引可用），導致全表掃描和較長的執行時間。
優化方法也是創建一個單獨的索引 indx_receive_time(receive_time)。
測試
將 arrival_record 表復制到測試實例，以在 XX 實例的 arrival_record 表 上執行刪除和重建索引操作。
du -sh /datas/mysql/data/3316/cq_new_cimiss/arrival_record*
12K /datas/mysql/data/3316/cq_new_cimiss/arrival_record.frm
48G /datas/mysql/data/3316/cq_new_cimiss/arrival_record.ibd
select count() from cq_new_cimiss.arrival_record;
+-----------+
| count() |
+-----------+
| 112294946 |
+-----------+
超過 1 億條記錄。
SELECT
table_name,
CONCAT(FORMAT(SUM(data_length) / 1024 / 1024,2),'M') AS dbdata_size,
CONCAT(FORMAT(SUM(index_length) / 1024 / 1024,2),'M') AS dbindex_size,
CONCAT(FORMAT(SUM(data_length + index_length) / 1024 / 1024 / 1024,2),'G') AS table_size(G),
AVG_ROW_LENGTH,table_rows,update_time
FROM
information_schema.tables
WHERE table_schema = 'cq_new_cimiss' and table_name='arrival_record';
+----------------+-------------+--------------+------------+----------------+------------+---------------------+
| table_name | dbdata_size | dbindex_size | table_size(G) | AVG_ROW_LENGTH | table_rows | update_time |
+----------------+-------------+--------------+------------+----------------+------------+---------------------+
| arrival_record | 18,268.02M | 13,868.05M | 31.38G | 175 | 109155053 | 2019-03-26 12:40:17 |
+----------------+-------------+--------------+------------+----------------+------------+---------------------+磁盤空間使用為 48G，MySQL 中的表大小為 31G，顯示出大約 17G 的碎片，主要是由于刪除造成的（刪除記錄后未回收空間）。
備份并恢復表到新實例，刪除原復合索引，并添加新索引進行測試。
mydumper 并行壓縮備份
user=root
passwd=xxxx
socket=/datas/mysql/data/3316/mysqld.sock
db=cq_new_cimiss
table_name=arrival_record
backupdir=/datas/dump_$table_name
mkdir -p $backupdir
nohup echo `date +%T` && mydumper -u $user -p $passwd -S $socket -B $db -c -T $table_name -o $backupdir -t 32 -r 2000000 && echo `date +%T` &并行壓縮備份耗時（52秒）和使用空間（1.2G，實際表占用 48G 磁盤空間，顯示出 mydumper 的高壓縮比?。?/p>
開始備份于：2019-03-26 12:46:04
........
備份完成于：2019-03-26 12:46:56
du -sh /datas/dump_arrival_record/
1.2G /datas/dump_arrival_record/將備份數據復制到測試節點：
scp -rp /datas/dump_arrival_record root@10.230.124.19:/datas多線程數據導入：
time myloader -u root -S /datas/mysql/data/3308/mysqld.sock -P 3308 -p root -B test -d /datas/dump_arrival_record -t 32真實耗時 126m42.885s 用戶 1m4.543s 系統 0m4.267s
邏輯導入表后的磁盤空間使用：
du -h -d 1 /datas/mysql/data/3308/test/arrival_record.*
12K /datas/mysql/data/3308/test/arrival_record.frm
30G /datas/mysql/data/3308/test/arrival_record.ibd
無碎片，與 MySQL 中的表大小相匹配。
cp -rp /datas/mysql/data/3308 /datas使用在線 DDL 和 pt-osc 工具進行索引刪除和重建。首先，刪除外鍵；如果不這樣做，復合索引無法被刪除，因為外鍵列是復合索引中第一列的一部分。
nohup bash /tmp/ddl_index.sh &
2019-04-04-10:41:39 開始停止 mysqld_3308
2019-04-04-10:41:41 開始 rm -rf datadir 并復制 datadir_bak
2019-04-04-10:46:53 啟動 mysqld_3308
2019-04-04-10:46:59 在線 DDL 開始
2019-04-04-11:20:01 索引刪除成功索引刪除完成后，添加新索引。
2019-04-04-11:20:02 索引添加開始
2019-04-04-11:40:30 索引添加成功生成的 EXPLAIN：
+----+-------------+-------------------+-------+---------------+---------+---------+------------------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------------------+-------+---------------+---------+---------+------------------+------+-------------+
| 1 | SIMPLE | arrival_record | range | indx_receive_time | indx_receive_time | 8 | NULL | 3522 | Using where |
+----+-------------+-------------------+-------+---------------+---------+---------+------------------+------+-------------+該查詢可以使用索引進行加速，最終性能提升十倍。
使用建議：
實施
由于這是一個主從實例，應用程序連接到 VIP。刪除和重建索引使用在線 DDL 進行。在停止主從復制后，首先在從實例上執行（不記錄 binlog），然后進行主從切換，接著在新切換的從實例上執行（不記錄 binlog）。
function red_echo () {
local what="$*"
echo -e "$(date +%F-%T) ${what}"
}
function check_las_comm(){
if [ "$1" != "0" ];then
red_echo "$2"
echo "exit 1"
exit 1
fi
}
red_echo "stop slave"
mysql -uroot -p$passwd --socket=/datas/mysql/data/${port}/mysqld.sock -e"stop slave"
check_las_comm "$?" "stop slave failed"
red_echo "online ddl begin"
mysql -uroot -p$passwd --socket=/datas/mysql/data/${port}/mysqld.sock -e"set sql_log_bin=0;select now() as ddl_start;ALTER TABLE $db_.\`${table_name}\` DROP FOREIGN KEY FK_arrival_record_product,drop index IXFK_arrival_record,add index idx_product_id_sequence_station_no(product_id,sequence,station_no),add index idx_receive_time(receive_time);select now() as ddl_stop" >>${log_file} 2>&1
red_echo "online ddl stop"
red_echo "add foreign key"
mysql -uroot -p$passwd --socket=/datas/mysql/data/${port}/mysqld.sock -e"set sql_log_bin=0;ALTER TABLE $db_.${table_name} ADD CONSTRAINT _FK_${table_name}_product FOREIGN KEY (product_id) REFERENCES cq_new_cimiss.product (id) ON DELETE NO ACTION ON UPDATE NO ACTION;" >>${log_file} 2>&1
check_las_comm "$?" "add foreign key error"
red_echo "add foreign key stop"
red_echo "start slave"
mysql -uroot -p$passwd --socket=/datas/mysql/data/${port}/mysqld.sock -e"start slave"
check_las_comm "$?" "start slave failed"執行時間
2019–04–08–11:17:36 停止從服務器 mysql: [警告] 在命令行界面使用密碼可能不安全。 ddl_start 2019–04–08 11:17:36 ddl_stop 2019–04–08 11:45:13 2019–04–08–11:45:13 online ddl stop 2019–04–08 –11:45:13 添加外鍵。
mysql: [警告] 在命令行界面使用密碼可能不安全。 2019–04–08–12:33:48 添加外鍵停止 2019–04–08 –12:33:48 啟動從服務器。
重新檢查刪除和選擇語句的執行計劃。
explain select count(*) from arrival_record where receive_time < STR_TO_DATE('2019-03-10', '%Y-%m-%d')\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: arrival_record
partitions: NULL
type: range
possible_keys: idx_receive_time
key: idx_receive_time
key_len: 6
ref: NULL
rows: 7540948
filtered: 100.00
Extra: Using where; Using index
explain select count(*) from arrival_record where product_id=26 and receive_time between '2019-03-25 14:00:00' and '2019-03-25 15:00:00' and receive_spend_ms>=0\G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: arrival_record
partitions: NULL
type: range
possible_keys: idx_product_id_sequence_station_no,idx_receive_time
key: idx_receive_time
key_len: 6
ref: NULL
rows: 291448
filtered: 16.66
Extra: Using index condition; Using where所有查詢都使用了 idx_receive_time 索引，大大減少了掃描的行數。
索引優化后
刪除操作仍然花費了 77 秒。
delete from arrival_record where receive_time < STR_TO_DATE('2019-03-10', '%Y-%m-%d')\G該刪除語句利用 receive_time 索引刪除了超過 300 萬條記錄，耗時 77 秒。
大表刪除小批量優化
應用程序已優化為每 10 分鐘刪除一次數據（每次執行時間約 1 秒），在 xxx 中沒有出現 SLA（主從延遲警報）事件。
另一種方法是按主鍵順序一次刪除 20,000 條記錄。
# 獲取符合時間條件的最大主鍵 ID
# 按主鍵順序逐步掃描小批量刪除數據
# 首先執行以下語句
SELECT MAX(id) INTO @need_delete_max_id FROM `arrival_record` WHERE receive_time<'2019-03-01';
DELETE FROM arrival_record WHERE id<@need_delete_max_id LIMIT 20000;
select ROW_COUNT(); # 返回 20000
# 在執行小批量刪除后，返回 row_count()，表示刪除的行數
# 程序檢查返回的 row_count() 是否為 0，如果不是，則執行以下循環；如果為 0，則退出循環，刪除完成
DELETE FROM arrival_record WHERE id<@need_delete_max_id LIMIT 20000;
select ROW_COUNT();
# 程序休眠 0.5 秒總結
- 當表的大小過大時，除了關注訪問此表的響應時間外，還應考慮表的維護成本（例如 DDL 操作所需的時間和刪除歷史數據的時間）。
- 在對大表進行 DDL 操作時，應考慮表的實際情況（例如表的并發性、是否有外鍵）以選擇合適的 DDL 變更方法。
- 對于從表中刪除大量數據，應采用小批量刪除的方法，以減少主實例的壓力和主從延遲。
責任編輯：武曉燕
來源：
路條編程
