Làm cách nào để kiểm tra hiệu suất của truy vấn SQL trong MySQL Workbench?
Báo cáo hiệu suất là một trong những tính năng tốt nhất được cung cấp bởi MySQL Workbench. Nó cung cấp thông tin rất chi tiết để gỡ lỗi và xem những gì đang diễn ra trên MySQL Server. Show
Bạn có thể tìm thấy tất cả thông tin bên dưới bằng cách sử dụng Báo cáo hiệu suất, Thông tin được sao chép từ trang web MySQL, liên kết tại đây Báo cáo hoạt động I/O tệp hàng đầu. Hiển thị các tệp thực hiện nhiều IO nhất (tính bằng byte) I/O hàng đầu theo tệp theo thời gian. Hiển thị mức sử dụng IO cao nhất theo tệp và độ trễ I/O hàng đầu theo danh mục sự kiện. Hiển thị mức sử dụng Dữ liệu IO cao nhất theo danh mục sự kiện I/O hàng đầu trong thời gian theo danh mục sự kiện. Hiển thị người tiêu dùng thời gian IO cao nhất theo danh mục sự kiện Thời gian I/O hàng đầu theo Người dùng/Chủ đề. Hiển thị người tiêu dùng thời gian IO hàng đầu theo người dùng/luồng Phân tích báo cáo. Liệt kê các báo cáo với số liệu thống kê tổng hợp Báo cáo trong 5 phần trăm cao nhất theo thời gian chạy. Liệt kê 5% câu lệnh hàng đầu có thời gian chạy cao nhất (tính bằng micro giây), Sử dụng bảng tạm thời. Liệt kê tất cả các câu lệnh sử dụng bảng tạm thời -- truy cập số lượng bảng tạm thời cao nhất của đĩa, sau đó là bảng tạm thời của bộ nhớ Với sắp xếp. Liệt kê tất cả các câu lệnh chuẩn hóa đã thực hiện sắp xếp và truy cập chúng theo thứ tự ưu tiên sau -- sort_merge_passes, sort_scans, then sort_rows Quét toàn bộ bảng. Liệt kê các câu lệnh đã thực hiện quét toàn bộ bảng. Truy cập hiệu suất truy vấn và (các) mệnh đề where, và nếu không có chỉ mục nào được sử dụng thì nên thêm chỉ mục cho các bảng lớn Lỗi hoặc Cảnh báo. Liệt kê các câu lệnh có lỗi hoặc cảnh báo Tổng quan về đối tượng lược đồ (Chi phí cao). Hiển thị số lượng theo loại đối tượng cho từng lược đồ Ghi chú Điều này có thể mất nhiều thời gian để thực thi trên các phiên bản có số lượng lớn đối tượng Thống kê chỉ mục lược đồ Thống kê bảng lược đồ Thống kê bảng lược đồ (với bộ đệm InnoDB) Các bảng có quét toàn bộ bảng. Tìm các bảng đang được truy cập bằng cách quét toàn bộ bảng, sắp xếp chúng theo số hàng được quét (DESC) Chỉ mục không sử dụng. Danh sách các chỉ mục không bao giờ được sử dụng kể từ khi máy chủ khởi động hoặc kể từ khi bắt đầu thu thập dữ liệu P_S Chờ đợi theo thời gian. Liệt kê các sự kiện chờ hàng đầu theo tổng thời gian của chúng, bỏ qua thời gian chờ (điều này thường chứa các giá trị lớn) Chờ người dùng theo thời gian. Liệt kê các sự kiện chờ đợi hàng đầu theo tổng thời gian của chúng, bỏ qua thời gian chờ (điều này thường chứa các giá trị lớn) Chờ lớp theo thời gian. Liệt kê các lớp chờ hàng đầu theo tổng thời gian, bỏ qua thời gian chờ (điều này thường chứa các giá trị lớn) Chờ lớp học theo thời gian trung bình. Liệt kê các lớp chờ hàng đầu theo thời gian trung bình, bỏ qua thời gian chờ (điều này thường chứa các giá trị lớn) Thống kê bộ đệm InnoDB theo lược đồ. Tóm tắt đầu ra của INFORMATION_SCHEMA. Bảng INNODB_BUFFER_PAGE, tổng hợp nó theo lược đồ Thống kê bộ đệm InnoDB theo bảng. Tóm tắt đầu ra của INFORMATION_SCHEMA. Bảng INNODB_BUFFER_PAGE, tổng hợp nó theo lược đồ và tên bảng Trước tiên, bạn cần xác định xem nhật ký truy vấn chậm của mình 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
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 determines the path where you need to place your slow query logs. If this variable is not set, it will use the DATA_DIR of your MySQL data directory. Đi kèm với biến slow_query_log là long_query_time và min_examined_row_limit tác động đến cách thức hoạt động của tính năng 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 cần ít nhất . Nó có thể được sử dụng để tìm các truy vấn mất nhiều thời gian để thực hiện 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 lại báo cáo cho mình, điều này sẽ nói sau. rows to be examined. It can be used to find queries that take a long time to execute and are therefore candidates for optimization and then you can use external tools to bring the report for you, which will talk later. 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. Để thực hiện việc 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 giám sát trạng thái InnoDBTrong một thói quen DBA bình 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 dài 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à hàng đợi chất đống đang tăng dần do truy vấn đang chạy bị khóa. Bạn chỉ có thể đơn giản là chạy,
hoặc
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 → Hiệu suất → Trạng thái InnoDB như bên dưới, hoặc sử dụng → Trình giám sát truy vấn → Truy vấn đang chạy (sẽ thảo luận sau) để xem các quy trình đang hoạt động, giống như cách SHOW PROCESSLIST hoạt động . Phân tích truy vấn MySQLNhậ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ả 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à một OLTP, thì rất phổ biến khi truy vấn 10 giây hoặc thậm chí 5 giây là một vấn đề hoặc gây ra sự suy giảm hiệu suất cho cơ sở dữ liệu của bạn. Nhật ký truy vấn MySQL giúp bạn điều này nhưng nó 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ì, chúng hoạt động như thế nào 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 với những pt-truy vấn-tiêu hóaSử 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-query-digest. pt-query-digest cung cấp cho bạ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 góc nhìn 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ể.
Sử dụng performance_schemaNhậ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ý hoàn toàn, chẳng hạn như Google Cloud SQL hoặc Azure SQL. Mặc dù bạn có thể cần một số biến để kích hoạt các tính năng này, nhưng tính năng này rất hữu ích khi truy vấn các truy vấn được đăng nhập vào hệ thống của bạn. Bạn có thể đặt hàng nó bằng cách sử dụng câu lệnh SQL tiêu chuẩn để truy xuất một phần kết quả. Ví dụ,
Bạn có thể sử dụng bảng performance_schema. event_statements_summary_by_digest . Mặc dù có khả năng các mục trên bảng từ performance_schema sẽ bị xóa, bạn có thể quyết định lưu mục này vào một bảng cụ thể. Hãy xem bài đăng bên ngoài này từ Percona Thông báo truy vấn MySQL với Lược đồ hiệu suất. Trong trường hợp bạn 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 ), những cột này đang sử dụng . Phân tích các truy vấn chậm bằng cách sử dụng ClusterControlNế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 lệ truy vấn).
Ngoài ra, ClusterControl cũng ghi lại hiệu suất truy vấn bằng cách sử dụng biểu đồ giúp bạn có 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, Đợi đã, nó 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 cũng như thu thập số liệu thống kê theo thời gian thực từ máy chủ. Chúng tôi đã thảo luận về điều này trong các blog trước của chúng tôi, được chia thành hai phần của loạt blog. Kiểm tra phần 1 và sau đó là blog phần 2. 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ả 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 nhật ký truy vấn chậm ghi lại. Kiểm tra Tab Hiệu suất như bên dưới, những mục này cung cấp cho bạn những điều sau đây
|