Các phương pháp hay nhất về tối ưu hóa cơ sở dữ liệu MySQL

Question

Các phương pháp hay nhất để tối ưu hóa cài đặt MySQL cho hiệu năng tốt nhất khi xử lý các bảng lớn hơn một chút (> 50k bản ghi với tổng số khoảng 100MB mỗi bảng)? Chúng tôi hiện đang tìm kiếm vào viết lại DelphiFeeds.com (một trang tin tức cho cộng đồng lập trình Delphi) và nhận thấy rằng các câu lệnh Update đơn giản có thể mất đến 50ms. Điều này có vẻ như rất nhiều. Có bất kỳ cài đặt cấu hình được đề xuất nào mà chúng tôi nên bật/đặt thường bị vô hiệu hóa khi cài đặt MySQL chuẩn (ví dụ: để tận dụng nhiều RAM hơn cho truy vấn bộ nhớ cache và dữ liệu, v.v ...) không?

Ngoài ra, sự lựa chọn công cụ lưu trữ có những tác động hiệu quả nào? Chúng tôi đang có kế hoạch đi với InnoDB, nhưng nếu MyISAM được khuyến khích vì lý do hiệu suất, chúng tôi có thể sử dụng MyISAM.

Answer 1

Các "thực hành tốt nhất" là:

1. Đo lường hiệu suất, cô lập các hệ thống phụ liên quan cũng như bạn có thể.
2. Xác định nguyên nhân gốc rễ của nút cổ chai. Bạn I/O bị ràng buộc? CPU bị ràng buộc? Bộ nhớ bị ràng buộc? Đang đợi khóa?
3. Thực hiện các thay đổi để giảm bớt nguyên nhân gốc rễ mà bạn đã khám phá.
4. Đo lại, để chứng minh rằng bạn đã sửa nút cổ chai và theo số lượng.
5. Chuyển đến bước 2 và lặp lại khi cần thiết cho đến khi hệ thống hoạt động đủ nhanh.

Đăng ký nguồn cấp dữ liệu RSS tại http://www.mysqlperformanceblog.com và đọc các bài viết lịch sử của nó. Đó là một nguồn tài nguyên cực kỳ hữu ích cho trí tuệ liên quan đến hiệu suất. Ví dụ, bạn hỏi về InnoDB so với MyISAM. Kết luận của họ: InnoDB có hiệu suất cao hơn ~ 30% so với MyISAM. Mặc dù cũng có một vài tình huống sử dụng mà MyISAM không thể thực hiện InnoDB.

• InnoDB vs. MyISAM vs. Falcon benchmarks - part 1

Các tác giả của blog mà cũng là đồng tác giả của "High Performance MySQL," cuốn sách được đề cập bởi @ Andrew Barnett.

---

Re comment from @ ʞɔıu: Làm thế nào để biết bạn đang I/O bị ràng buộc so với CPU bị ràng buộc với bộ nhớ ràng buộc là nền tảng phụ thuộc. Hệ điều hành có thể cung cấp các công cụ như ps, iostat, vmstat hoặc top. Hoặc bạn có thể phải có công cụ của bên thứ ba nếu hệ điều hành của bạn không cung cấp.

Về cơ bản, bất kỳ tài nguyên nào được chốt ở mức sử dụng 100%/độ bão hòa có thể là nút cổ chai của bạn. Nếu tải CPU của bạn thấp nhưng tải I/O của bạn ở mức tối đa cho phần cứng của bạn, thì bạn là I/O bị ràng buộc.

Tuy nhiên, đó chỉ là một điểm dữ liệu. Biện pháp khắc phục cũng có thể phụ thuộc vào các yếu tố khác. Ví dụ, một truy vấn SQL phức tạp có thể đang làm một filesort, và điều này giữ cho I/O bận. Bạn có nên ném phần cứng nhanh hơn/nhanh hơn vào nó hay bạn nên thiết kế lại truy vấn để tránh filesort?

