Query Outlier là gì và Cách khắc phục

Khối lượng công việc của cơ sở dữ liệu MySQL được xác định bởi số lượng truy vấn mà nó xử lý. Có một số tình huống mà sự chậm chạp của MySQL có thể bắt nguồn. Khả năng đầu tiên là nếu có bất kỳ truy vấn nào không sử dụng lập chỉ mục thích hợp. Khi một truy vấn không thể sử dụng một chỉ mục, máy chủ MySQL phải sử dụng nhiều tài nguyên và thời gian hơn để xử lý truy vấn đó. Bằng cách theo dõi các truy vấn, bạn có khả năng xác định mã SQL là nguyên nhân gốc rễ gây ra sự chậm chạp và khắc phục nó trước khi hiệu suất tổng thể giảm sút.

Trong bài đăng trên blog này, chúng tôi sẽ làm nổi bật tính năng Query Outlier có sẵn trong ClusterControl và xem nó có thể giúp chúng tôi cải thiện hiệu suất cơ sở dữ liệu như thế nào. Nói chung, ClusterControl thực hiện lấy mẫu truy vấn MySQL theo hai cách:

1. Tìm nạp các truy vấn từ Giản đồ hiệu suất ( khuyến nghị ).
2. Phân tích cú pháp nội dung của MySQL Slow Query.

Nếu Lược đồ Hiệu suất bị tắt, ClusterControl sau đó sẽ mặc định là Nhật ký Truy vấn Chậm. Để tìm hiểu thêm về cách ClusterControl thực hiện việc này, hãy xem bài đăng trên blog này, Cách sử dụng Trình theo dõi truy vấn ClusterControl cho MySQL, MariaDB và Máy chủ Percona.

Ngoại lệ Truy vấn là gì?

Ngoại lệ là truy vấn mất nhiều thời gian hơn thời gian truy vấn bình thường của loại đó. Đừng coi đây là truy vấn "viết xấu" theo nghĩa đen. Nó nên được coi là những truy vấn chung không tối ưu tiềm năng có thể được cải thiện. Sau một số mẫu và khi ClusterControl đã có đủ số liệu thống kê, nó có thể xác định xem độ trễ có cao hơn bình thường hay không (2 sigmas + average_query_time) thì đó là một ngoại lệ và sẽ được thêm vào Query Outlier.

Tính năng này phụ thuộc vào tính năng Truy vấn hàng đầu. Nếu Giám sát truy vấn được bật và các Truy vấn hàng đầu được ghi lại và điền vào, thì các Truy vấn ngoại lai sẽ tóm tắt những điều này và cung cấp một bộ lọc dựa trên dấu thời gian. Để xem danh sách các truy vấn cần chú ý, hãy chuyển đến ClusterControl -> Query Monitor -> Query Outceptions và sẽ thấy một số truy vấn được liệt kê (nếu có):

Như bạn có thể thấy từ ảnh chụp màn hình ở trên, các ngoại lệ về cơ bản là các truy vấn mất ít nhất 2 lần so với thời gian truy vấn trung bình. Đầu tiên là mục nhập đầu tiên, thời gian trung bình là 34,41 ms trong khi thời gian truy vấn của người ngoài là 140 ms (cao hơn 2 lần so với thời gian trung bình). Tương tự, đối với các mục tiếp theo, cột Thời gian truy vấn và Thời gian truy vấn tr.bình là hai cột quan trọng để chứng minh những điểm nổi bật của một truy vấn ngoại lệ cụ thể.

Tương đối dễ dàng tìm thấy một mẫu ngoại trừ truy vấn cụ thể bằng cách xem xét một khoảng thời gian lớn hơn, như một tuần trước, như được đánh dấu trong ảnh chụp màn hình sau:

Bằng cách nhấp vào từng hàng, bạn có thể xem toàn bộ truy vấn thực sự là hữu ích để xác định và hiểu vấn đề, như được hiển thị trong phần tiếp theo.

Khắc phục các Ngoại lệ Truy vấn

Để khắc phục các ngoại lệ, chúng ta cần hiểu bản chất của truy vấn, công cụ lưu trữ của bảng, phiên bản cơ sở dữ liệu, kiểu phân cụm và mức độ ảnh hưởng của truy vấn. Trong một số trường hợp, truy vấn ngoại lệ không thực sự làm giảm hiệu suất cơ sở dữ liệu tổng thể. Như trong ví dụ này, chúng tôi thấy rằng truy vấn đã nổi bật trong cả tuần và đây là loại truy vấn duy nhất được ghi lại, vì vậy có lẽ bạn nên sửa hoặc cải thiện truy vấn này nếu có thể.

Như trong trường hợp của chúng tôi, truy vấn ngoại lệ là:

