Hotline : 07 088 44444
Thích
Chia sẻ

Sự khác biệt giữa MyISAM và InnoDB là gì?

29/07/2021

MyISAM và InnoDB là hai engine lưu trữ dữ liệu table phổ biến trên MySQL. Vậy MyISAM và InnoDB có gì khác nhau? Nên sử dụng engine lưu trữ nào cho table data trong MySQL?

Khi tạo một table trong MySQL, bạn có thể chọn một engine lưu trữ. Đây chính là cách table data được lưu trữ trong file. Ngoài ra, cũng có nhiều engine lưu trữ khác nhau. Nhưng những engine được sử dụng phổ biến nhất là MyISAM và InnoDB. Cả hai đều là engine lưu trữ mặc định trong các phiên bản MySQL khác nhau. Nếu bạn không chỉ định engine lưu trữ khi tạo table, engine mặc định cho phiên bản MySQL sẽ được sử dụng. Trong các phiên bản MySQL trước 5.5.5, MyISAM là mặc định. Với các phiên bản 5.5.5 trở lên, thì InnoDB là mặc định. Trong hầu hết các trường hợp, MyISAM được khuyến nghị sử dụng. Nhưng đôi khi thì InnoDB cũng có thể được sử dụng để thay thế.

Phân tích MyISAM và InnoDB

Khi nào thì sử dụng MyISAM thay cho InnoDB?

  • Nói chung, nếu một table MyISAM gặp sự cố, thì sự cố sẽ được giới hạn trong table đó. Nó không ảnh hưởng đến các chức năng của các table hoặc cơ sở dữ liệu khác. InnoDB thì khác, các lỗi có thể lan truyền ảnh hưởng sang những table khác. Vì lý do này, ta nên sử dụng MyISAM trong các server với nhiều website.

Khi nào thì sử dụng InnoDB?

  • InnoDB sử dụng row-level locking nhiều hơn là table-level locking. Nên sử dụng InnoDB cho các table cụ thể được ghi thường xuyên có thể giúp giảm thời gian chờ locking. Điều này có thể làm giảm đáng kể việc sử dụng bộ nhớ trong server.
  • Một phần vì cơ sở dữ liệu (CSDL) sử dụng table InnoDB không thể được khôi phục riêng lẻ như Partial VPS Restore. Và một phần vì một số sự cố với table InnoDB có thể gây mấy dữ liệu trong các table khác. Do đó các bản sao lưu tự động phải được kích hoạt, nếu có bất kỳ trang nào đang sử dụng InnoDB.
  • Một phần vì các vấn đề với table InnoDB có thể ảnh hưởng đến quyền truy cập vào các cơ sở dữ liệu khác.

Khi nào không nên sử dụng cả MyISAM và InnoDB?

  • Hầu hết các loại trang web lưu trữ thông tin phiên dưới dạng file. Nhưng nếu nó phải được lưu trữ trong table CSDL, thì MEMORY có thể là lựa chọn tốt hơn MyISAM và InnoDB.
  • Tương tự, một số loại dữ liệu bộ nhớ cache của trang web nếu được lưu trữ trong table CSDL thì nên sử dụng công cụ MEMORY.

Cách thay đổi công cụ lưu trữ của table

Nếu bạn đã có sẵn một table và cần thay đổi sang một công cụ mới. Bạn có thể sử dụng lệnh ALTER TABLE:

mysql> ALTER TABLE dbname.tablename ENGINE = enginename;

Nếu bạn thích sử dụng phpMyAdmin hơn, bạn sẽ cần chọn table:

myisam và innodb

Chọn vào tab “Operations“:

chọn Operations trong phpMyAdmin

Chọn công cụ muốn mà bạn muốn sử dụng trong phần “Storage Engine

chọn kiểu Storage Engine

Nhấp vào nút “Go

thiết lập Storage Engine

Và như vậy là bạn đã thay đổi công cụ lưu trữ cho table thành công.

Giải thích kỹ thuật

Dưới đây là một số thông tin chi tiết hơn về các công cụ lưu trữ. Phần này sẽ giải thích tại sao các công cụ lại có mục đích sử dụng khác nhau.

Điểm tương đồng giữa MEMORY, MyISAM và InnoDB

Bất kỳ cơ sở dữ liệu table nào, dù sử dụng công cụ lưu trữ nào, đều có file .frm. Tên của file này sẽ là tên table, theo sau là phần mở rộng file này. File này chứa table metadata, chẳng hạn như định nghĩa table. Tùy thuộc vào engine của table mà có thể có hoặc không các file được liên kết với table.

MyISAM

  • Một table MyISAM có tổng cộng 3 file. Ngoài file .frm mà tất cả các table đều có, còn có file .MYD chứa dữ liệu table. Cùng với đó là file .MYI chứa các index.
  • Bởi vì MyISAM lưu trữ tất cả thông tin table trực tiếp trong 3 file của table đó. Nên một table bị lỗi sẽ không ảnh hưởng trực tiếp đến chức năng của các table khác.
  • Nếu cần, bạn có thể khôi phục một CSDL đơn lẻ từ Partial VPS Restore. Với điều kiện là tất cả các table trong CSDL đó đều đang sử dụng MyISAM.

InnoDB

