Các vấn đề về hiệu suất là những vấn đề thường gặp khi quản trị cơ sở dữ liệu MySQL. Đôi khi những vấn đề này trên thực tế là do các truy vấn chậm. Trong blog này, chúng tôi sẽ giải quyết các truy vấn chậm và cách xác định các truy vấn này.
Kiểm tra nhật ký truy vấn chậm của bạn
MySQL có khả năng lọc và ghi nhật ký các truy vấn chậm. Có nhiều cách khác nhau để bạn có thể điều tra những điều này, nhưng cách phổ biến và hiệu quả nhất là sử dụng nhật ký truy vấn chậm.
Trước tiên, bạn cần xác định xem nhật ký truy vấn chậm của bạn có được bật hay không. Để giải quyết vấn đề này, bạn có thể truy cập máy chủ của mình và truy vấn biến sau:
MariaDB [(none)]> show global variables like 'slow%log%';
+---------------------+-------------------------------+
| Variable_name | Value |
+---------------------+-------------------------------+
| slow_query_log | ON |
| slow_query_log_file | /var/log/mysql/mysql-slow.log |
+---------------------+-------------------------------+
2 rows in set (0.001 sec)Bạn phải đảm bảo rằng biến slow_query_log được đặt thành BẬT, trong khi slow_query_log_file xác định đường dẫn mà bạn cần đặt nhật ký truy vấn chậm của mình. Nếu biến này không được đặt, biến này sẽ sử dụng DATA_DIR của thư mục dữ liệu MySQL của bạn.
Đi kèm với biến slow_query_log là long_query_time và min_examined_row_limit, các biến này sẽ ảnh hưởng đến cách hoạt động của ghi nhật ký truy vấn chậm. Về cơ bản, nhật ký truy vấn chậm hoạt động như các câu lệnh SQL mất hơn long_query_time giây để thực thi và cũng yêu cầu kiểm tra ít nhất hàng min_examined_row_limit. Nó có thể được sử dụng để tìm các truy vấn mất nhiều thời gian để thực thi và do đó là ứng cử viên để tối ưu hóa và sau đó bạn có thể sử dụng các công cụ bên ngoài để mang báo cáo cho bạn, sẽ nói sau.
Theo mặc định, các câu lệnh quản trị (ALTER TABLE, ANALYZE TABLE, CHECK TABLE, CREATE INDEX, DROP INDEX, OPTIMIZE TABLE, và REPAIR TABLE) không rơi vào nhật ký truy vấn chậm. Để làm được điều này, bạn cần bật biến log_slow_admin_statements.
Danh sách Quy trình Truy vấn và Trình theo dõi Trạng thái InnoDB
Trong quy trình DBA thông thường, bước này là cách phổ biến nhất để xác định các truy vấn đang chạy lâu hoặc các truy vấn đang hoạt động gây ra suy giảm hiệu suất. Nó thậm chí có thể khiến máy chủ của bạn bị kẹt, theo sau là các hàng đợi chồng chất đang tăng dần do bị khóa bởi một truy vấn đang chạy. Bạn chỉ cần chạy,
SHOW [FULL] PROCESSLIST;hoặc
SHOW ENGINE INNODB STATUS \G Nếu bạn đang sử dụng ClusterControl, bạn có thể tìm thấy nó bằng cách sử dụng
hoặc sử dụng
Phân tích Truy vấn MySQL
Nhật ký truy vấn chậm sẽ hiển thị cho bạn danh sách các truy vấn đã được xác định là chậm, dựa trên các giá trị đã cho trong các biến hệ thống như đã đề cập trước đó. Định nghĩa truy vấn chậm có thể khác nhau trong các trường hợp khác nhau vì có những trường hợp nhất định mà ngay cả một truy vấn 10 giây cũng được chấp nhận và vẫn không chậm. Tuy nhiên, nếu ứng dụng của bạn là OLTP, thì việc truy vấn 10 giây hoặc thậm chí 5 giây là một vấn đề hoặc gây suy giảm hiệu suất cho cơ sở dữ liệu của bạn rất phổ biến. Nhật ký truy vấn MySQL giúp bạn điều này nhưng không đủ để mở tệp nhật ký vì nó không cung cấp cho bạn tổng quan về những truy vấn đó là gì, cách chúng thực hiện và tần suất xuất hiện của chúng là gì. Do đó, các công cụ của bên thứ ba có thể giúp bạn những điều này.
pt-truy vấn-thông báo
Sử dụng Bộ công cụ Percona, mà tôi có thể nói là công cụ DBA phổ biến nhất, là sử dụng pt-truy vấn-thông báo. pt-truy vấn-thông báo cung cấp cho bạn một cái nhìn tổng quan rõ ràng về một báo cáo cụ thể đến từ nhật ký truy vấn chậm của bạn. Ví dụ:báo cáo cụ thể này cho thấy quan điểm rõ ràng về việc hiểu các báo cáo truy vấn chậm trong một nút cụ thể:
# A software update is available:
# 100ms user time, 100ms system time, 29.12M rss, 242.41M vsz
# Current date: Mon Feb 3 20:26:11 2020
# Hostname: testnode7
# Files: /var/log/mysql/mysql-slow.log
# Overall: 24 total, 14 unique, 0.00 QPS, 0.02x concurrency ______________
# Time range: 2019-12-12T10:01:16 to 2019-12-12T15:31:46
# Attribute total min max avg 95% stddev median
# ============ ======= ======= ======= ======= ======= ======= =======
# Exec time 345s 1s 98s 14s 30s 19s 7s
# Lock time 1s 0 1s 58ms 24ms 252ms 786us
# Rows sent 5.72M 0 1.91M 244.14k 1.86M 629.44k 0
# Rows examine 15.26M 0 1.91M 651.23k 1.86M 710.58k 961.27k
# Rows affecte 9.54M 0 1.91M 406.90k 961.27k 546.96k 0
# Bytes sent 305.81M 11 124.83M 12.74M 87.73M 33.48M 56.92
# Query size 1.20k 25 244 51.17 59.77 40.60 38.53
# Profile
# Rank Query ID Response time Calls R/Call V/M
# ==== ================================ ============= ===== ======= =====
# 1 0x00C8412332B2795DADF0E55C163... 98.0337 28.4% 1 98.0337 0.00 UPDATE sbtest?
# 2 0xDEF289292EA9B2602DC12F70C7A... 74.1314 21.5% 3 24.7105 6.34 ALTER TABLE sbtest? sbtest3
# 3 0x148D575F62575A20AB9E67E41C3... 37.3039 10.8% 6 6.2173 0.23 INSERT SELECT sbtest? sbtest
# 4 0xD76A930681F1B4CC9F748B4398B... 32.8019 9.5% 3 10.9340 4.24 SELECT sbtest?
# 5 0x7B9A47FF6967FD905289042DD3B... 20.6685 6.0% 1 20.6685 0.00 ALTER TABLE sbtest? sbtest3
# 6 0xD1834E96EEFF8AC871D51192D8F... 19.0787 5.5% 1 19.0787 0.00 CREATE
# 7 0x2112E77F825903ED18028C7EA76... 18.7133 5.4% 1 18.7133 0.00 ALTER TABLE sbtest? sbtest3
# 8 0xC37F2569578627487D948026820... 15.0177 4.3% 2 7.5088 0.00 INSERT SELECT sbtest? sbtest
# 9 0xDE43B2066A66AFA881D6D45C188... 13.7180 4.0% 1 13.7180 0.00 ALTER TABLE sbtest? sbtest3
# MISC 0xMISC 15.8605 4.6% 5 3.1721 0.0 <5 ITEMS>
# Query 1: 0 QPS, 0x concurrency, ID 0x00C8412332B2795DADF0E55C1631626D at byte 5319
# Scores: V/M = 0.00
# Time range: all events occurred at 2019-12-12T13:23:15
# Attribute pct total min max avg 95% stddev median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Count 4 1
# Exec time 28 98s 98s 98s 98s 98s 0 98s
# Lock time 1 25ms 25ms 25ms 25ms 25ms 0 25ms
# Rows sent 0 0 0 0 0 0 0 0
# Rows examine 12 1.91M 1.91M 1.91M 1.91M 1.91M 0 1.91M
# Rows affecte 20 1.91M 1.91M 1.91M 1.91M 1.91M 0 1.91M
# Bytes sent 0 67 67 67 67 67 0 67
# Query size 7 89 89 89 89 89 0 89
# String:
# Databases test
# Hosts localhost
# Last errno 0
# Users root
# Query_time distribution
# 1us
# 10us
# 100us
# 1ms
# 10ms
# 100ms
# 1s
# 10s+ ################################################################
# Tables
# SHOW TABLE STATUS FROM `test` LIKE 'sbtest3'\G
# SHOW CREATE TABLE `test`.`sbtest3`\G
update sbtest3 set c=substring(MD5(RAND()), -16), pad=substring(MD5(RAND()), -16) where 1\G
# Converted for EXPLAIN
# EXPLAIN /*!50100 PARTITIONS*/
select c=substring(MD5(RAND()), -16), pad=substring(MD5(RAND()), -16) from sbtest3 where 1\G
# Query 2: 0.00 QPS, 0.01x concurrency, ID 0xDEF289292EA9B2602DC12F70C7A041A9 at byte 3775
# Scores: V/M = 6.34
# Time range: 2019-12-12T12:41:47 to 2019-12-12T15:25:14
# Attribute pct total min max avg 95% stddev median
# ============ === ======= ======= ======= ======= ======= ======= =======
# Count 12 3
# Exec time 21 74s 6s 36s 25s 35s 13s 30s
# Lock time 0 13ms 1ms 8ms 4ms 8ms 3ms 3ms
# Rows sent 0 0 0 0 0 0 0 0
# Rows examine 0 0 0 0 0 0 0 0
# Rows affecte 0 0 0 0 0 0 0 0
# Bytes sent 0 144 44 50 48 49.17 3 49.17
# Query size 8 99 33 33 33 33 0 33
# String:
# Databases test
# Hosts localhost
# Last errno 0 (2/66%), 1317 (1/33%)
# Users root
# Query_time distribution
# 1us
# 10us
# 100us
# 1ms
# 10ms
# 100ms
# 1s ################################
# 10s+ ################################################################
# Tables
# SHOW TABLE STATUS FROM `test` LIKE 'sbtest3'\G
# SHOW CREATE TABLE `test`.`sbtest3`\G
ALTER TABLE sbtest3 ENGINE=INNODB\GSử dụng performance_schema
Nhật ký truy vấn chậm có thể là một vấn đề nếu bạn không có quyền truy cập trực tiếp vào tệp, chẳng hạn như sử dụng RDS hoặc sử dụng các dịch vụ cơ sở dữ liệu được quản lý đầy đủ như Google Cloud SQL hoặc Azure SQL. Mặc dù nó có thể cần bạn một số biến để kích hoạt các tính năng này, nhưng nó rất hữu ích khi truy vấn các truy vấn đã đăng nhập vào hệ thống của bạn. Bạn có thể sắp xếp nó bằng cách sử dụng một câu lệnh SQL chuẩn để truy xuất một phần kết quả. Ví dụ,
mysql> SELECT SCHEMA_NAME, DIGEST, DIGEST_TEXT, COUNT_STAR, SUM_TIMER_WAIT/1000000000000 SUM_TIMER_WAIT_SEC, MIN_TIMER_WAIT/1000000000000 MIN_TIMER_WAIT_SEC, AVG_TIMER_WAIT/1000000000000 AVG_TIMER_WAIT_SEC, MAX_TIMER_WAIT/1000000000000 MAX_TIMER_WAIT_SEC, SUM_LOCK_TIME/1000000000000 SUM_LOCK_TIME_SEC, FIRST_SEEN, LAST_SEEN FROM events_statements_summary_by_digest;
+--------------------+----------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+--------------------+--------------------+--------------------+--------------------+-------------------+---------------------+---------------------+
| SCHEMA_NAME | DIGEST | DIGEST_TEXT | COUNT_STAR | SUM_TIMER_WAIT_SEC | MIN_TIMER_WAIT_SEC | AVG_TIMER_WAIT_SEC | MAX_TIMER_WAIT_SEC | SUM_LOCK_TIME_SEC | FIRST_SEEN | LAST_SEEN |
+--------------------+----------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------+--------------------+--------------------+--------------------+--------------------+-------------------+---------------------+---------------------+
| NULL | 390669f3d1f72317dab6deb40322d119 | SELECT @@`skip_networking` , @@`skip_name_resolve` , @@`have_ssl` = ? , @@`ssl_key` , @@`ssl_ca` , @@`ssl_capath` , @@`ssl_cert` , @@`ssl_cipher` , @@`ssl_crl` , @@`ssl_crlpath` , @@`tls_version` | 1 | 0.0373 | 0.0373 | 0.0373 | 0.0373 | 0.0000 | 2020-02-03 20:22:54 | 2020-02-03 20:22:54 |
| NULL | fba95d44e3d0a9802dd534c782314352 | SELECT `UNIX_TIMESTAMP` ( ) | 2 | 0.0002 | 0.0001 | 0.0001 | 0.0001 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | 18c649da485456d6cdf12e4e6b0350e9 | SELECT @@GLOBAL . `SERVER_ID` | 2 | 0.0001 | 0.0001 | 0.0001 | 0.0001 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | dd356b8a5a6ed0d7aee2abd939cdb6c9 | SET @? = ? | 6 | 0.0003 | 0.0000 | 0.0001 | 0.0001 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | 1c5ae643e930af6d069845d74729760d | SET @? = @@GLOBAL . `binlog_checksum` | 2 | 0.0001 | 0.0001 | 0.0001 | 0.0001 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | ad5208ffa004a6ad7e26011b73cbfb4c | SELECT @? | 2 | 0.0001 | 0.0000 | 0.0000 | 0.0001 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | ed0d1eb982c106d4231b816539652907 | SELECT @@GLOBAL . `GTID_MODE` | 2 | 0.0001 | 0.0000 | 0.0000 | 0.0001 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | cb47e22372fdd4441486b02c133fb94f | SELECT @@GLOBAL . `SERVER_UUID` | 2 | 0.0001 | 0.0000 | 0.0000 | 0.0001 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | 73301368c301db5d2e3db5626a21b647 | SELECT @@GLOBAL . `rpl_semi_sync_master_enabled` | 2 | 0.0001 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 2020-02-03 20:22:57 | 2020-02-03 20:23:00 |
| NULL | 0ff7375c5f076ba5c040e78a9250a659 | SELECT @@`version_comment` LIMIT ? | 1 | 0.0001 | 0.0001 | 0.0001 | 0.0001 | 0.0000 | 2020-02-03 20:45:59 | 2020-02-03 20:45:59 |
| NULL | 5820f411e67a393f987c6be5d81a011d | SHOW TABLES FROM `performance_schema` | 1 | 0.0008 | 0.0008 | 0.0008 | 0.0008 | 0.0002 | 2020-02-03 20:46:11 | 2020-02-03 20:46:11 |
| NULL | a022a0ab966c51eb820da1521349c7ef | SELECT SCHEMA ( ) | 1 | 0.0005 | 0.0005 | 0.0005 | 0.0005 | 0.0000 | 2020-02-03 20:46:29 | 2020-02-03 20:46:29 |
| performance_schema | e4833a7c1365b0b4492e9a514f7b3bd4 | SHOW SCHEMAS | 1 | 0.1167 | 0.1167 | 0.1167 | 0.1167 | 0.0001 | 2020-02-03 20:46:29 | 2020-02-03 20:46:29 |
| performance_schema | 1107f048fe6d970cb6a553bd4727a1b4 | SHOW TABLES | 1 | 0.0002 | 0.0002 | 0.0002 | 0.0002 | 0.0000 | 2020-02-03 20:46:29 | 2020-02-03 20:46:29 |
...Bạn có thể sử dụng bảng performance_schema.events_statements_summary_by_digest. Mặc dù có khả năng các mục nhập trên các bảng từ performance_schema sẽ bị xóa, bạn có thể quyết định lưu nó vào một bảng cụ thể. Hãy xem bài đăng bên ngoài này từ thông báo truy vấn Percona MySQL với Lược đồ hiệu suất.
Trong trường hợp bạn đang thắc mắc tại sao chúng ta cần chia các cột thời gian chờ (SUM_TIMER_WAIT, MIN_TIMER_WAIT_SEC, AVG_TIMER_WAIT_SEC), các cột này đang sử dụng pico giây, vì vậy bạn có thể cần thực hiện một số phép toán hoặc một số phép tính tròn nó dễ đọc hơn đối với bạn.
Phân tích các Truy vấn Chậm bằng ClusterControl
Nếu bạn đang sử dụng ClusterControl, có nhiều cách khác nhau để giải quyết vấn đề này. Ví dụ:trong Cụm MariaDB mà tôi có bên dưới, nó hiển thị cho bạn tab sau (Trình theo dõi truy vấn) và các mục thả xuống của nó (Truy vấn hàng đầu, Truy vấn đang chạy, Ngoại trừ truy vấn):
- Các truy vấn hàng đầu - danh sách tổng hợp tất cả các truy vấn hàng đầu của bạn đang chạy trên tất cả các nút của cụm cơ sở dữ liệu của bạn
- Truy vấn đang chạy - Xem các truy vấn đang chạy hiện tại trên cụm cơ sở dữ liệu của bạn tương tự như lệnh SHOW FULL PROCESSLIST trong MySQL
- Truy vấn ngoại lệ - Hiển thị các truy vấn ngoại lệ. Ngoại lệ là một truy vấn mất nhiều thời gian hơn so với truy vấn bình thường của loại đó.
Trên hết, ClusterControl cũng nắm bắt hiệu suất truy vấn bằng cách sử dụng đồ thị cung cấp cho bạn cái nhìn nhanh về cách hệ thống cơ sở dữ liệu của bạn hoạt động liên quan đến hiệu suất truy vấn. Xem bên dưới,
Chờ đã, vẫn chưa kết thúc. ClusterControl cũng cung cấp số liệu có độ phân giải cao bằng cách sử dụng Prometheus và hiển thị các số liệu rất chi tiết và thu thập số liệu thống kê thời gian thực từ máy chủ. Chúng tôi đã thảo luận điều này trong các blog trước đây của chúng tôi được chia thành hai loạt blog. Xem phần 1 và sau đó là phần 2 blog. Nó cung cấp cho bạn cách giám sát hiệu quả không chỉ các truy vấn chậm mà còn cả hiệu suất tổng thể của các máy chủ cơ sở dữ liệu MySQL, MariaDB hoặc Percona của bạn.
Ngoài ra còn có các công cụ khác trong ClusterControl cung cấp các con trỏ và gợi ý có thể gây ra hiệu suất truy vấn chậm ngay cả khi nó chưa xảy ra hoặc được ghi lại bởi nhật ký truy vấn chậm. Kiểm tra Tab Hiệu suất như bên dưới,
các mục này cung cấp cho bạn những điều sau:
- Tổng quan - Bạn có thể xem đồ thị của các bộ đếm cơ sở dữ liệu khác nhau trên trang này
- Cố vấn - Danh sách các kết quả được lập lịch của cố vấn được tạo trong ClusterControl> Quản lý> Developer Studio bằng ClusterControl DSL.
- Trạng thái DB - Trạng thái DB cung cấp tổng quan nhanh về trạng thái MySQL trên tất cả các nút cơ sở dữ liệu của bạn, tương tự như câu lệnh SHOW STATUS
- Biến DB - Biến DB cung cấp tổng quan nhanh về các biến MySQL được đặt trên tất cả các nút cơ sở dữ liệu của bạn, tương tự như câu lệnh SHOW GLOBAL VARIABLES
- Tăng trưởng DB - Cung cấp bản tóm tắt về mức tăng trưởng cơ sở dữ liệu và bảng của bạn hàng ngày trong 30 ngày qua.
- Trạng thái InnoDB - Tìm nạp đầu ra màn hình InnoDB hiện tại cho máy chủ đã chọn, tương tự như lệnh SHOW ENGINE INNODB STATUS.
- Trình phân tích lược đồ - Phân tích các lược đồ cơ sở dữ liệu của bạn để tìm các khóa chính bị thiếu, các chỉ mục và bảng dự phòng bằng cách sử dụng công cụ lưu trữ MyISAM.
- Nhật ký giao dịch - Liệt kê các giao dịch đã hoạt động lâu dài và các lần bế tắc trên toàn bộ cụm cơ sở dữ liệu, nơi bạn có thể dễ dàng xem các giao dịch nào đang gây ra sự cố. Ngưỡng thời gian truy vấn mặc định là 30 giây.
Kết luận
Việc theo dõi vấn đề Hiệu suất MySQL của bạn không thực sự khó với MySQL. Có nhiều công cụ bên ngoài khác nhau cung cấp cho bạn hiệu quả và khả năng mà bạn đang tìm kiếm. Điều quan trọng nhất là, nó dễ sử dụng và bạn có thể cung cấp năng suất trong công việc. Khắc phục các vấn đề còn tồn tại hoặc thậm chí tránh một thảm họa nào đó trước khi nó có thể xảy ra.