SELECT i2l.country_code AS country_code, i2l.country_name AS country_name 
FROM ip2location i2l 
WHERE (i2l.ip_to >= INET_ATON('104.144.171.139') 
AND i2l.ip_from <= INET_ATON('104.144.171.139')) 
LIMIT 1 
OFFSET 0;

Và kết quả truy vấn là:

+--------------+---------------+
| country_code | country_name  |
+--------------+---------------+
| US           | United States |
+--------------+---------------+

Sử dụng GIẢI THÍCH

Truy vấn là truy vấn chọn phạm vi chỉ đọc để xác định thông tin vị trí địa lý của người dùng (mã quốc gia và tên quốc gia) cho địa chỉ IP trên bảng ip2location. Sử dụng câu lệnh EXPLAIN có thể giúp chúng tôi hiểu kế hoạch thực thi truy vấn:

mysql> EXPLAIN SELECT i2l.country_code AS country_code, i2l.country_name AS country_name 
FROM ip2location i2l 
WHERE (i2l.ip_to>=INET_ATON('104.144.171.139') 
AND i2l.ip_from<=INET_ATON('104.144.171.139')) 
LIMIT 1 OFFSET 0;
+----+-------------+-------+------------+-------+--------------------------------------+-------------+---------+------+-------+----------+------------------------------------+
| id | select_type | table | partitions | type  | possible_keys                        | key         | key_len | ref  | rows  | filtered | Extra                              |
+----+-------------+-------+------------+-------+--------------------------------------+-------------+---------+------+-------+----------+------------------------------------+
|  1 | SIMPLE      | i2l   | NULL       | range | idx_ip_from,idx_ip_to,idx_ip_from_to | idx_ip_from | 5       | NULL | 66043 |    50.00 | Using index condition; Using where |
+----+-------------+-------+------------+-------+--------------------------------------+-------------+---------+------+-------+----------+------------------------------------+

Truy vấn được thực hiện bằng cách quét phạm vi trên bảng bằng chỉ mục idx_ip_from với 50% hàng tiềm năng (đã lọc).

Công cụ lưu trữ thích hợp

Nhìn vào cấu trúc bảng của ip2location:

mysql> SHOW CREATE TABLE ip2location\G
*************************** 1. row ***************************
       Table: ip2location
