Tin xấu:có những công cụ GUI để trợ giúp việc này, nhưng nó là một công việc có kỹ năng và phạm vi rộng. Vì vậy, chúng không bao gồm tất cả mọi thứ, có khả năng bạn sẽ cần sử dụng nội dung dòng lệnh / câu lệnh sql, v.v. để trợ giúp. Tôi chỉ thực sự sử dụng các công cụ dòng lệnh. Tôi sẽ cung cấp một chút tổng quan về những thứ tôi biết / đã sử dụng:
Đầu tiên, bạn cần một thiết kế cơ sở dữ liệu tốt. Nếu thiết kế xấu, bạn chỉ có thể nhận được cho đến nay. Điều này bao gồm việc chuẩn hóa, cũng như sử dụng các kiểu thích hợp cho các trường. Tôi sẽ để lại vấn đề này ở đây, vì tôi nghĩ nó hơi sang một bên, và không phải là điều bạn đang theo đuổi.
Đảm bảo MySQL Query Cache được thiết lập và hoạt động, đồng thời cung cấp cho nó nhiều RAM hơn nếu bạn có thể và đảm bảo rằng các truy vấn quan trọng của bạn không làm bất cứ điều gì ngăn cản mysql lưu vào bộ nhớ đệm của chúng. Ví dụ:sử dụng hàm NOW () trong các truy vấn thực hiện điều này - vì những lý do rõ ràng - NOW thay đổi mỗi giây! Thay vào đó, bạn có thể đặt dấu thời gian vào sql và sử dụng thời gian chính xác đến phút / giờ / ngày (khoảng thời gian lớn nhất mà bạn có thể có được) để cho phép mysql nhận được một số lợi ích từ bộ nhớ đệm.
Để bắt đầu tối ưu hóa mọi thứ:Gắn "GIẢI THÍCH" trước lựa chọn là CÁCH để xem cách truy vấn đang được thực thi và lý tưởng cách cải thiện nó. Tìm hiểu cách diễn giải kết quả đầu ra: http://dev.mysql .com / doc / refman / 5.0 / vi / using-giải thích.html Thông thường, bạn sẽ có thể thêm chỉ mục mới / thêm cột vào những chỉ mục hiện có để cải thiện mọi thứ. Nhưng bạn cũng sẽ gặp phải những thời điểm mà các truy vấn cần được cấu trúc lại.
Bắt đầu cải thiện hiệu suất với MySQL (giả sử bạn chưa biết truy vấn vấn đề là gì) là kiểm tra nhật ký truy vấn chậm - nó ghi vào tệp tất cả các truy vấn mất hơn x giây.
Tổng quan, bao gồm cả cấu hình nếu nó chưa ghi nhật ký điều này, ở đây: http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html - Tôi cũng nhận thấy rằng việc đặt long_query_time thành 0 trong một ngày hoặc lâu hơn, để tất cả các truy vấn được ghi vào đây với thời gian thực hiện, là một cách hữu ích để biết chính xác hiệu suất đang diễn ra. Nhưng tôi sẽ không đến đó ngay lập tức! Và đừng để nguyên, nhật ký có thể trở nên lớn.
Khi bạn đã ghi nhật ký được vài ngày, tôi đã tìm thấy mysqlsla (trình phân tích nhật ký chậm mysql) từ đây: http://hackmysql.com/mysqlsla là một công cụ tốt.
Nó có thể làm được nhiều việc hơn là chỉ phân tích nhật ký truy vấn chậm - hãy đọc hướng dẫn sử dụng. Nhưng để giải thích tác dụng của nó đối với nhật ký chậm:nhật ký truy vấn chậm có thể chứa rất nhiều dữ liệu, vì vậy có thể khó tìm ra truy vấn nào là đắt nhất về tổng thể - ví dụ:yếu tố số lần chúng chạy và thời điểm hai truy vấn thực sự giống nhau với một id khác trong mệnh đề where.
MySQL nô lệ làm tất cả điều này cho bạn. Nó chạy qua nhật ký và có thể nhóm các truy vấn giống nhau / có giá trị khác nhau trong mệnh đề where. Sau đó, nó hiển thị cho bạn (theo mặc định) 10 truy vấn hàng đầu về tổng thời gian thực thi - điều này thường có một số bất ngờ, nhưng thường là điểm khởi đầu hiệu quả nhất - hãy lấy truy vấn đắt nhất và sử dụng GIẢI THÍCH về nó và xem liệu bạn có thể cải thiện không nó.
Một số truy vấn mất nhiều thời gian và không thể dễ dàng cải thiện được. Trong trường hợp này, bạn có thể lấy dữ liệu theo cách khác hoặc ít nhất là lưu vào bộ nhớ cache để thay thế? Bạn thậm chí có thể thấy rằng việc thay đổi lược đồ DB là bắt buộc. Tương tự, một số truy vấn có thể ở trên cùng của đầu ra mysqlsla vì bạn chạy chúng rất nhiều (đặc biệt đúng nếu long_query_time được đặt thành 0), ngay cả khi chúng chạy khá nhanh. Có lẽ đã đến lúc thêm một số bộ nhớ đệm vào ứng dụng của bạn?
http://www.maatkit.org/ cũng có vẻ hứa hẹn - chưa bao giờ được sử dụng, nhưng công cụ mk-query-profiler sẽ hữu ích để xem xét thêm lý do tại sao các truy vấn chậm.
Một thứ hoàn toàn riêng biệt cũng cần xem xét:trang "trạng thái" trong PHPMYADMIN (hoặc bạn có thể chạy tất cả các truy vấn để tạo ra thông tin này ....) - nó làm nổi bật những thứ mà nó cho là không tốt bằng màu đỏ và có thể giúp bạn xem nơi bạn có thể nhận được lợi ích từ việc phân bổ tài nguyên hệ thống. Tôi không biết nhiều về điều này - cách tiếp cận của tôi luôn là nếu cái gì đó có màu đỏ và trông xấu, hãy đi đọc lại nó và quyết định xem nó có quan trọng hay không và liệu tôi có nên làm gì đó không (thường có nghĩa là phân bổ nhiều tài nguyên hơn cho MySQL bằng cách thay đổi cấu hình).
Gần đây, tôi nhận thấy rằng việc chạy DANH SÁCH TRÌNH BÀY cũng có thể hữu ích trên một máy chủ đang gặp sự cố. Mặc dù nó chỉ cung cấp cho bạn thông tin trực tiếp (tốt, ảnh chụp nhanh trực tiếp), nó có thể giúp bạn cảm nhận những gì đang diễn ra tại một thời điểm nhất định, đặc biệt nếu bạn làm mới một vài lần và quan sát các thay đổi. Gần đây tôi đã phát hiện một máy chủ sử dụng mọi kết nối mysql có sẵn để chạy một truy vấn giống hệt nhau bằng phương pháp này. Chắc chắn, nó đã ở trong nhật ký truy vấn chậm, nhưng đây là một cách thực sự nhanh chóng và rõ ràng để xem những gì đã xảy ra.
