Tôi đã sẵn sàng để chuyển từ MyISAM sang InnoDB nhưng muốn biết liệu có một danh sách đầy đủ những thứ cần tìm không? Ví dụ: tôi chưa thấy bất kỳ danh sách nào đề cập rằng việc chạy DISABLE KEYStrên bảng InnoDB sẽ đưa ra cảnh báo, ngoại trừ trang hướng dẫn sử dụng ALTER TABLE. Đó là điều mà tôi cần biết trước khi chuyển đổi. Tôi nghĩ rằng tôi sẽ ổn với các truy vấn của tôi nhưng dường như không.

Đây là một số vấn đề

Sử dụng bộ nhớ

MyISAM

• chỉ lưu trữ các trang chỉ mục.
• chia sẻ keycache (có kích thước bằng key_buffer_size).
• Bạn cũng có thể thiết lập keycache chuyên dụng, một hoặc nhiều bảng cho mỗi bảng bộ đệm .

InnoDB

• lưu trữ các trang dữ liệu và các trang chỉ mục.
• một vùng đệm và một kích thước trước MySQL 5.5
• 1 hoặc nhiều nhóm bộ đệm bắt đầu với MySQL 5.5

Dưới đây là một số truy vấn tôi đã viết và đăng trước đó về cách chọn kích thước phù hợp cho MyISAM Key Cache và InnoDB Buffer Pool .

Chỉ số FULLTEXT

MyISAM

• Hỗ trợ các chỉ mục FULLTEXT

InnoDB

• Bắt đầu với MySQL 5.6, có, nhưng vẫn ở phiên bản beta (CẬP NHẬT: MySQL 5.6 tồn tại và có các chỉ mục FULLTEXT. Nếu bạn đang sử dụng lập chỉ mục FULLTEXT trong MySQL 5.6, hãy đảm bảo bạn đang sử dụng các tùy chọn FULLTEXT dành riêng cho InnoDB )
• Trước MySQL 5.6, điều này có nghĩa là bạn không thể chuyển đổi MyISAM sang InnoDB.

MySQL 5.5 trở lại

Để xác định vị trí các bảng MyISAM có chỉ mục FULLTEXT chạy truy vấn này:

select tbl.table_schema,tbl.table_name from
(
    select table_schema,table_name
    from information_schema.tables
    where engine='MyISAM'
    and table_schema NOT IN ('information_schema','mysql')
) tbl
INNER JOIN
(
    select table_schema,table_name
    from information_schema.statistics
    where index_type='FULLTEXT'
) ndx
USING (table_schema,table_name);

Bất cứ điều gì xuất hiện từ truy vấn này đều không thể được chuyển đổi thành InnoDB cho đến khi bạn nâng cấp lên MySQL 5.6.

BẢNG TỐI ƯU

MyISAM

• Bảng MyISAM bị thu hẹp
• ANALYZE TABLE chạy thống kê chỉ mục trên tất cả các chỉ mục

InnoDB

• BẢNG ANALYZE hoàn toàn vô dụng vì các chỉ số chỉ số luôn bị thu hồi
• Với innodb_file_per_table bị vô hiệu hóa, ibdata1 sẽ phát triển lớn hơn
• Với innodb_file_per_table được bật, tệp không gian bảng (.ibd) bị thu hẹp

Tôi nghĩ rằng Gotcha lớn nhất sẽ là xung quanh innodb là giao dịch. Bạn sẽ muốn biết liệu các thư viện MySQL đang được sử dụng bởi các ứng dụng của bạn auto_commit theo mặc định hay không.

Python , ví dụ, không tự động cam kết. Điều này có nghĩa là nếu một ứng dụng đã chèn một hàng ngay trước khi đóng kết nối thì phần chèn đó sẽ được khôi phục sau khi bạn thay đổi thành innodb. Ví dụ, tập lệnh python sẽ cần phải chắc chắn để gọi Connection.commit ();

Một điểm khác biệt có thể là xung quanh việc chèn hoặc cập nhật nhiều hàng. Hãy xem xét một bộ chèn nhiều hàng

insert into tbl values (...row1...),  (...row2...),  (...rowN....);

Xem xét những gì xảy ra nếu có một số loại lỗi như va chạm khóa duy nhất trên hàng3. Với MyISAM, hai hàng đầu tiên sẽ được viết, theo innodb, tất cả các hàng được viết sẽ được khôi phục để lại không có gì được viết ngay cả khi có lỗi như vậy.

Với innodb bạn sẽ bước vào thế giới của những bế tắc. Chúng không phải là xấu, trừ khi chúng xảy ra với tần suất như vậy để ngăn chặn bất kỳ công việc nào được thực hiện. Tuy nhiên, các ứng dụng của bạn sẽ cần được mã hóa theo cách chúng dự đoán các bế tắc và xử lý chúng một cách thích hợp (điều này rất có thể có nghĩa là chỉ thử lại).

Xem xét giới hạn bộ nhớ / lưu trữ. Innodb tốn nhiều tài nguyên hơn MyISAM. Nếu bạn có đủ RAM để giữ cho vùng đệm của bạn đủ lớn để chứa tất cả các bảng thì bạn là vàng.

Tìm các bảng có khóa chính lớn. Lập chỉ mục cụm của Innodb có nghĩa là mỗi chỉ mục phụ giữ một bản sao khác của PK của hàng tương ứng. Nếu bạn có 2 chỉ mục phụ có nghĩa là mỗi hàng PK được lưu trữ 3 lần (PK + mỗi chỉ mục). Nếu pk trải dài trên một số cột và kiểu dữ liệu lớn (char (N) chẳng hạn), bạn có thể thấy các yêu cầu chỉ mục có thể nhanh chóng bùng nổ trong innodb.