Làm thế nào để cải thiện hiệu suất MySQL INSERT và UPDATE?

Câu hỏi này có lẽ cũng có thể được hỏi trên StackOverflow, nhưng tôi sẽ thử ở đây trước ...

Hiệu suất của các câu lệnh INSERT và UPDATE trong cơ sở dữ liệu của chúng tôi dường như đang suy giảm và gây ra hiệu suất kém trong ứng dụng web của chúng tôi.

Các bảng là InnoDB và ứng dụng sử dụng các giao dịch. Có bất kỳ điều chỉnh dễ dàng nào mà tôi có thể thực hiện để tăng tốc mọi thứ không?

Tôi nghĩ rằng chúng ta có thể thấy một số vấn đề khóa, làm thế nào tôi có thể tìm ra?

1. Kiểm tra xem phần cứng và hệ điều hành của bạn có được cấu hình và điều chỉnh đúng không:

   • Nguồn của sự cố (CPU / IO / Bộ nhớ / Hoán đổi sử dụng). Bạn có nhiều IOP không? CPU đã được tải chưa? Nếu bạn có nhiều đọc IOP thì có lẽ bạn không có đủ bộ đệm InnoDB lớn_pool. Nếu CPU được tải, có thể các truy vấn của bạn sẽ quét toàn bộ bảng thay vì sử dụng các chỉ mục thích hợp.
   • Thiết lập đĩa / RAID / LVM. Trong một số thiết lập cụ thể, phân chia LVM có thể mang lại cho bạn lợi ích bằng cách tăng tốc độ tải đĩa (không có RAID phần cứng, nhiều LUNS được kết nối)
   • Bộ lập lịch IO: khi bạn có bộ điều khiển RAID phần cứng tốt, có lẽ noop là tốt nhất. RedHat đã thực hiện một số thử nghiệm và họ nói rằng, đối với CFQ của Oracle (và DB khác) là sự lựa chọn tốt nhất. Bạn cần chạy một số điểm chuẩn (như tpc-c hoặc tpc-e) và chọn, cái gì là tốt nhất cho phần cứng của bạn.
   • Hệ thống tập tin tốt - ext3 không hoạt động tốt trong khối lượng công việc cụ thể của cơ sở dữ liệu. Tốt hơn là XFS hoặc OCFS2. Bạn cần một số điểm chuẩn một lần nữa.
   • Xem, nếu hệ thống của bạn sử dụng trao đổi. Sử dụng trao đổi làm giảm hiệu suất mysql .

2. Kiểm tra, nếu phiên bản MySQL / InnoDB của bạn được điều chỉnh đúng:

   • kích thước nhóm bộ đệm - các trang dữ liệu bộ nhớ cache trong bộ nhớ
   • innodb_flush_method = O_DIRECT - tránh bộ đệm IO gấp đôi
   • tăng kích thước tệp nhật ký InnoDB - để ghi khối lượng công việc lớn, điều này có thể cải thiện hiệu suất. Nhưng hãy nhớ: kích thước tệp nhật ký lớn hơn có nghĩa là phục hồi sự cố lâu hơn. Đôi khi trong vài giờ !!!
   • innodb_flush_log_at_trx_commit = 0 hoặc 2 - Nếu bạn không quan tâm đến ACID và có thể mất các giao dịch trong một hoặc hai giây cuối cùng.
   • key_buffer_size - rất quan trọng đối với MyISAM, nhưng nó được sử dụng cho các bảng tạm thời trên đĩa.
   • Xem TÌNH TRẠNG INNODB của bạn
3. Phân tích khối lượng công việc của bạn - bắt tất cả các truy vấn của bạn để ghi nhật ký chậm và chạy mk-query-digest trên đó. Bạn có thể bắt tất cả các truy vấn bằng tcpdump và maatkit
   • Những truy vấn nào chiếm phần lớn thời gian máy chủ của bạn?
   • Có bất kỳ bảng tạm thời được tạo ra, đặc biệt là các bảng tạm thời lớn?
   • Tìm hiểu, làm thế nào để sử dụng giải thích
   • Là ứng dụng của bạn sử dụng giao dịch? Khi bạn chạy truy vấn với autocommit = 1 (mặc định là MySQL), mọi truy vấn chèn / cập nhật sẽ bắt đầu giao dịch mới, thực hiện một số chi phí. Nếu có thể, tốt hơn là tắt autocommit (trong python Trình điều khiển autocommit của trình điều khiển MySQL bị tắt theo mặc định) và thực hiện thủ công cam kết sau khi tất cả các sửa đổi được thực hiện.
   • Là ứng dụng của bạn tạo ra một loạt các chèn vào cùng một bảng trong một vòng lặp? Load data infilelệnh nhanh hơn nhiều cho loạt chèn.
   • Hãy nhớ rằng: select count(*) from table;chậm hơn nhiều đối với innodb so với myisam.
   • Những loại truy vấn INSERT / UPDATE chiếm phần lớn thời gian của máy chủ? Làm thế nào họ có thể được tối ưu hóa?
   • Kiểm tra, nếu DB của bạn có các chỉ mục thích hợp và thêm chúng, nếu cần.

