Chúng tôi có một ứng dụng trong đó chỉ một trong số các bảng sẽ phát triển thành hàng triệu dòng nhưng phần còn lại sẽ chỉ dưới một triệu. Vậy lời khuyên nào chúng ta nên đi với innodb_file_per_table hoặc để lại như một .ibd? Tôi đọc một số bài báo nói không đi với nó vì bạn cần truy cập nhiều đĩa hơn khi có tham gia để được thực hiện? Chúng tôi sẽ tham gia giữa bảng này và các bảng khác cho mục đích tạo báo cáo.
Câu trả lời:
Bạn phải đi với innodb_file_per_table và bạn cần thực hiện một số cách làm sạch với cơ sở hạ tầng hiện tại của InnoDB.
Tôi đã thấy nhiều máy khách lưu trữ DB thiết lập MySQL và để InnoDB ở trạng thái mặc định. Điều này làm cho không gian bảng hệ thống (được gọi là ibdata1) phát triển mạnh mẽ.
Ngay cả khi bạn đã chuyển sang innodb_file_per_table, tệp .ibd sẽ phải được trích xuất từ ibdata1 và ibdata sẽ không bao giờ co lại. Ví dụ: nếu bạn có một bảng có tên mydb.mytable nằm trong ibdata1 chiếm 2GB, để giải nén nó, bạn phải làm như sau:
BƯỚC 01) Thêm cái này vào /etc/my.cnf
[mysqld]
innodb_file_per_tableBƯỚC 02) service mysql restart
BƯỚC 03) ALTER TABLE mydb.mytable ENGINE=InnoDB;
Điều đó sẽ làm cho tập tin /var/lib/mysql/mydb/mytable.ibd
Thật không may, 2GB dung lượng đã bị chiếm chỗ bởi bảng trước khi thay đổi không thể lấy lại được. Tôi đã viết các bài đăng trước đây về cách thức và lý do để dọn dẹp cơ sở hạ tầng của InnoDB:
Khi bạn thực hiện thay đổi lớn này, đừng quên tăng innodb_open_files (mặc định 300) . Nếu không, truy cập đĩa rất hạn chế.
Liên quan đến tham gia, hãy đảm bảo bạn có các chỉ mục phù hợp hỗ trợ các tiêu chí tham gia.
Sử dụng innodb_file_per_table trong một bản cài đặt mới khiến ibdata1 phát triển rất chậm vì tất cả DDL được thực hiện bên ngoài ibdata. Bạn có thể thu nhỏ bất kỳ bảng InnoDB nào như tôi đã đề cập trước đây như sau:
ALTER TABLE mydb.mytable ENGINE=InnoDB;Khi nói đến các bản sao lưu, hãy cực kỳ cẩn thận tạo các bản sao của các tệp .ibd. Tại sao?
Bên trong mỗi tệp .ibd là giá trị đặc biệt được gọi là framespace_id. Có một danh sách các giá trị framespace_id trong ibdata1. Nếu bạn từng thực hiện bảo trì bảng yêu cầu bỏ và tạo lại bảng, thì không gian bảng sẽ trở nên khác biệt. Tạo một bản sao của tệp .ibd như vậy chỉ có thể được tích hợp lại vào cơ sở dữ liệu để sử dụng nếu bạn cũng tạo một bản sao của ibdata1. Điều đó gây nguy hiểm cho không gian bảng_id của tất cả các bảng InnoDB khác. Theo cách này, tốt hơn là bạn nên thực hiện sao lưu mysqldump vì mysqldumps là bản sao logic của dữ liệu. Nói cách khác, bản sao lưu độc lập với thời điểm của ibdata1 và bạn có thể tự do tải lại mà không gặp vấn đề về khả năng hoạt động.
Đồng ý với @RolandoMySQLDBA, vì một điều mà anh ấy không đề cập đến: sao lưu.
Nếu tất cả các chế độ sao lưu MySQL của bạn đều hoạt động, VÀ bạn không bao gồm tệp .ibd của nó trong chiến lược sao lưu hệ thống tệp của mình, thì điều này không quá quan trọng. Nhưng hãy xem xét rằng việc thêm MỘT BYTES vào bất kỳ bảng innodb nào sẽ gây ra một bản sao lưu gia tăng của bảng .ibd của bạn một cách khôn ngoan khác và bạn có thể thấy rằng bạn sẽ nhanh chóng hết dung lượng lưu trữ dự phòng.
Tôi có một ứng dụng mà tôi có chính xác tình huống này: một số bảng lớn và một số bảng nhỏ hơn.
Tôi quyết định để lại những cái nhỏ trong ibdata1khi đặt những cái lớn hơn vào tập tin của riêng họ.
Tôi làm như vậy bởi khi innodb_file_per_tablebật theo mặc định và chỉ tắt tạm thời cho di chuyển một bảng để ibdata1có ALTER TABLE.
ALTER TABLEhọ. Vì vậy, chiến lược của tôi là innodb_file_per_tablebật thường xuyên và tắt nó một cách ngẫu nhiên để chuyển một cái bàn nhỏ vào ibdata1và sau đó bật lại.