自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

優(yōu)化實錄!如何將 MySQL 查詢時間從 190 秒縮減到 1 秒,輕松應(yīng)對千萬數(shù)據(jù)

開發(fā) 前端
當(dāng)表的大小過大時,除了關(guān)注訪問此表的響應(yīng)時間外,還應(yīng)考慮表的維護成本(例如 DDL 操作所需的時間和刪除歷史數(shù)據(jù)的時間)。

最近,我在工作中遇到一個數(shù)據(jù)庫配置問題,涉及一個主從結(jié)構(gòu)的數(shù)據(jù)庫實例。具體來說,該數(shù)據(jù)庫每天凌晨會觸發(fā)SLA(服務(wù)級別協(xié)議)警報。這個警報表明主從同步延遲顯著。這意味著如果在這個時間點嘗試從主庫切換到從庫,切換的完成時間會非常長。系統(tǒng)需要額外的時間來趕上并同步延遲的數(shù)據(jù),以確保主庫和從庫之間的數(shù)據(jù)一致性。進一步分析顯示,這個問題的一個主要驅(qū)動因素是該數(shù)據(jù)庫實例中存在大量慢查詢。

這些慢查詢定義為執(zhí)行時間超過1秒的SQL查詢。

我們發(fā)現(xiàn),應(yīng)用程序每晚執(zhí)行的一個特定任務(wù)——刪除一個月前的舊數(shù)據(jù)——是這些慢查詢的主要來源。

分析

利用pt-query-digest工具分析最近一周的mysql-slow.log。

pt-query-digest --since=148h mysql-slow.log | less

結(jié)果第二部分

圖片圖片

在過去一周,總共記錄的慢查詢執(zhí)行時間為25403秒,最長的慢SQL執(zhí)行時間為266秒,平均每個慢SQL的執(zhí)行時間為5秒,平均掃描的行數(shù)為1766萬。

結(jié)果第二部分

圖片圖片

選擇arrival_record操作的慢查詢次數(shù)超過4萬次,平均響應(yīng)時間為4秒。刪除arrival_record的記錄6次,平均響應(yīng)時間為258秒。

select xxx_record語句

選擇arrival_record的慢查詢語句類似于以下,where子句中的參數(shù)字段相同,但參數(shù)值不同: *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中的平均掃描行數(shù)為172萬,推斷出掃描行數(shù)過多導(dǎo)致執(zhí)行時間長。

查看執(zhí)行計劃

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,但估算掃描的行數(shù)非常大,超過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億條記錄,只有一個復(fù)合索引。product_id字段的基數(shù)非常低,選擇性差,不適合查詢。
  • 提供的過濾條件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字段,因此未能利用復(fù)合索引IXFK_arrival_record的字段product_id、station_no、sequence和receive_time。
  • 根據(jù)左前綴原則,選擇arrival_record只使用復(fù)合索引IXFK_arrival_record的第一個字段product_id,其選擇性差,導(dǎo)致掃描的行數(shù)較多,執(zhí)行時間較長。
  • receive_time字段具有較高的基數(shù)和良好的選擇性,單獨為該字段創(chuàng)建索引是有益的。然后,選擇arrival_record的SQL將會利用這個索引。

現(xiàn)在我們知道arrival_record的慢查詢?nèi)罩局械膚here語句包含了字段product_id、receive_time、receive_spend_ms的參數(shù),我們想知道是否還有其他字段用于過濾訪問這個表?

強大工具tcpdump的登場時間

使用tcpdump捕獲一段時間內(nèi)針對該表的select語句的數(shù)據(jù)包。

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 字段,可以利用復(fù)合索引 IXFK_arrival_record 的前三個字段。

總結(jié)來說,優(yōu)化方法是刪除復(fù)合索引 IXFK_arrival_record,創(chuàng)建一個新的復(fù)合索引 idx_sequence_station_no_product_id,并建立單獨的索引 indx_receive_time。

刪除 xxx_record 語句

刪除操作的平均掃描量為 1.1 億行,平均執(zhí)行時間為 262 秒。

下面是刪除語句,每個慢查詢記錄不同的參數(shù)值:

delete from arrival_record where receive_time < STR_TO_DATE('2019-02-23', '%Y-%m-%d')\G

執(zhí)行計劃:

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)

該刪除語句未使用索引(沒有合適的索引可用),導(dǎo)致全表掃描和較長的執(zhí)行時間。

優(yōu)化方法也是創(chuàng)建一個單獨的索引 indx_receive_time(receive_time)。

測試

將 arrival_record 表復(fù)制到測試實例,以在 XX 實例的 arrival_record 表 上執(zhí)行刪除和重建索引操作。

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 的碎片,主要是由于刪除造成的(刪除記錄后未回收空間)。

備份并恢復(fù)表到新實例,刪除原復(fù)合索引,并添加新索引進行測試。

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/

將備份數(shù)據(jù)復(fù)制到測試節(jié)點:

scp -rp /datas/dump_arrival_record root@10.230.124.19:/datas

多線程數(shù)據(jù)導(dǎo)入:

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 系統(tǒng) 0m4.267s

邏輯導(dǎo)入表后的磁盤空間使用:

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 工具進行索引刪除和重建。首先,刪除外鍵;如果不這樣做,復(fù)合索引無法被刪除,因為外鍵列是復(fù)合索引中第一列的一部分。

nohup bash /tmp/ddl_index.sh &
2019-04-04-10:41:39 開始停止 mysqld_3308
2019-04-04-10:41:41 開始 rm -rf datadir 并復(fù)制 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 |
+----+-------------+-------------------+-------+---------------+---------+---------+------------------+------+-------------+

該查詢可以使用索引進行加速,最終性能提升十倍。

使用建議:

實施

由于這是一個主從實例,應(yīng)用程序連接到 VIP。刪除和重建索引使用在線 DDL 進行。在停止主從復(fù)制后,首先在從實例上執(zhí)行(不記錄 binlog),然后進行主從切換,接著在新切換的從實例上執(zhí)行(不記錄 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"

執(zhí)行時間

2019–04–08–11:17:36 停止從服務(wù)器 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 啟動從服務(wù)器。

重新檢查刪除和選擇語句的執(zhí)行計劃。

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 索引,大大減少了掃描的行數(shù)。

索引優(yōu)化后

刪除操作仍然花費了 77 秒。

delete from arrival_record where receive_time < STR_TO_DATE('2019-03-10', '%Y-%m-%d')\G

該刪除語句利用 receive_time 索引刪除了超過 300 萬條記錄,耗時 77 秒。

大表刪除小批量優(yōu)化

應(yīng)用程序已優(yōu)化為每 10 分鐘刪除一次數(shù)據(jù)(每次執(zhí)行時間約 1 秒),在 xxx 中沒有出現(xiàn) SLA(主從延遲警報)事件。

另一種方法是按主鍵順序一次刪除 20,000 條記錄。

# 獲取符合時間條件的最大主鍵 ID
# 按主鍵順序逐步掃描小批量刪除數(shù)據(jù)
# 首先執(zhí)行以下語句
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

# 在執(zhí)行小批量刪除后,返回 row_count(),表示刪除的行數(shù)
# 程序檢查返回的 row_count() 是否為 0,如果不是,則執(zhí)行以下循環(huán);如果為 0,則退出循環(huán),刪除完成
DELETE FROM arrival_record WHERE id<@need_delete_max_id LIMIT 20000;
select ROW_COUNT();
# 程序休眠 0.5 秒

總結(jié)

  • 當(dāng)表的大小過大時,除了關(guān)注訪問此表的響應(yīng)時間外,還應(yīng)考慮表的維護成本(例如 DDL 操作所需的時間和刪除歷史數(shù)據(jù)的時間)。
  • 在對大表進行 DDL 操作時,應(yīng)考慮表的實際情況(例如表的并發(fā)性、是否有外鍵)以選擇合適的 DDL 變更方法。
  • 對于從表中刪除大量數(shù)據(jù),應(yīng)采用小批量刪除的方法,以減少主實例的壓力和主從延遲。
責(zé)任編輯:武曉燕 來源: 路條編程
相關(guān)推薦

2019-11-12 13:30:07

開源技術(shù) 軟件

2024-10-31 10:41:01

2023-05-29 12:35:09

模型ChatGPT

2022-09-26 09:41:25

MySQL數(shù)據(jù)庫

2013-03-26 10:10:38

服務(wù)器RubyGo

2019-08-21 14:35:18

壓縮文件優(yōu)化過程Java

2020-11-12 18:51:43

Java編程語言

2024-04-10 08:00:00

PostgresNoSQL

2022-11-03 10:28:43

Docker

2021-04-07 13:43:07

PythonDash數(shù)據(jù)庫

2010-08-31 09:03:07

IT技術(shù)周刊

2012-06-20 11:17:02

MemSQL

2012-04-28 14:07:41

AMD數(shù)據(jù)中心

2021-08-26 22:26:55

性能優(yōu)化技術(shù)

2024-11-08 09:34:54

2025-03-27 00:14:10

2021-08-30 16:47:00

Firefox 93Chrome簡化

2019-11-27 09:48:04

數(shù)據(jù)ESHBase

2023-08-08 12:55:30

強化學(xué)習(xí)訓(xùn)練
點贊
收藏

51CTO技術(shù)棧公眾號