Trong môi trường của chúng tôi, chúng tôi đã có tình huống, một loại truy vấn cập nhật chậm. Thời gian dự kiến ​​để hoàn thành công việc hàng loạt là 2 ngày !!! Sau khi phân tích nhật ký chậm mà chúng tôi tìm thấy, loại truy vấn cập nhật này cần 4 giây để hoàn thành. Truy vấn trông như thế này : update table1 set field1=value1 where table1.field2=xx table2.field3=yy and table2.field4=zz. Sau khi chuyển đổi truy vấn cập nhật để chọn truy vấn và chạy giải thích về truy vấn chọn mà chúng tôi tìm thấy, loại truy vấn này không sử dụng chỉ mục. Sau khi tạo chỉ mục thích hợp, chúng tôi đã giảm thời gian thực hiện truy vấn cập nhật xuống còn milis giây và toàn bộ công việc đã hoàn thành trong vòng chưa đầy hai giờ.

Một số liên kết hữu ích:

• SHOW INNODB TÌNH TRẠNG đi bộ qua
• Điều gì để điều chỉnh trong Máy chủ MySQL sau khi cài đặt
• Khái niệm cơ bản về tối ưu hóa hiệu suất của Innodb
• Cách tính kích thước tệp nhật ký InnoDB tốt
• Chọn innodb_buffer_pool_size
• Chọn innodb_log_file_size thích hợp

Với cấu hình innoDB mặc định, bạn sẽ bị giới hạn về tốc độ bạn có thể viết và xóa các giao dịch vào đĩa. Nếu bạn có thể đối phó với việc mất một chút ACID, hãy thử nghiệm với innodb_flush_log_at_trx_commit. Đặt thành 0 để ghi và xóa nhật ký vào đĩa mỗi giây. Đặt thành 1 (mặc định) để viết và xóa trên mỗi cam kết. Đặt thành 2 để ghi vào tệp nhật ký sau mỗi lần xác nhận nhưng chỉ xóa một lần mỗi giây.

Nếu bạn có thể đối phó với việc mất 1 giây giao dịch, đây có thể là một cách tuyệt vời để cải thiện đáng kể hiệu suất ghi.

Ngoài ra, hãy chú ý đến những gì đĩa của bạn đang làm. RAID 10> RAID 5 để ghi với chi phí của một đĩa phụ.

Sự cố khóa sẽ được kiểm tra bằng các trạng thái kết nối trong show full processlist;

Đọc qua my.cnftài liệu và MySQL. Các tùy chọn cấu hình được ghi lại rất tốt.

Nói chung, bạn muốn xử lý càng nhiều trong bộ nhớ càng tốt. Để tối ưu hóa truy vấn, điều đó có nghĩa là tránh các bảng tạm thời. Áp dụng đúng các chỉ số.

Điều chỉnh sẽ được cụ thể cho công cụ cơ sở dữ liệu và kiến ​​trúc ứng dụng ưa thích của bạn. Có tài nguyên đáng kể có sẵn một tìm kiếm Internet đi.

• Tài liệu MySQL
• Điều gì để điều chỉnh trong Máy chủ MySQL sau khi cài đặt

Bật màn hình Innodb có thể giúp xác định nguyên nhân gây ra khóa và khóa chết:

HIỂN THỊ TÌNH TRẠNG CÔNG CỤ INNODB và Màn hình InnoDB

InnoDB là một công cụ khá tốt. Tuy nhiên, nó rất phụ thuộc vào việc được 'điều chỉnh'. Một điều là nếu các phần chèn của bạn không theo thứ tự tăng khóa chính, innoDB có thể mất nhiều thời gian hơn MyISAM một chút. Điều này có thể dễ dàng khắc phục bằng cách đặt innodb_buffer_pool_size cao hơn. Đề nghị của tôi là đặt nó ở mức 60-70% tổng RAM của bạn. Tôi hiện đang chạy 4 máy chủ như vậy trong sản xuất, chèn khoảng 3,5 triệu hàng mỗi phút. Họ đã có gần 3 Terabyte. InnoDB phải như vậy, vì các phần chèn rất đồng thời. Có nhiều cách khác để tăng tốc độ chèn. Và tôi đã điểm chuẩn một số.