Mẹo để cung cấp hiệu suất cơ sở dữ liệu MySQL - Phần thứ hai

Quản lý hiệu suất cơ sở dữ liệu là một lĩnh vực mà các doanh nghiệp khi quản trị viên thường thấy mình đóng góp nhiều thời gian hơn họ mong đợi.

Giám sát và phản ứng với các vấn đề về hiệu suất cơ sở dữ liệu sản xuất là một trong những nhiệm vụ quan trọng nhất trong công việc quản trị cơ sở dữ liệu. Đó là một quá trình liên tục đòi hỏi sự chăm sóc liên tục. Ứng dụng và cơ sở dữ liệu cơ bản thường phát triển theo thời gian; phát triển về quy mô, số lượng người dùng, khối lượng công việc, các thay đổi lược đồ đi kèm với các thay đổi về mã.

Các truy vấn chạy dài hiếm khi không thể tránh khỏi trong cơ sở dữ liệu MySQL. Trong một số trường hợp, một truy vấn chạy dài có thể là một sự kiện có hại. Nếu bạn quan tâm đến cơ sở dữ liệu của mình, việc tối ưu hóa hiệu suất truy vấn và phát hiện các truy vấn chạy dài phải được thực hiện thường xuyên.

Trong blog này, chúng ta sẽ xem xét sâu hơn về khối lượng công việc cơ sở dữ liệu thực tế, đặc biệt là về phía các truy vấn đang chạy. Chúng tôi sẽ kiểm tra cách theo dõi các truy vấn, loại thông tin nào chúng tôi có thể tìm thấy trong siêu dữ liệu MySQL, những công cụ nào cần sử dụng để phân tích các truy vấn đó.

Xử lý các Truy vấn Chạy dài

Hãy bắt đầu với việc kiểm tra các Truy vấn chạy dài. Trước hết, chúng ta phải biết bản chất của truy vấn, cho dù nó được mong đợi là một truy vấn chạy dài hay chạy ngắn. Một số hoạt động phân tích và hàng loạt được cho là các truy vấn chạy dài, vì vậy chúng ta có thể bỏ qua chúng ngay bây giờ. Ngoài ra, tùy thuộc vào kích thước bảng, việc sửa đổi cấu trúc bảng bằng lệnh ALTER có thể là một hoạt động kéo dài (đặc biệt là trong MySQL Galera Clusters).

• Khóa bảng - Bảng bị khóa bằng khóa chung hoặc khóa bảng rõ ràng khi truy vấn đang cố gắng truy cập.
• Truy vấn không hiệu quả - Sử dụng các cột không được lập chỉ mục khi tra cứu hoặc tham gia, do đó MySQL mất nhiều thời gian hơn để phù hợp với điều kiện.
• Bế tắc - Một truy vấn đang chờ truy cập vào các hàng giống nhau bị khóa bởi một yêu cầu khác.
• Tập dữ liệu không vừa với RAM - Nếu dữ liệu tập hợp làm việc của bạn phù hợp với bộ nhớ cache đó, thì các truy vấn CHỌN thường sẽ tương đối nhanh.
• Tài nguyên phần cứng không tối ưu - Đây có thể là đĩa chậm, quá trình xây dựng lại RAID, mạng bão hòa, v.v.

Nếu bạn thấy một truy vấn mất nhiều thời gian hơn bình thường để thực thi, hãy điều tra nó.

Sử dụng MySQL Show Process List

​MYSQL> SHOW PROCESSLIST;

Đây thường là điều đầu tiên bạn chạy trong trường hợp có vấn đề về hiệu suất. SHOW PROCESSLIST là một lệnh mysql nội bộ cho bạn biết các luồng nào đang chạy. Bạn cũng có thể xem thông tin này từ bảng information_schema.PROCESSLIST hoặc lệnh danh sách quy trình mysqladmin. Nếu bạn có đặc quyền QUY TRÌNH, bạn có thể xem tất cả các chuỗi. Bạn có thể xem thông tin như Id truy vấn, thời gian thực thi, ai chạy nó, máy chủ lưu trữ khách hàng, v.v.