Create Table: CREATE TABLE `ip2location` (
  `ip_from` int(10) unsigned DEFAULT NULL,
  `ip_to` int(10) unsigned DEFAULT NULL,
  `country_code` char(2) COLLATE utf8_bin DEFAULT NULL,
  `country_name` varchar(64) COLLATE utf8_bin DEFAULT NULL,
  KEY `idx_ip_from` (`ip_from`),
  KEY `idx_ip_to` (`ip_to`),
  KEY `idx_ip_from_to` (`ip_from`,`ip_to`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin

Bảng này dựa trên cơ sở dữ liệu IP2location và hiếm khi được cập nhật / ghi, thường chỉ vào ngày đầu tiên của tháng dương lịch (do nhà cung cấp khuyến nghị). Vì vậy, một tùy chọn là chuyển đổi bảng thành công cụ lưu trữ MyISAM (MySQL) hoặc Aria (MariaDB) với định dạng hàng cố định để có được hiệu suất chỉ đọc tốt hơn. Lưu ý rằng điều này chỉ có thể áp dụng nếu bạn đang chạy trên MySQL hoặc MariaDB độc lập hoặc sao chép. Trên Galera Cluster và Group Replication, vui lòng sử dụng công cụ lưu trữ InnoDB (trừ khi bạn biết mình đang làm gì).

Dù sao, để chuyển đổi bảng từ InnoDB sang MyISAM với định dạng hàng cố định, chỉ cần chạy lệnh sau:

ALTER TABLE ip2location ENGINE=MyISAM ROW_FORMAT=FIXED;

Trong phép đo của chúng tôi, với 1000 thử nghiệm tra cứu địa chỉ IP ngẫu nhiên, hiệu suất truy vấn được cải thiện khoảng 20% ​​với MyISAM và định dạng hàng cố định:

• Thời gian trung bình (InnoDB): 21,467823 mili giây
• Thời gian trung bình (MyISAM Cố định): 17.175942 mili giây
• Cải tiến: 19.992157565301%

Bạn có thể mong đợi kết quả này ngay lập tức sau khi bảng được thay đổi. Không cần sửa đổi ở tầng cao hơn (ứng dụng / bộ cân bằng tải).

Điều chỉnh Truy vấn

Một cách khác là kiểm tra kế hoạch truy vấn và sử dụng một cách tiếp cận hiệu quả hơn để có kế hoạch thực thi truy vấn tốt hơn. Truy vấn tương tự cũng có thể được viết bằng truy vấn con như sau:

SELECT `country_code`, `country_name` FROM 
  (SELECT `country_code`, `country_name`, `ip_from` 
   FROM `ip2location` 
   WHERE ip_to >= INET_ATON('104.144.171.139') 
   LIMIT 1) 
AS temptable 
WHERE ip_from <= INET_ATON('104.144.171.139');

Truy vấn đã điều chỉnh có kế hoạch thực thi truy vấn sau:

mysql> EXPLAIN SELECT `country_code`,`country_name` FROM 
(SELECT `country_code`, `country_name`, `ip_from` 
FROM `ip2location` 
WHERE ip_to >= INET_ATON('104.144.171.139') 
LIMIT 1) 
AS temptable 
WHERE ip_from <= INET_ATON('104.144.171.139');
+----+-------------+--------------+------------+--------+---------------+-----------+---------+------+-------+----------+-----------------------+
| id | select_type | table        | partitions | type   | possible_keys | key       | key_len | ref  | rows  | filtered | Extra                 |
+----+-------------+--------------+------------+--------+---------------+-----------+---------+------+-------+----------+-----------------------+
|  1 | PRIMARY     | <derived2>   | NULL       | system | NULL          | NULL      | NULL    | NULL |     1 |   100.00 | NULL                  |
|  2 | DERIVED     | ip2location  | NULL       | range  | idx_ip_to     | idx_ip_to | 5       | NULL | 66380 |   100.00 | Using index condition |
+----+-------------+--------------+------------+--------+---------------+-----------+---------+------+-------+----------+-----------------------+

Sử dụng truy vấn con, chúng ta có thể tối ưu hóa truy vấn bằng cách sử dụng bảng dẫn xuất tập trung vào một chỉ mục. Truy vấn sẽ chỉ trả về 1 bản ghi trong đó giá trị ip_to lớn hơn hoặc bằng giá trị địa chỉ IP. Điều này cho phép các hàng tiềm năng (đã lọc) đạt 100% là hàng hiệu quả nhất. Sau đó, kiểm tra xem ip_from có ​​nhỏ hơn hoặc bằng giá trị địa chỉ IP hay không. Nếu đúng, thì chúng ta nên tìm bản ghi. Nếu không, địa chỉ IP không tồn tại trong bảng ip2location.

Trong phép đo của chúng tôi, hiệu suất truy vấn được cải thiện khoảng 99% bằng cách sử dụng truy vấn con:

• Thời gian trung bình (InnoDB + quét phạm vi): 22,87112 ms
• Thời gian trung bình (InnoDB + truy vấn con): 0,14744 mili giây
• Cải thiện: 99.355344207017%

Với sự tối ưu hóa ở trên, chúng ta có thể thấy thời gian thực thi truy vấn dưới mili giây của loại truy vấn này, đây là một cải tiến lớn khi xem xét thời gian trung bình trước đó là 22 mili giây. Tuy nhiên, chúng tôi cần thực hiện một số sửa đổi đối với cấp cao hơn (ứng dụng / bộ cân bằng tải) để hưởng lợi từ truy vấn đã điều chỉnh này.

Vá hoặc Viết lại Truy vấn

Vá các ứng dụng của bạn để sử dụng truy vấn đã điều chỉnh hoặc viết lại truy vấn ngoại lệ trước khi nó đến máy chủ cơ sở dữ liệu. Chúng ta có thể đạt được điều này bằng cách sử dụng trình cân bằng tải MySQL như ProxySQL (quy tắc truy vấn) hoặc MariaDB MaxScale (bộ lọc viết lại câu lệnh) hoặc sử dụng plugin MySQL Query Rewriter. Trong ví dụ sau, chúng tôi sử dụng ProxySQL trước cụm cơ sở dữ liệu của mình và chúng tôi có thể chỉ cần tạo một quy tắc để viết lại truy vấn chậm hơn thành truy vấn nhanh hơn, ví dụ:

Lưu quy tắc truy vấn và theo dõi trang Ngoại trừ truy vấn trong ClusterControl. Bản sửa lỗi này rõ ràng sẽ xóa các truy vấn ngoại lệ khỏi danh sách sau khi quy tắc truy vấn được kích hoạt.

Kết luận

Truy vấn ngoại lệ là một công cụ giám sát truy vấn chủ động có thể giúp chúng tôi hiểu và khắc phục sự cố hiệu suất trước khi nó vượt quá tầm kiểm soát. Khi ứng dụng của bạn phát triển và trở nên khắt khe hơn, công cụ này có thể giúp bạn duy trì hiệu suất cơ sở dữ liệu tốt trong suốt quá trình.