1. Mối Quan Hệ Giữa Page và Row Trong InnoDB

1.1. Khái Niệm Về Page

• Page là đơn vị lưu trữ cơ bản trong cơ sở dữ liệu InnoDB của MySQL.
• Mỗi page có kích thước cố định; tất cả dữ liệu của bảng được lưu trữ trong các page.
• Kích thước page mặc định trong InnoDB là 16KB, nhưng có thể điều chỉnh thành 4KB, 8KB, 32KB hoặc 64KB tùy theo nhu cầu sử dụng.

1.2. Khái Niệm Về Row

• Mỗi table trong MySQL bao gồm nhiều row, và mỗi row được lưu trữ trong một hoặc nhiều page.
• Một page có thể chứa nhiều row khác nhau.

Lưu ý Quan Trọng:

• MySQL thực hiện thao tác trên page thay vì row, nghĩa là khi thực hiện câu lệnh chọn dữ liệu, MySQL sẽ truy xuất toàn bộ các page chứa các row cần thiết để xử lý.
• Đối với các kích thước page khác nhau (như 4KB, 8KB, 16KB,...), InnoDB quy định rằng độ dài tối đa của mỗi row sẽ không quá 1/2 kích thước của page. Cụ thể:
  • Với page 16KB, độ dài tối đa của một row là khoảng 8KB.
  • Với page 64KB, độ dài tối đa của một row là gần 16KB.

Tóm lại: Hãy tưởng tượng page như một tờ giấy A4, trong khi row là các dòng dữ liệu trên tờ giấy đó. Độ dài của các row không vượt quá một nửa kích thước của page nhằm tối ưu hóa hiệu suất lưu trữ và truy xuất dữ liệu.

Ví Dụ Cụ Thể

Giả sử bạn có một bảng có cấu trúc như sau:

CREATE TABLE employee (
    id INT,
    name VARCHAR(255),
    address VARCHAR(255),
    description TEXT
);

• Nếu kích thước page là 16KB và mỗi row của bảng employee có dung lượng xấp xỉ 8KB, mỗi page có thể chứa được 2 rows.
• Nếu kích thước page là 64KB, một page có thể chứa khoảng 4 rows (vì mỗi row có dung lượng tối đa 16KB).

Việc giới hạn kích thước của mỗi row (tối đa 1/2 kích thước của page) không chỉ giúp tiết kiệm diện tích lưu trữ mà còn cải thiện hiệu suất khi thực hiện các thao tác trên cơ sở dữ liệu.

2. Khi Dữ Liệu Row Vượt Quá Dung Lượng Tối Đa

Khi một row vượt quá kích thước tối đa cho phép, các cột dạng VARCHAR, VARBINARY, BLOB hoặc TEXT sẽ được chuyển sang lưu trữ bên ngoài page (hay còn gọi là off-page storage).

Có hai loại định dạng off-page storage: COMPACT/REDUNDANT và DYNAMIC/COMPRESSED.

2.1. Định Dạng COMPACT / REDUNDANT

InnoDB sẽ lưu trữ một phần dữ liệu của cột dạng biến độ dài trong page chính và phần còn lại trong các overflow pages.

• Cụ thể:
  • InnoDB lưu 768 byte đầu tiên của cột ngay trong row trên page chính.
  • Nếu dữ liệu của cột dài hơn 768 byte, phần còn lại sẽ nằm trong các overflow pages. Ví dụ, nếu cột có dung lượng 1500 byte, 768 byte sẽ ở page chính, và 732 byte còn lại sẽ ở overflow pages.
  • Phía trước 768 byte, có thêm 20 byte để lưu trữ độ dài thực tế của cột và con trỏ trỏ đến danh sách các overflow pages.

Tóm tắt: Trong định dạng COMPACT và REDUNDANT, 768 byte đầu tiên của cột được lưu tạm trong row trên page chính, trong khi phần còn lại sẽ được lưu bên ngoài page.

2.2. Định Dạng DYNAMIC / COMPRESSED

Khi một cột với độ dài thay đổi cần lưu trữ ngoài page, InnoDB không lưu 768 byte đầu tiên ở page chính như ở định dạng COMPACT/REDUNDANT.

• Cụ thể:
  • Toàn bộ dữ liệu sẽ được chuyển ngay đến các overflow pages ngay từ đầu.
  • Chỉ có một con trỏ 20 byte được lưu trên page chính để trỏ đến vị trí của các overflow pages chứa dữ liệu của cột.

Tóm tắt: Trong định dạng DYNAMIC và COMPRESSED, chỉ có con trỏ 20 byte được lưu trên page chính, trong khi toàn bộ dữ liệu của cột được để ở overflow pages, giúp tiết kiệm không gian trên page chính.

Khi Nào Nên Sử Dụng Loại Nào?

• COMPACT/REDUNDANT: Phù hợp khi dữ liệu của cột thường không lớn (dưới 768 byte), vì định dạng này hỗ trợ lưu trữ 768 byte đầu tiên trong page chính, giúp dễ dàng truy cập hơn.
• DYNAMIC/COMPRESSED: Phù hợp với các bảng có nhiều cột lớn, vì toàn bộ dữ liệu được lưu bên ngoài page, giúp tiết kiệm không gian và tăng khả năng chứa row trong một page.

Kết Luận

Hy vọng bài viết này đã giúp bạn hiểu rõ hơn về mối quan hệ giữa page và row trong InnoDB. Để nhận thêm nhiều bài viết thú vị khác, hãy kết nối với tôi qua các trang mạng xã hội:

1. Youtube: https://www.youtube.com/@pdthien
2. LinkedIn: www.linkedin.com/in/pdthien

Tài Liệu Tham Khảo

1. Nguyên lý 3+2 hiệu quả cho mọi database - anh Trần Quốc Huy
2. Tài liệu resmi của MySQL
   source: viblo