SHOW PROCESSLIST;

+----+-----------------+-----------+------+---------+------+------------------------+------------------+----------+

| Id | User            | Host | db | Command | Time | State                  | Info | Progress |

+----+-----------------+-----------+------+---------+------+------------------------+------------------+----------+

|  2 | event_scheduler | localhost | NULL | Daemon  | 2693 | Waiting on empty queue | NULL   | 0.000 |

|  4 | root            | localhost | NULL | Query   | 0 | Table lock   | SHOW PROCESSLIST | 0.000 |

+----+-----------------+-----------+------+---------+------+------------------------+------------------+----------+

chúng ta có thể thấy ngay truy vấn tấn công ngay từ đầu ra. Trong ví dụ trên, đó có thể là một khóa Bảng. Nhưng chúng ta thường nhìn chằm chằm vào những quá trình đó như thế nào? Điều này chỉ hữu ích nếu bạn biết về giao dịch đang diễn ra trong thời gian dài. Nếu không, bạn sẽ không biết cho đến khi có điều gì đó xảy ra - chẳng hạn như các kết nối đang chồng chất lên nhau hoặc máy chủ chạy chậm hơn bình thường.

Sử dụng MySQL Pt-truy vấn-thông báo

Nếu bạn muốn xem thêm thông tin về một khối lượng công việc cụ thể, hãy sử dụng pt-query-dig. Pt-truy vấn-thông báo là một công cụ Linux của Percona để phân tích các truy vấn MySQL. Nó là một phần của Bộ công cụ Percona mà bạn có thể tìm thấy tại đây. Nó hỗ trợ các bản phân phối Linux 64 bit phổ biến nhất như Debian, Ubuntu và Redhat.

Để cài đặt nó, bạn phải định cấu hình kho lưu trữ Percona và sau đó cài đặt gói perona-toolkit.

Cài đặt Bộ công cụ Percona bằng trình quản lý gói của bạn:

Debian hoặc Ubuntu:

sudo apt-get install percona-toolkit

RHEL hoặc CentOS:

sudo yum install percona-toolkit

Pt-truy vấn-tiêu hóa chấp nhận dữ liệu từ danh sách quy trình, nhật ký chung, nhật ký nhị phân, nhật ký chậm hoặc tcpdump Ngoài ra, có thể thăm dò danh sách quy trình MySQL tại một khoảng thời gian xác định - một quy trình có thể sử dụng nhiều tài nguyên và không còn lý tưởng, nhưng vẫn có thể được sử dụng như một giải pháp thay thế.

Nguồn phổ biến nhất cho pt-query-digan là một bản ghi truy vấn chậm. Bạn có thể kiểm soát lượng dữ liệu sẽ đến đó với tham số log_slow_verbosity.

Có một số điều có thể khiến truy vấn mất nhiều thời gian hơn để thực thi:

• microtime - các truy vấn có độ chính xác đến micro giây.
• query_plan - thông tin về kế hoạch thực thi của truy vấn.
• innodb - Số liệu thống kê của InnoDB.
• tối thiểu - Tương đương với chỉ bật microtime.
• standard - Tương đương với việc bật microtime, innodb.
• full - Tương đương với tất cả các giá trị khác HOẶC được kết hợp với nhau mà không có tùy chọn cấu hình và profiling_use_getrusage.
• profiling - Cho phép lập hồ sơ cho tất cả các truy vấn trong tất cả các kết nối.
• profiling_use_getrusage - Cho phép sử dụng hàm getrusage.

nguồn:Tài liệu Percona

Để có tính đầy đủ, hãy sử dụng log_slow_verbosity =full, đây là trường hợp phổ biến.

Nhật ký Truy vấn Chậm

Nhật ký truy vấn chậm 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. Nhật ký truy vấn chậm ghi lại các truy vấn chậm (câu lệnh SQL mất hơn long_query_time giây để thực thi) hoặc các truy vấn không sử dụng chỉ mục để tra cứu (log_queries_not_using_indexes). Tính năng này không được bật theo mặc định và để bật nó chỉ cần đặt các dòng sau và khởi động lại máy chủ MySQL:

[mysqld]
slow_query_log=1
log_queries_not_using_indexes=1
long_query_time=0.1

Nhật ký truy vấn chậm 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. Tuy nhiên, việc kiểm tra nhật ký truy vấn chậm dài có thể là một công việc tốn nhiều thời gian. Có các công cụ để phân tích cú pháp tệp nhật ký truy vấn chậm của MySQL và tóm tắt nội dung của chúng như mysqldumpslow, pt-query-dig.

Giản đồ Hiệu suất

Performance Schema là một công cụ tuyệt vời có sẵn để theo dõi nội bộ MySQL Server và chi tiết thực thi ở cấp độ thấp hơn. Nó đã có tiếng xấu trong phiên bản đầu tiên (5.6) vì việc kích hoạt nó thường gây ra các vấn đề về hiệu suất, tuy nhiên các phiên bản gần đây không gây hại cho hiệu suất. Các bảng sau trong Lược đồ hiệu suất có thể được sử dụng để tìm các truy vấn chậm:

• event_statements_current
• event_statements_history
• event_statements_history_long
• event_statements_summary_by_digest
• event_statements_summary_by_user_by_event_name
• event_statements_summary_by_host_by_event_name

MySQL 5.7.7 trở lên bao gồm lược đồ sys, một tập hợp các đối tượng giúp DBA và các nhà phát triển giải thích dữ liệu được Thu thập bởi Lược đồ Hiệu suất thành một dạng dễ hiểu hơn. Các đối tượng lược đồ Sys có thể được sử dụng cho các trường hợp sử dụng điều chỉnh và chẩn đoán điển hình.

Theo dõi mạng

Điều gì sẽ xảy ra nếu chúng tôi không có quyền truy cập vào nhật ký truy vấn hoặc nhật ký ứng dụng trực tiếp. Trong trường hợp đó, chúng tôi có thể sử dụng kết hợp tcpdump và thông báo truy vấn pt có thể giúp nắm bắt các truy vấn.

$ tcpdump -s 65535 -x -nn -q -tttt -i any port 3306 > mysql.tcp.txt

Sau khi quá trình thu thập kết thúc, chúng tôi có thể tiếp tục xử lý dữ liệu:

$ pt-query-digest --limit=100% --type tcpdump mysql.tcp.txt > ptqd_tcp.out

ClusterControl Query Monitor

ClusterControl Query Monitor là một mô-đun trong điều khiển cụm cung cấp thông tin kết hợp về hoạt động của cơ sở dữ liệu. Nó có thể thu thập thông tin từ nhiều nguồn như hiển thị danh sách quy trình hoặc nhật ký truy vấn chậm và trình bày nó theo cách tổng hợp trước.

Giám sát SQL được chia thành ba phần.

Truy vấn hàng đầu

trình bày thông tin về các truy vấn chiếm một lượng lớn tài nguyên.

Đang chạy Truy vấn

đó là danh sách thông tin quy trình được kết hợp từ tất cả các nút của cụm cơ sở dữ liệu vào một chế độ xem. Bạn có thể sử dụng nó để loại bỏ các truy vấn ảnh hưởng đến hoạt động cơ sở dữ liệu của bạn.

Truy vấn Ngoại lệ

trình bày danh sách các truy vấn có thời gian thực thi lâu hơn mức trung bình.

Kết luận

Đây là tất cả cho phần hai. Blog này không nhằm mục đích là một hướng dẫn đầy đủ về cách nâng cao hiệu suất cơ sở dữ liệu, nhưng hy vọng nó cung cấp một bức tranh rõ ràng hơn về những thứ có thể trở nên thiết yếu và một số thông số cơ bản có thể được định cấu hình. Đừng ngần ngại cho chúng tôi biết nếu chúng tôi bỏ lỡ bất kỳ điều quan trọng nào trong phần nhận xét bên dưới.