优化实录！如何将 MySQL 查询时间从 190 秒缩减到 1 秒，轻松应对千万数据
最近，我在工作中遇到一个数据库配置问题，涉及一个主从结构的数据库实例。具体来说，该数据库每天凌晨会触发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 的高压缩比！）。
开始备份于：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 变更方法。
对于从表中删除大量数据，应采用小批量删除的方法，以减少主实例的压力和主从延迟。
