Những tùy chọn cấu hình nào cho MySQL cung cấp những cải tiến tốc độ lớn nhất?

Những tùy chọn cấu hình nào cho MySQL cung cấp những cải tiến tốc độ lớn nhất?

Tôi đang tự hỏi về các cải tiến tệp cấu hình thực tế, loại bảng, thiết lập phần cứng, sao chép, v.v. Bất cứ điều gì khác ngoài cấu trúc truy vấn và cấu trúc bảng (chúng có thể dễ dàng tìm thấy trên trang web và Stack Overflow). Có phải những thứ như cài đặt bộ đệm truy vấn đã cho bạn tốc độ cao nhất? Làm thế nào về ổ đĩa; nó là tốt hơn để có nó trên một RAID bên ngoài hoặc nội bộ? Sao chép có cung cấp cho bạn hiệu suất tốt hơn, đặc biệt với việc đọc các truy vấn lớn?

Bạn đã thực hiện những cài đặt / thay đổi nào khác để cải thiện hiệu suất của MySQL?

Lưu ý: Tôi nhận thấy chúng rất phụ thuộc vào việc sử dụng (nghĩa là trang web nhỏ so với kho dữ liệu), nhưng theo tôi nghĩ hầu hết chúng ta có thể làm việc trên nhiều trang web / hệ thống khác nhau, thật tốt khi biết nhiều kỹ thuật có thể áp dụng cho các kỹ thuật khác nhau tình huống. Ngoài ra, tôi nghĩ rằng một số kỹ thuật có thể được chuyển giao giữa các tình huống.

Dưới đây là những đề xuất của tôi (phần kê của bạn có thể thay đổi)

• Sử dụng RAID phần cứng. Điều này trái với khuyến nghị của tôi là sử dụng RAID phần mềm trong các bài đăng khác, tuy nhiên đây là tình huống cụ thể mà bạn muốn thẻ RAID phần cứng. Cụ thể, bạn muốn NVRAM được hỗ trợ pin trên thẻ RAID để giảm thời gian đưa fsync tệp nhật ký vào đĩa.
• Sử dụng CHỈ RAID 1 hoặc RAID 10 ổ. Chi phí của RAID 5 hoặc 6 ghi là quá cao để có thể chịu đựng được trong một khối lượng công việc đọc / ghi hỗn hợp.
• Sử dụng các LUN riêng cho khối lượng dữ liệu, nhật ký và tmp. Tất cả nên tách biệt với hệ điều hành và khối lượng trao đổi.
• Sử dụng InnoDB .
• Sử dụng innodb_file_per_table
• Sử dụng hệ điều hành 64 bit
• Đặt nhóm bộ đệm InnoDB của bạn thành ~ 80% RAM có sẵn của bạn
• Đặt tệp nhật ký của bạn thành 1/4 kích thước nhóm bộ đệm của bạn, bạn có từ 2 đến 4 tệp nhật ký. Các tệp nhật ký lớn hơn có nghĩa là thời gian tắt và khôi phục chậm hơn, nhưng cho phép bạn khôi phục các bãi chứa cơ sở dữ liệu lớn nhanh hơn.
• log_slow_queries, log-query-not-used-indexes, set-biến = long_query_time = 1, điều tra mọi truy vấn trong nhật ký đó, cấu trúc lại lược đồ của bạn để tránh quét bảng và bảng tmp bất cứ khi nào có thể.

Một lần nữa Dave Cheney thực sự đánh bật nó ra khỏi công viên ở đây. Tôi thực sự không thể thêm bất cứ điều gì vào câu trả lời của anh ấy cho câu hỏi của bạn. Tuy nhiên, tôi muốn chỉ ra những gì bạn không hỏi. Như Jeremy Zawodny và Peter Zaitsev đã dạy tôi cách đây nhiều năm, ROI của bạn dành thời gian theo dõi và tối ưu hóa các truy vấn xấu sẽ thực hiện ROI của bạn trong thời gian thay đổi cấu hình gấp 10 lần. Chắc chắn, bạn không muốn có cấu hình kém, thiết lập RAID sai hoặc RAM không đủ. Nhưng, trong số tuyệt vời, và thậm chí biên, truy vấn xấu MySQL DBA (thường là từ các nhà phát triển / khuôn khổ, không phải là DBA) là một mãn điều kiện, nơi cấu hình xấu là một dẻo dai một.

