Tốt nhất của MyISAM và InnoDB

Có thể làm cho InnoDB sử dụng các chỉ mục giống như MyISAM thay vì chỉ mục được nhóm lại do giới hạn của RAM trong khi nhận được lợi ích từ hiệu suất đồng thời của nó?

Các gen_clust_index (clustered index) dưới mui xe của InnoDB nhà mục của khóa chính cùng với rowids. Điều thú vị về việc sử dụng gen_clust_index là thực tế là bất kỳ chỉ mục không duy nhất nào bạn tạo sẽ luôn có một hàng tương ứng cho gen_clust_index của bảng. Do đó, luôn có các tra cứu chỉ mục kép, một cho chỉ mục phụ và một cho gen_clust_index.

Mọi nỗ lực cải thiện bố cục của bảng hoặc khóa chính đều bị vô hiệu hóa do gen_clust_index hoặc ít nhất là kết quả cận biên tốt nhất.

THÍ DỤ

Một số người cố gắng sắp xếp MyISAM theo thứ tự CHÍNH. Theo Thiết kế và Điều chỉnh Cơ sở dữ liệu MySQL, Đoạn 7, dưới tiêu đề "Lưu bảng trong thứ tự chỉ mục":

Nếu bạn thường xuyên truy xuất phạm vi lớn dữ liệu được lập chỉ mục từ một bảng hoặc sắp xếp kết quả nhất quán trên cùng một khóa chỉ mục, bạn có thể muốn xem xét việc chạy myisamchk với tùy chọn --sort-records. Làm như vậy để yêu cầu MySQL sắp xếp dữ liệu của bảng theo thứ tự vật lý giống như chỉ mục và có thể giúp tăng tốc các loại hoạt động này. Ngoài ra, bạn có thể kết hợp câu lệnh ALTER TABLE với tùy chọn ORDER BY một tùy chọn cột cụ thể để đạt được kết quả tương tự.

Cấp, điều này hoạt động và hoạt động hiệu quả CHO MyISAM . Bạn có thể thực hiện ALTER TABLE ... ĐẶT HÀNG B colNG col1, col2, ..., coln đối với InnoDB trong đó các cột có thể hoặc không phải là phím CHÍNH. Điều này sẽ không tạo ra kết quả nhanh hơn cho InnoDB vì ... đúng vậy ... bạn phải tham khảo gen_clust_index mỗi lần.

Một số người có thể làm cho định dạng hàng của bảng CỐ ĐỊNH bằng cách sử dụng ALTER TABLE mydb.mytb ROW_FORMAT=Fixed;và có thể tăng 20% ​​hiệu suất đọc mà không có bất kỳ thay đổi nào khác. Điều này hoạt động và hoạt động hiệu quả CHO MyISAM . Điều này sẽ không tạo ra kết quả nhanh hơn cho InnoDB vì ... đúng vậy ... bạn phải tham khảo gen_clust_index mỗi lần.

Bạn có thể thực hiện các thao tác sau trên bảng InnoDB có tên mydb.mytb:

CREATE TABLE mydb.mytc LIKE mydb.mytb;
INSERT INTO mydb.mytc SELECT * FROM mydb.mytb ORDER BY col1,col2,...coln;
ALTER TABLE mydb.mytb RENAME mydb.mytd;
ALTER TABLE mydb.mytc RENAME mydb.mytb;
DROP TABLE mydb.mytd;

Điều này sẽ đặt bảng theo thứ tự hàng trong gen_clust_index. Điều này có thể tạo ra kết quả cận biên cho InnoDB tốt nhất vì ... đúng vậy ... bạn phải tham khảo gen_clust_index mỗi lần.

Bây giờ, hãy để một chút vô lý. Có một giao diện NoQuery để truy vấn (chỉ CHỌN) MyISAM và InnoDB được gọi là giao diện HandlerSocket (trước đây gọi là HANLDER) . Điều này cho phép bạn truy cập vào dữ liệu cho phép bạn bỏ qua tất cả các giao thức SQL, ACID và MVCC . Mặc dù có thể, IMHO CÁCH HOÀN THÀNH ĐẾN MÃ VÀ MAINTAIN. AFAIK không có gì trong bản in nêu rõ giao diện HandlerSocket có tương tác với gen_clust_index hay không.

