Làm thế nào để bạn chọn một công cụ cơ sở dữ liệu MySQL

Cụ thể, làm thế nào để bạn chọn giữa MyISAM và InnoDB, khi không thiếu tính năng bắt buộc (ví dụ: bạn không cần khóa ngoại).

Có phải nó luôn luôn đi xuống để thử cả hai và đo lường? Hoặc có những quy tắc tốt về số lượng và tần suất đọc so với viết và các biện pháp khác như vậy? Liệu kích thước của bảng có bất kỳ ảnh hưởng đến sự lựa chọn điển hình?

Câu trả lời là bạn nên luôn luôn đo lường, tốt nhất là với dữ liệu và khối lượng công việc của riêng bạn nếu có thể.

Vì các mẫu truy cập dữ liệu có thể thay đổi rất nhiều từ ứng dụng này sang ứng dụng khác, thật khó để nói và rất có thể không thể xác định một công cụ lưu trữ "tốt nhất" cho tất cả các khối lượng công việc.

Tuy nhiên, có những phát triển rất đáng khích lệ trong không gian MySQL đã tham dự MySQLConf / Percona Performance Conf vào tuần trước.

Một số công cụ lưu trữ thay thế:

1. XtraDB (ngã ba của InnoDB)
2. Plugin InnoDB
3. Tổng đài
4. TokuDB

Ngoài ra, Percona, Google, v.v. đã đóng góp các bản vá giúp ích rất nhiều cho hiệu suất của InnoDB. Cá nhân, tôi chạy một bản dựng OurDelta. Nó hoạt động độc đáo đối với tôi và tôi khuyến khích kiểm tra các bản dựng OurDelta và Percona.

Nếu đó chỉ là một hệ thống lưu trữ / báo cáo đơn giản, tôi sử dụng MyISAM cho hiệu suất thô của nó.

Tôi sẽ sử dụng InnoDB nếu tôi lo ngại về nhiều truy cập đồng thời với nhiều lần ghi, để tận dụng khóa cấp hàng.

Có một số điểm chuẩn tốt cho các công cụ cơ sở dữ liệu MySQL khác nhau. Có một bài khá hay so sánh MyISAM, InnoDB và Falcon trên Blog Hiệu suất MySQL của Percona , xem tại đây .

Một điều khác cần xem xét giữa hai công cụ nói trên (MyISAM và InnoDB) là cách tiếp cận của họ để khóa. MyISAM thực hiện khóa bảng, trong khi InnoDB thực hiện khóa hàng. Có rất nhiều điều cần xem xét, không chỉ những con số hiệu suất hoàn toàn.

Có những tính năng mà bạn sẽ thấy rất hữu ích, vì lý do vận hành, ngay cả khi ứng dụng của bạn không hoàn toàn yêu cầu chúng:

• InnoDB có MVCC, có nghĩa là bạn có thể thực hiện các bản sao lưu nhất quán không chặn
• InnoDB có phục hồi tự động, có nghĩa là không có hoạt động REPAIR TABLE kéo dài sau khi tắt máy ô uế
• Với InnoDB, người đọc không bao giờ chặn người viết và ngược lại, nghĩa là (nói chung) đồng thời lớn hơn (điều này không có nghĩa là hiệu suất tốt hơn trong trường hợp chung)
• InnoDB phân cụm các hàng của nó trên khóa chính, điều đó có nghĩa là có ít hoạt động IO hơn cho các hoạt động đọc NẾU khóa chính được chọn đủ tốt.

Vì vậy, bất chấp các ràng buộc khóa ngoại, bạn có thể muốn sử dụng InnoDB.

tất nhiên đây là ServerFault, không phải Stack Overflow, vì vậy câu trả lời thích hợp là:

• Bạn phải luôn sử dụng công cụ mà các nhà phát triển ứng dụng đã chọn
• Nếu họ không chọn một công cụ cụ thể, họ sẽ không nghiêm túc về việc sử dụng MySQL và có lẽ họ không biết sử dụng nó đúng cách.
• Bạn không thể chuyển sang một công cụ khác với công cụ mà ứng dụng của bạn đã được thử nghiệm, nó có thể gây ra lỗi.

Nhà cung cấp dịch vụ lưu trữ của tôi khuyên chúng tôi nên loại bỏ hoàn toàn MyISAM và chuyển sang InnoDB, trừ khi không thể.

Trong trường hợp của chúng tôi, chúng tôi đã bị hỏng dữ liệu nghiêm trọng bắt đầu hiển thị từ vài lần đến vài lần mỗi ngày, luôn yêu cầu BẢNG SỬA CHỮA và các lệnh liên quan, mất nhiều thời gian trên các bảng lớn.

Khi chúng tôi chuyển đổi (hoặc: đã được chuyển đổi) thành InnoDB, các vấn đề ngay lập tức biến mất. Nhược điểm / cảnh báo chúng tôi đã có:

• Không thể chuyển đổi bảng với chỉ mục FULLTEXT (vấn đề này đã tự biến mất theo thời gian; nó đã được thay thế bằng giải pháp dựa trên Solr / Lucene có chất lượng tốt hơn nhiều)
• Các bảng lớn với hàng triệu hàng thường yêu cầu COUNT (*) rất chậm, chúng tôi cũng không thể chuyển đổi các bảng đó.

Nhưng lưu ý: đây là tất cả cụ thể cho môi trường của chúng tôi, vv, vì vậy nó có thể không áp dụng chung.