(Tôi đã đào những tính từ đó một lúc và vẫn không hài lòng với những tính từ tôi đã chọn.)

Tôi muốn nhấn mạnh một lần nữa rằng nếu các nhà phát triển của bạn đang sử dụng ORM giống như các khung phổ biến trong các khung như Ruby on Rails và Django, thì bạn THỰC SỰ PHẢI giám sát các truy vấn đánh vào DB của bạn. Khi các nhà phát triển ngừng suy nghĩ về SQL và để DB bị trừu tượng hóa, điều này thực sự khó chịu. Tôi yêu hai khung mà tôi vừa đề cập. (Đừng bỏ phiếu cho tôi vì đã nói xấu họ.) Nó chỉ làm cho Truy vấn điều tra rất quan trọng. (Đọc: Bảo mật công việc)

Vài điều khác (chưa được đề cập trong câu trả lời của Dave Cheney)

• Hãy thử đặt innodb_flush_method thành O_DIRECT để tránh đệm đôi dữ liệu. Tránh điều này nếu thẻ RAID của bạn không có bộ đệm ghi được sao lưu bằng pin hoặc dữ liệu của bạn nằm trên SAN.

• Cũng chơi với innodb_thread_concurrency. Tôi tin rằng mặc định là 8 nhưng nó đáng để điều chỉnh để xem nó có cải thiện hiệu suất không

• Đảm bảo bộ đệm truy vấn được bật và kiểm tra số liệu thống kê để xem tỷ lệ trúng là gì. Nếu nó tốt hãy thử tăng nó để xem nó có cải thiện tỷ lệ trúng không.

• Tùy thuộc vào các ứng dụng chạy, bạn có thể thay đổi mức cô lập mặc định. Mặc định là REPEATABLE_READ nhưng READ_COMMITTED có thể mang lại cho bạn hiệu suất tốt hơn

• Nếu các câu lệnh của bạn chủ yếu là CẬP NHẬT và XÓA thì bạn có thể thử mồi bộ đệm trên nô lệ bằng cách thực hiện một truy vấn CHỌN trả về tập kết quả sẽ được sửa đổi. Kiểm tra công cụ mk-Slave-prefetch sẽ làm điều này cho bạn

• Hãy xem các công cụ lưu trữ khác ngoài MyISAM và InnoDB

Không thể nói bất cứ điều gì về phần cứng, nhưng bạn có thể thử http://blog.mysqltuner.com . Đó là tập lệnh Perl phân tích cài đặt MySQL của bạn.

Bạn có thể thấy một đầu ra mẫu tại http://www.thomas-krenn.com/de/wiki/MySQL_Performance_Tuning#mysqltuner.pl

Điều chung đầu tiên bạn nên làm là nhìn vào các tham số bộ nhớ. Các thiết lập mặc định cho MySQL là rất rất bảo thủ. Dù bạn sử dụng công cụ nào, có thể bạn sẽ cần tăng một số tham số bộ nhớ lên gấp mười hoặc thậm chí hàng trăm lần.

Điều tiếp theo bạn nên làm là nhìn vào bộ đệm của bảng. Giá trị mặc định là 64, chỉ hữu ích nếu bạn không có nhiều hơn khoảng 60 bảng. Bạn sẽ muốn nâng cao điều đó một chặng đường dài.

Điều thứ ba bạn nên làm là nhìn vào các tham số luồng và kết nối. Wait_timeout mặc định cực kỳ dài đối với hầu hết các ứng dụng dựa trên web và có thể giảm xuống còn khoảng 30 giây. Điều này cũng sẽ cải thiện việc sử dụng bộ nhớ, vì MySQL sẽ gặt hái các kết nối sớm hơn, ít để lại sự dối trá trong trạng thái 'ngủ'.