Tóm lại, có nhiều cách để lột da một con mèo. Trong trường hợp này, bạn không thể giữ mèo (gen_clust_index). Tôi đoán đây là lý do tại sao MyISAM tiếp tục tồn tại vì hiệu suất đọc, tính linh hoạt của nó trong thứ tự bảng, định dạng hàng của bảng và các công cụ hỗ trợ cho nó. InnoDB sẽ vẫn được thiết kế theo tính chất tuân thủ ACID của nó cho đến khi một linh hồn dũng cảm nào đó lấy mã nguồn InnoDB và biến nó thành thứ gì đó tốt nhất của cả MyISAM và InnoDB .

Các nhóm chỉ số có lẽ là những lý do để thực hiện đồng thời InnoDB về ổ đĩa quay truyền thống.

Truy cập một hàng thông qua chỉ mục được nhóm nhanh vì dữ liệu hàng nằm trên cùng một trang nơi tìm kiếm chỉ mục dẫn. Nếu một bảng lớn, kiến ​​trúc chỉ mục được phân cụm thường lưu hoạt động I / O của đĩa khi so sánh với các tổ chức lưu trữ lưu trữ dữ liệu hàng bằng một trang khác với bản ghi chỉ mục. (Ví dụ: MyISAM sử dụng một tệp cho các hàng dữ liệu và một tệp khác cho các bản ghi chỉ mục.)

Đĩa I / O đắt tiền. Vì vậy, giảm đó là một lợi ích rất lớn để cải thiện đồng thời.

Nếu I / O đĩa bắt đầu trở nên rẻ hơn và ít bị tắc nghẽn hơn (ví dụ, khi công nghệ SSD trở nên ổn định hơn), Oracle có thể quyết định thay đổi cách hoạt động của các chỉ mục InnoDB. Nhiều khả năng nó sẽ giữ nguyên, bởi vì cùng một công nghệ sẽ làm cho 'giới hạn của RAM' trở thành một vấn đề.

Câu trả lời ngắn gọn: Không.

InnoDB cụm thông qua khóa chính và trong trường hợp không có khóa chính, nó chọn chỉ mục duy nhất đầu tiên. Trong trường hợp không có một chỉ mục duy nhất, nó tạo ra một khóa 6 byte ẩn để phân cụm.

Khi bạn có khóa 6 byte ẩn, mọi chỉ mục phụ đều tham chiếu đến khóa này, thay vì các con trỏ chính xác đến các vị trí hàng (như trong MyISAM), do đó, bạn kết thúc với một khóa phụ, và sau đó là một khóa chính để tìm bản ghi của bạn .

Để ngoại suy một chút từ câu hỏi của bạn, tôi giả sử bạn lo lắng về việc bộ nhớ phù hợp với cây, bởi vì để tìm kiếm hiệu quả, tất cả các nút gốc phải nằm trong bộ nhớ, vì bạn luôn phải đi theo con đường này để tìm các trang lá của mình?

Điều này là đúng, nhưng một điều an ủi là các cơ sở dữ liệu thương mại cố gắng và làm cho cây của họ béo nhất có thể, thay vì sâu. Hãy thử chạy xtrabackup --stats trên dữ liệu của bạn để xem. Ví dụ:

<INDEX STATISTICS>
  table: test/table1, index: PRIMARY, space id: 12, root page 3
  estimated statistics in dictionary:
    key vals: 25265338, leaf pages 497839, size pages 498304
  real statistics:
     level 2 pages: pages=1, data=5395 bytes, data/pages=32%
     level 1 pages: pages=415, data=6471907 bytes, data/pages=95%
        leaf pages: recs=25958413, pages=497839, data=7492026403 bytes, data/pages=91%

Có 497839 trang lá (~ 8GB), nhưng chỉ có 416 trang ở trên (6,5 MB). Tôi đã chạy lệnh này một vài lần trên dữ liệu sản xuất và nó luôn làm tôi ngạc nhiên khi tôi có hàng triệu - hồ sơ và chỉ cấp 1-3 trang + trang lá.