Các chuyên gia biết cách viết các truy vấn hiệu quả về hiệu suất. Mặc dù kinh nghiệm làm chín sự khôn ngoan, nhưng có những điều nhất định mà người ta phải hiểu ít nhất để bắt đầu. Ví dụ, bạn phải hiểu những cân nhắc chính của thiết kế truy vấn; cách truy vấn hoạt động nội bộ, vị trí lỗi, các mẫu tối ưu hóa, v.v. Trong bài viết này, tôi sẽ cung cấp một số điểm tối ưu hóa để bạn cân nhắc khi thiết kế truy vấn trong MySQL.
Tại sao một số truy vấn lại chậm?
Một vấn đề phổ biến với các truy vấn SQL là nhiều dữ liệu đang được truy xuất hơn mức thực tế cần thiết. Tất nhiên, có những truy vấn sàng lọc qua rất nhiều dữ liệu và chúng ta không thể làm gì nhiều về chúng, nhưng chúng không phổ biến. Trong hầu hết các trường hợp, thiết kế truy vấn không tốt dẫn đến hiệu suất truy vấn kém. Sau mỗi thiết kế truy vấn, bạn phải xem xét nội dung về một số khía cạnh như những gì có thể xảy ra sau khi truy vấn được kích hoạt:
- Truy vấn SQL có truy cập quá nhiều cột hoặc hàng không?
- Máy chủ MySQL có phân tích quá nhiều hàng để thu được kết quả mong muốn không?
Có những truy vấn khiến máy chủ MySQL phân tích trên quá nhiều dữ liệu nhưng lại ném chúng khi nó sàng lọc. Đây là một công việc bổ sung cho máy chủ về nhiều khía cạnh như chi phí mạng, tiêu thụ quá nhiều bộ nhớ hoặc sử dụng quá nhiều tài nguyên CPU trên máy chủ. Hậu quả là hiệu suất chậm.
Có những tình huống mà bạn có thể không giúp được nhiều trong quá trình thiết kế nó, nhưng có một tình huống mà nếu bạn cẩn thận và ước tính hậu quả và xem xét nội tâm, thì một truy vấn tồi ít nhất cũng có thể trở nên tốt nếu không muốn nói là tốt hơn.
Sai lầm điển hình và giải pháp của chúng
Có một số lỗi phổ biến thường mắc phải khi viết truy vấn. Dưới đây là một vài trong số họ. Bạn có thể tìm thấy một vài suy nghĩ khác trên cùng một dòng. Dưới đây là các lý do khiến hiệu suất truy vấn chậm với các giải pháp khả thi.
Quá nhiều hàng
Sai lầm thường mắc phải khi viết một truy vấn truy xuất dữ liệu và cho rằng MySQL sẽ cung cấp kết quả theo yêu cầu trong khi bỏ qua số lượng xử lý cần thiết để trả về tập hợp kết quả đầy đủ. Giả sử, một câu lệnh SELECT được kích hoạt để tìm nạp 100 thông tin chi tiết về sản phẩm cho một trang web thương mại điện tử khi chỉ 10 sản phẩm trong số đó thực sự cần được hiển thị đầu tiên. Bạn có thể nghĩ rằng MySQL chỉ tìm nạp 10 hàng và ngừng thực thi truy vấn. Nhưng không. Những gì MySQL làm là tạo tập kết quả hoàn chỉnh và cung cấp cho máy khách. Thư viện máy khách nhận được bộ hoàn chỉnh và loại bỏ hầu hết và chỉ giữ lại 10 bộ mà nó tìm kiếm. Điều này rõ ràng gây lãng phí rất nhiều tài nguyên.
Tuy nhiên, trong tình huống như vậy, bạn có thể đưa ra giải pháp bằng cách sử dụng mệnh đề LIMIT với truy vấn.
SELECT col1, col2,... FROM table_name LIMIT [offset,] count;
Mệnh đề LIMIT chấp nhận một hoặc hai tham số. Cái đầu tiên chỉ định độ lệch và cái thứ hai chỉ định số lượng. Nếu chỉ một tham số được chỉ định, nó biểu thị số hàng từ đầu tập kết quả.
Ví dụ:để chọn 10 hàng từ bảng, bạn có thể viết:
SELECT e.emp_name, e.phone, e.email FROM employee e LIMIT 10;
Và để chọn 10 hàng tiếp theo, bắt đầu từ bản ghi 11, bạn có thể viết:
SELECT e.emp_name, e.phone, e.email FROM employee e LIMIT 10, 10;
Quá nhiều cột
Luôn nhìn vào truy vấn:SELECT * với sự nghi ngờ. Truy vấn này trả về tất cả các cột và bạn có thể chỉ cần một số cột trong số đó. Nhược điểm lớn nhất của việc truy xuất tất cả các cột là nó ngăn cản việc tối ưu hóa bằng cách cản trở việc sử dụng các chỉ mục, đòi hỏi quá nhiều I / O, bộ nhớ và tài nguyên CPU từ máy chủ.
Hiểu rằng một truy vấn phổ quát như vậy truy xuất tất cả các cột có thể lãng phí. Một số người nói rằng chúng hữu ích vì nó cho phép nhà phát triển sử dụng cùng một đoạn mã ở nhiều nơi. Điều đó tốt nếu chi phí liên quan được giới hạn trong thời gian cân nhắc. Đôi khi dữ liệu đã truy xuất vào bộ nhớ đệm sẽ giúp ích trong ngữ cảnh này. Tuy nhiên, hãy thận trọng, tận dụng hiệu suất là một công việc hấp dẫn và sự xa xỉ như vậy có thể không có chỗ cho hiệu suất.
Quy tắc chung là tránh những truy vấn phổ biến như vậy hoặc giữ một số cột được tìm nạp ở mức tối thiểu nhất có thể.
Phân tích quá nhiều dữ liệu
Các truy vấn trả về kết quả mong muốn là tốt nhưng đôi khi những truy vấn này được viết theo cách mà trong khi xử lý, nó yêu cầu kiểm tra quá nhiều dữ liệu trước khi tạo ra kết quả. Do đó, trong MySQL, bạn phải đo lường theo các số liệu chi phí sau:
- Thời gian thực hiện
- Các hàng được kiểm tra
- Các cột được kiểm tra
Bạn có thể ước tính sơ bộ chi phí truy vấn từ các ma trận này. Những điều này phản ánh số lượng truy cập dữ liệu của MySQL nội bộ để xử lý truy vấn và tốc độ chạy của truy vấn. Vì các ma trận của luận văn được ghi vào nhật ký truy vấn chậm, nên điều tra và tìm các truy vấn phân tích quá nhiều dữ liệu để trả về kết quả là một ý kiến hay. Cơ sở dữ liệu MySQL đăng ký tất cả các truy vấn vượt quá một lượng thời gian thực thi nhất định trong nhật ký truy vấn chậm. Đây là nơi lý tưởng để tìm kiếm các truy vấn chậm và tìm hiểu tần suất chúng chạy chậm.
Nhật ký truy vấn chậm thường được đặt tại /var/log/mysql/mysql-slow.log
Lưu ý rằng, người ta có thể phải đặt và bật ghi nhật ký các truy vấn chậm trong mysqld.cnf tệp cấu hình như sau.
#slow_query_log = 1 #slow_query_log_file = /var/log/mysql/mysql-slow.log #long_query_time = 2
Trước và với MySQL 5, có những hạn chế nghiêm trọng, đặc biệt là thiếu hỗ trợ cho việc ghi nhật ký chi tiết. Chỉ thời gian nghỉ ngơi là sử dụng các bản vá cho phép ghi nhật ký. Tuy nhiên, tính năng này đã là một phần của máy chủ MySQL 5.1 trở lên như một phần của tính năng cốt lõi của nó.
Các truy vấn mất quá nhiều thời gian trong quá trình thực thi không nhất thiết có nghĩa là chúng là các truy vấn tồi. Nhật ký truy vấn chậm chỉ cung cấp cơ hội để kiểm tra hiệu suất truy vấn và cải thiện nó nhất có thể.
Truy vấn tái cấu trúc
Khi bạn có cơ hội tái cấu trúc các truy vấn có vấn đề, mục tiêu chính của bạn nên là tìm một giải pháp thay thế để đạt được hiệu quả mà chúng tôi mong muốn. Bạn có thể chuyển đổi truy vấn thành dạng tương đương với lưu ý đến hiệu ứng nội bộ trong máy chủ MySQL trong khi xử lý.
Một quyết định trong thiết kế truy vấn là liệu chúng ta có nên ưu tiên một truy vấn phức tạp thay cho một số truy vấn đơn giản hay ngược lại. Cách tiếp cận thông thường của thiết kế cơ sở dữ liệu là thực hiện càng nhiều công việc càng tốt với ít truy vấn hơn. Lý do là một truy vấn lớn / phức tạp sẽ hiệu quả hơn về mặt chi phí trong việc thiết lập kết nối cơ sở dữ liệu. Ưu điểm của việc giảm chi phí có lợi cho truy vấn phức tạp là sử dụng mạng, xử lý / tối ưu hóa truy vấn và sử dụng tài nguyên. Nhưng cách tiếp cận truyền thống này không phù hợp với MySQL. MySQL được thiết kế để xử lý kết nối và ngắt kết nối cơ sở dữ liệu một cách nhanh chóng. Do đó, việc thiết lập kết nối, kích hoạt nhiều truy vấn đơn giản hơn và đóng kết nối có vẻ hiệu quả hơn. Truy xuất dữ liệu thông qua nhiều hơn một truy vấn đơn giản thay cho một truy vấn phức tạp lớn sẽ hiệu quả hơn. Lưu ý rằng ý tưởng tương tự có thể không được áp dụng với các cơ sở dữ liệu khác.
Kết luận
Đây là một vài mẹo nhanh để tối ưu hóa truy vấn. Hiểu rằng, biết các cú pháp SQL, có thể tạo một truy vấn lấy kết quả mong muốn là không đủ nếu người ta nhắm đến hiệu suất truy vấn. Hiểu được những gì đang xảy ra bên dưới các truy vấn trông có vẻ đơn giản là rất quan trọng trong việc viết một truy vấn không chỉ truy xuất những gì mong muốn mà còn thấm nhuần nghệ thuật tối ưu hóa ngay từ nơi tất cả bắt đầu. Hậu trường xảy ra của quá trình xử lý truy vấn cung cấp manh mối quan trọng để hiểu hiệu suất truy vấn và kiến thức này là điều bắt buộc trước khi một người bước vào lĩnh vực tối ưu hóa truy vấn.
