Kích thước giao dịch MySQL - lớn như thế nào là quá lớn?


23

Tôi có một quy trình nhập thường xuyên chạy và tôi muốn đó là một loại thỏa thuận 'tất cả hoặc không có gì', hay còn gọi là giao dịch.

Có nhiều khía cạnh và việc nhập khẩu có thể mang lại bất kỳ nơi nào trong khoảng 100k-1mil + hồ sơ. Điều này tương đương với một trọng tải từ vài MB đến vài trăm MB dữ liệu.

Tôi biết bảng tạm thời là một lựa chọn khác - nhưng phương pháp này có vẻ rất tiện dụng.

Có bất kỳ cảnh báo nào để nhận thức về loại thực hành này với một lượng lớn thao tác dữ liệu giữa các lần xác nhận không? (Bên ngoài cụm tải ghi / lập chỉ mục điển hình một khi đã cam kết)


Cá nhân, tôi thích có một sự cân bằng. Tôi nhập hàng trong các giao dịch 1k hoặc 10k, vì tôi chỉ biết rằng nó sẽ có khoảng 900k hàng và sau đó bị sập vì kích thước bộ đệm hoặc một cái gì đó vô lý. Khá dễ dàng để nhận từ đó, và không nhiều I / O.
Thuyền trưởng Hypertext

Câu trả lời:


20

Một điểm nghẽn cần lưu ý là Bộ đệm Nhật ký InnoDB. Kích thước được đặt bởi innodb_log_buffer_size . Đây là những gì Tài liệu MySQL nói về nó:

Kích thước tính theo byte của bộ đệm mà InnoDB sử dụng để ghi vào tệp nhật ký trên đĩa. Giá trị mặc định là 8MB. Bộ đệm nhật ký lớn cho phép các giao dịch lớn chạy mà không cần ghi nhật ký vào đĩa trước khi giao dịch được cam kết. Do đó, nếu bạn có các giao dịch lớn, làm cho bộ đệm nhật ký lớn hơn sẽ tiết kiệm I / O đĩa.

Không nên nhầm lẫn Bộ đệm Nhật ký InnoDB với Nhóm Bộ đệm InnoDB. Sự khác biệt chính giữa chúng là mục đích của chúng. Bộ đệm Nhật ký InnoDB về cơ bản sẽ ghi lại các thay đổi ngắn hạn được ghi vào nhật ký làm lại (ib_logfile0, ib_logfile1). Nhóm bộ đệm InnoDB (có kích thước bằng innodb_buffer_pool_size ) lưu trữ dữ liệu và các trang chỉ mục sẽ được cam kết (nếu các trang bị bẩn) và cuối cùng được ghi) vào đĩa. Sau khi cam kết, các trang thay đổi vẫn còn trong RAM cho đến khi được xóa thông qua các quy tắc LRU.

Các giao dịch lớn phải chuyển qua Bộ đệm Đăng nhập. Như đã đề cập, bộ đệm nhật ký lớn hơn sẽ giảm I / O đĩa. Chỉ có một cam kết lớn sẽ đưa ra một nút cổ chai.

Bạn có thể muốn xem xét các tùy chọn InnoDB khác để định cấu hình.

Tôi có các bài viết khác về tối ưu hóa InnoDB để nghiên cứu thêm


bằng cách nào đó tôi biết bạn sẽ ở trên này. Cảm ơn câu trả lời thấu đáo mà bạn dường như luôn luôn đưa ra. Câu hỏi phụ: Bạn có tài nguyên nào liên quan đến việc sử dụng innodb_io_capacity không? Khi tài liệu đề xuất một SATA tiêu dùng 5400 / 7200RPM có giá trị 100, chiến lược của bạn mà bạn đề xuất chỉ là 'xóa giới hạn' bằng cách đặt giá trị đó quá cao?
mỏng

Tôi thường đặt innodb_io_capacity cao hơn và để phần cứng vượt trội. Tôi sẽ thêm điều này vào câu trả lời của tôi ngay bây giờ.
RolandoMySQLDBA
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.