Một table InnoDB sẽ có một hoặc hai file, tùy thuộc vào việc innodb_file_per_table có được bật hay không.

  • Cho dù nó được bật hay không, table luôn có file .frm.
  • Nếu nó được bật, cũng sẽ có một file .ibd, chứa dữ liệu table và index.
  • Nếu không được bật, dữ liệu table và index cho tất cả các table sẽ được lưu trữ trong vùng table hệ thống.
  • Do bộ đệm thay đổi, ngay cả khi innodb_file_per_table được kích hoạt, các thay đổi gần đây vẫn chưa được ghi vào file table. Đây là lý do tại sao các CSDL chứa các table InnoDB không thể được khôi phục riêng lẻ. Vì vậy cần bật khôi phục tự động với table InnoDB.
  • InnoDB có quy trình khôi phục sự cố tự động. Khi mysql dừng đột ngột, InnoDB có một số kiểm tra nhất định chạy khi khởi động mysql. Phần lớn quá trình khôi phục sự cố này sẽ hoàn tất các thay đổi trước khi xảy ra sự cố. Và cũng sẽ hoàn tác các thay đổi đang diễn ra nhưng chưa được cam kết. Tuy nhiên, đôi khi quá trình này không thành công, đặc biệt nếu InnoDB đang hoạt động khi MySQL không được shutdown đúng cách. Khi đó, MySQL sẽ hoàn toàn không thể khởi động. Và không có CSDL nào có thể truy cập được.
  • Ngoài ra, nếu InnoDB gặp sự cố và không thể tự động khôi phục, một số table InnoDB có thể bị hỏng, không thể sửa chữa được. Do đó việc bật sao lưu tự động cho table InnoDB càng quan trọng hơn nữa.

MEMORY

  • Một table MEMORY sẽ chỉ có một file .frm. Tương tự như MyISAM và InnoDB, file này chứa định nghĩa table. Dữ liệu table chỉ được lưu trữ trong bộ nhớ.
  • Nếu mysql được khởi động lại, dữ liệu trong table MEMORY sẽ bị mất. Điều này có thể không thành vấn đề nếu đó là dữ liệu tạm thời.
  • table MEMORY sẽ không bao giờ được ghi vào đĩa. table MEMORY không được vượt quá kích thước được chỉ định bởi max_heap_table_size. Nếu table đang filling, bạn sẽ cần thêm nhiều vị trí hơn trong tập lệnh trang web nơi table bị trống.
  • table MEMORY, giống như table MyISAM, sử dụng khóa table-level cho các hoạt động nhất định. Nhưng vì các thay đổi không được ghi vào đĩa, điều này vẫn thường nhanh hơn nhiều so với các hoạt động tương tự trong table MyISAM.
  • Vì dữ liệu từ table MEMORY bị mất khi khởi động lại mysql, dữ liệu table MEMORY bị hỏng không thể ngăn mysql khởi động.
  • Table MEMORY chỉ nên được sử dụng cho dữ liệu tạm thời, không liên tục.

Kết luận

Nếu một table được bao gồm hoàn toàn bằng dữ liệu tạm thời, nên lưu trữ nó trong các table MEMORY. Việc này giúp cải thiện cả tốc độ lẫn khả năng phân chia.

Khi một table không thường xuyên được ghi, đặc biệt là trên một máy chủ có nhiều website. Thì cách an toàn nhất là lưu trữ nó dưới dạng MyISAM. Để đề phòng việc khôi phục InnoDB không thành công.

Nếu một table thường xuyên được ghi và chứa dữ liệu không lâu dài, thì nên được lưu trữ dưới dạng InnoDB. Việc này nhằm ngăn chặn cạnh tranh khóa sử dụng quá nhiều tài nguyên máy chủ. Nếu sử dụng InnoDB cho một table, cần đảm bảo cPanel đã bật sao lưu tự động. Nếu một trang web đủ ‘bận’ để cần đến các table InnoDB. Thì có thể đã đến lúc cân nhắc việc đặt trang đó lên server riêng của chính nó. Việc này giúp ngăn chặn lỗi InnoDB ảnh hưởng đến các trang khác.

Vietnix hy vọng sau khi tìm hiểu sự khác nhau giữa MyISAM và InnoDB, các bạn sẽ có thể lựa chọn được công cụ lưu trữ phù hợp với mục đích sử dụng của mình!

Nếu bạn có thắc mắc hay có vấn đề cần hỗ trợ, bạn có thể liên hệ trực tiếp với Vietnix thông qua các kênh sau:
  • Hotline: 1800 1093 - 07 088 44444
  • Email: support@vietnix.vn
  • Hoặc chat trực tiếp với Vietnix thông qua biểu tượng Livechat ở góc phải màn hình. Đội ngũ chuyên viên của chúng tôi luôn sẵn sàng tư vấn và hỗ trợ bạn 24/7.
Vietnix hiện đang có chương trình khuyến mãi lớn nhất trong năm, giảm giá TRỌN ĐỜI: Đăng ký dùng thử ngay và Vietnix sẽ hoàn tiền 100% nếu quý khách không hài lòng với chất lượng sản phẩm, dịch vụ!
Mình là Bo - admin của Quản Trị Linux. Mình đã có 10 năm làm việc trong mảng System, Network, Security và đã trải nghiệm qua các chứng chỉ như CCNP, CISSP, CISA, đặc biệt là chống tấn công DDoS. Gần đây mình trải nghiệm thêm Digital Marketing và đã hòan thành chứng chỉ CDMP của PersonVUE. Mình rất thích được chia sẻ và hỗ trợ cho mọi người, nhất là các bạn sinh viên. Hãy kết nối với mình nhé!
Bài viết liên quan
Không có bài viết liên quan
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments