Hiệu suất truy vấn kém là vấn đề phổ biến nhất mà DBA phải giải quyết. Có nhiều cách để thu thập, xử lý và phân tích dữ liệu liên quan đến hiệu suất truy vấn - chúng tôi đã đề cập đến một trong những công cụ phổ biến nhất, pt-query-dig, trong một số bài đăng trên blog trước đây của chúng tôi:
Trở thành một chuỗi blog MySQL DBA
- Phân tích Khối lượng Công việc SQL của bạn bằng cách sử dụng pt-truy vấn-thông báo
- Phân tích khối lượng công việc SQL sâu bằng cách sử dụng pt-truy vấn-thông báo
Tuy nhiên, khi bạn sử dụng ClusterControl, điều này không phải lúc nào cũng cần thiết. Bạn có thể sử dụng dữ liệu có sẵn trong ClusterControl để giải quyết vấn đề của mình. Trong bài đăng blog này, chúng tôi sẽ xem xét cách ClusterControl có thể giúp bạn giải quyết các vấn đề liên quan đến hiệu suất truy vấn.
Có thể xảy ra trường hợp không thể hoàn thành truy vấn kịp thời. Truy vấn có thể bị kẹt do một số vấn đề về khóa, nó có thể không tối ưu hoặc không được lập chỉ mục đúng cách hoặc có thể quá nặng để hoàn thành trong một khoảng thời gian hợp lý. Hãy nhớ rằng một vài liên kết không được lập chỉ mục có thể dễ dàng quét hàng tỷ hàng nếu bạn có một cơ sở dữ liệu sản xuất lớn. Dù điều gì đã xảy ra, truy vấn có thể đang sử dụng một số tài nguyên - có thể là CPU hoặc I / O cho một truy vấn không được tối ưu hóa hoặc thậm chí chỉ là khóa hàng. Những tài nguyên đó cũng được yêu cầu cho các truy vấn khác và nó có thể làm chậm mọi thứ một cách nghiêm trọng. Một trong những nhiệm vụ rất đơn giản nhưng quan trọng là xác định truy vấn vi phạm và dừng nó lại.
Nó được thực hiện khá dễ dàng từ giao diện ClusterControl. Chuyển đến tab Giám sát Truy vấn -> Phần Truy vấn Đang chạy - bạn sẽ thấy một kết quả tương tự như ảnh chụp màn hình bên dưới.
Như bạn có thể thấy, chúng tôi có một đống truy vấn bị mắc kẹt. Thông thường truy vấn vi phạm là truy vấn mất nhiều thời gian, bạn có thể muốn loại bỏ nó. Bạn cũng có thể muốn điều tra thêm để đảm bảo rằng bạn chọn đúng. Trong trường hợp của chúng tôi, chúng tôi thấy rõ ràng là CHỌN… CHO CẬP NHẬT tham gia một vài bảng và ở trạng thái "Đang gửi dữ liệu" có nghĩa là nó đang xử lý dữ liệu, trong 90 giây qua.
Một loại câu hỏi khác mà DBA có thể cần trả lời là - truy vấn nào mất nhiều thời gian nhất để thực thi? Đây là một câu hỏi phổ biến, vì các truy vấn như vậy có thể là một kết quả thấp - chúng có thể được tối ưu hóa và càng có nhiều thời gian thực thi mà một truy vấn nhất định chịu trách nhiệm trong toàn bộ hỗn hợp truy vấn, thì lợi ích từ việc tối ưu hóa của nó càng lớn. Đó là một phương trình đơn giản - nếu một truy vấn chiếm 50% tổng thời gian thực thi, thì việc làm cho nó nhanh hơn 10 lần sẽ cho kết quả tốt hơn nhiều so với việc tối ưu hóa một truy vấn chỉ chiếm 1% tổng thời gian thực thi.
ClusterControl có thể giúp bạn trả lời những câu hỏi như vậy, nhưng trước tiên chúng ta cần đảm bảo rằng Query Monitor đã được bật. Bạn có thể chuyển Trình theo dõi truy vấn thành BẬT trong trang Giám sát truy vấn. Hơn nữa, bạn có thể định cấu hình tùy chọn "Thời gian truy vấn dài" và "Truy vấn nhật ký không sử dụng chỉ mục" trong Cài đặt cho phù hợp với khối lượng công việc của bạn:
Trình giám sát truy vấn trong ClusterControl hoạt động ở hai chế độ, tùy thuộc vào việc bạn có sẵn Sơ đồ hiệu suất với dữ liệu cần thiết về các truy vấn đang chạy hay không. Nếu nó có sẵn (và điều này đúng theo mặc định trong MySQL 5.6 và mới hơn), Performance Schema sẽ được sử dụng để thu thập dữ liệu truy vấn, giảm thiểu tác động đến hệ thống. Nếu không, nhật ký truy vấn chậm sẽ được sử dụng và tất cả các cài đặt hiển thị trong ảnh chụp màn hình ở trên đều được sử dụng. Những điều đó đã được giải thích khá kỹ trong giao diện người dùng, vì vậy không cần phải làm điều đó ở đây. Khi Màn hình truy vấn sử dụng Giản đồ hiệu suất, những cài đặt đó sẽ không được sử dụng (ngoại trừ việc bật / tắt Màn hình truy vấn để bật / tắt thu thập dữ liệu).
Khi bạn xác nhận rằng Trình theo dõi truy vấn được bật trong ClusterControl, bạn có thể đi tới Trình theo dõi truy vấn -> Truy vấn hàng đầu, tại đây bạn sẽ được hiển thị với một màn hình tương tự như bên dưới:
Những gì bạn có thể thấy ở đây là danh sách các truy vấn đắt nhất (về thời gian thực hiện) đã truy cập vào cụm của chúng tôi. Mỗi người trong số họ có một số chi tiết khác - bao nhiêu lần nó được thực thi, bao nhiêu hàng đã được kiểm tra hoặc gửi đến máy khách, thời gian thực thi khác nhau như thế nào, cụm dành bao nhiêu thời gian để thực hiện một loại truy vấn nhất định. Các truy vấn được nhóm theo loại truy vấn và giản đồ.
Bạn có thể ngạc nhiên khi phát hiện ra rằng nơi chính dành thời gian thực thi là truy vấn ‘COMMIT’. Trên thực tế, điều này khá điển hình cho các truy vấn OLTP nhanh được thực thi trên cụm Galera. Cam kết một giao dịch là một quá trình tốn kém vì chứng nhận phải xảy ra. Điều này dẫn đến COMMIT là một trong những truy vấn tốn thời gian nhất trong hỗn hợp truy vấn.
Khi nhấp vào một truy vấn, bạn có thể thấy toàn bộ truy vấn, thời gian thực thi tối đa, số lần xuất hiện, một số gợi ý tối ưu hóa chung và kết quả GIẢI THÍCH cho truy vấn - khá hữu ích để xác định xem có vấn đề gì xảy ra với nó hay không. Trong ví dụ của chúng tôi, chúng tôi đã kiểm tra một CHỌN… CHO CẬP NHẬT với số lượng hàng được kiểm tra cao. Như mong đợi, truy vấn này là một ví dụ về SQL khủng khiếp - một JOIN không sử dụng bất kỳ chỉ mục nào. Bạn có thể thấy trên đầu ra EXPLAIN rằng không có chỉ mục nào được sử dụng, thậm chí không có một chỉ mục nào được coi là có thể sử dụng. Không có gì ngạc nhiên khi truy vấn này ảnh hưởng nghiêm trọng đến hiệu suất của cụm của chúng tôi.
Một cách khác để hiểu rõ hơn về hiệu suất truy vấn là xem Query Monitor -> Query Outceptions. Về cơ bản, đây là danh sách các truy vấn có hiệu suất khác biệt đáng kể so với mức trung bình của chúng.
Như bạn có thể thấy trong ảnh chụp màn hình ở trên, truy vấn thứ hai mất 0,01116 giây (thời gian được hiển thị bằng mili giây) trong đó thời gian thực thi trung bình cho truy vấn đó thấp hơn nhiều (0,000142 giây). Chúng tôi cũng có một số thông tin thống kê bổ sung về độ lệch chuẩn và thời gian thực hiện truy vấn tối đa. Danh sách các truy vấn như vậy có vẻ không hữu ích lắm - điều đó không thực sự đúng. Khi bạn nhìn thấy một truy vấn trong danh sách này, điều đó có nghĩa là có điều gì đó khác với thông thường - truy vấn không hoàn thành trong thời gian bình thường. Đó có thể là dấu hiệu của một số vấn đề về hiệu suất trên hệ thống của bạn và là tín hiệu cho thấy bạn nên điều tra các chỉ số khác và kiểm tra xem có điều gì khác xảy ra vào thời điểm đó không.
Mọi người có xu hướng tập trung vào việc đạt được hiệu suất tối đa mà quên rằng chỉ cần có thông lượng cao là chưa đủ - nó còn phải nhất quán. Người dùng thích hiệu suất ổn định - bạn có thể thu được nhiều giao dịch hơn mỗi giây từ hệ thống của mình nhưng nếu điều đó có nghĩa là một số giao dịch sẽ bắt đầu bị đình trệ trong vài giây, điều đó không đáng. Nhìn vào Biểu đồ truy vấn trong ClusterControl giúp bạn xác định các vấn đề nhất quán như vậy trong hỗn hợp truy vấn của bạn.
Chúc bạn theo dõi truy vấn vui vẻ!
Tái bút:Để bắt đầu với ClusterControl, hãy nhấp vào đây!