Có quá nhiều yếu tố để tóm tắt trong bài đăng StackOverflow và thực tế là nhiều sách tồn tại trên chủ đề hỗ trợ điều này.Giữ cho cơ sở dữ liệu hoạt động hiệu quả và tận dụng tối đa các nguồn lực là công việc toàn thời gian đòi hỏi các kỹ năng chuyên môn và nghiên cứu liên tục.

---

Jeff Atwood chỉ viết một bài viết trên blog tốt đẹp về việc tìm kiếm tắc nghẽn trong hệ thống:

• The Computer Performance Shell Game

Answer 2

Mua "Hiệu suất cao MySQL" từ O'Reilly. Đó là gần 700 trang về chủ đề này, vì vậy tôi nghi ngờ bạn sẽ tìm thấy câu trả lời ngắn gọn về SO.

Answer 3

Thật khó để broadbrush mọi thứ, nhưng một cái nhìn tương đối cao cấp có thể .

• Bạn cần đánh giá tỷ lệ đã đọc: ghi. Đối với các bảng có tỷ lệ thấp hơn khoảng 5: 1, bạn có thể sẽ được hưởng lợi từ InnoDB vì sau đó chèn sẽ không chặn các lựa chọn. Nhưng nếu bạn không sử dụng giao dịch, bạn nên thay đổi innodb_flush_log_at_trx_commit thành 1 để nhận lại hiệu suất trên MyISAM.
• Xem thông số bộ nhớ. Mặc định của MySQL rất bảo thủ và một số giới hạn bộ nhớ có thể được nâng lên bởi hệ số 10 hoặc nhiều hơn trên phần cứng thông thường. Điều này sẽ mang lại lợi ích cho các CHỌN của bạn hơn là INSERT.
• MySQL có thể ghi lại những thứ như truy vấn không sử dụng chỉ mục, cũng như các truy vấn chỉ mất quá nhiều thời gian (người dùng có thể xác định).
• Bộ nhớ cache truy vấn có thể hữu ích, nhưng bạn cần phải sử dụng nó (ví dụ: xem nó được sử dụng bao nhiêu). Xương rồng có thể làm điều đó; Munin.
• thiết kế ứng dụng cũng rất quan trọng:
  • nhẹ bộ nhớ đệm bộ dữ liệu thường xuyên lấy nhưng smallish sẽ có một sự khác biệt lớn (ví dụ: bộ nhớ cache đời của một vài giây).
  • Không tìm nạp lại dữ liệu mà bạn đã có.
  • Bộ nhớ nhiều bước có thể trợ giúp với khối lượng lớn chèn vào các bảng cũng được đọc một cách bận rộn. Ý tưởng cơ bản là bạn có thể có một bảng cho chèn ad-hoc (INSERT DELAYED cũng có thể hữu ích), nhưng một quá trình theo lô để di chuyển các bản cập nhật trong MySQL từ đó đến nơi tất cả các lần đọc đang diễn ra. Có những biến thể này.
• Đừng quên rằng phối cảnh và bối cảnh cũng quan trọng: bạn có thể nghĩ rằng một thời gian dài cho một sự kiện xảy ra một lần mỗi ngày.

Answer 4

Có rất nhiều phương pháp hay nhất đã được thảo luận trước đó nên không có lý do gì để lặp lại chúng. Để được tư vấn cụ thể về những việc cần làm, tôi sẽ thử chạy MySQL Tuner. Một kịch bản perl mà bạn có thể tải xuống và chạy trên máy chủ cơ sở dữ liệu của bạn, nó sẽ cung cấp cho bạn một số thống kê về cơ sở dữ liệu của bạn đang hoạt động như thế nào (ví dụ: truy cập bộ đệm) cùng với một số khuyến nghị cụ thể để cải thiện hiệu suất.

Mặc dù các thống kê này đều có sẵn trong chính MySQL, tôi thấy rằng công cụ này cung cấp cho chúng một cách dễ hiểu hơn nhiều. Mặc dù điều quan trọng cần lưu ý là YMMV đối với các đề xuất, tôi đã nhận thấy chúng là khá chính xác. Chỉ cần đảm bảo rằng bạn đã thực hiện tốt công việc thực hiện cơ sở dữ liệu trước với lưu lượng truy cập thực tế.