Là các cột không phải là chỉ mục, được sắp xếp trên đĩa cùng với chỉ mục?

Các cột không phải là chỉ mục, được sắp xếp trên đĩa cùng với chỉ mục, trong MySQL, trong MyISAM và InnoDB?

Một suy nghĩ không chính xác mà tôi bắt đầu viết:

Tôi nghĩ rằng có lẽ là không, vì chúng không được lập chỉ mục; nếu chúng được sắp xếp có nghĩa là chúng là các chỉ mục.

Điều này không đúng vì mỗi cột chỉ mục được sắp xếp theo thứ tự nội dung của chính nó, nhưng tôi đang hỏi về việc được sắp xếp theo thứ tự của mỗi hàng (hoặc chỉ một số cột) với chỉ mục tương ứng.

Để giải thích, tôi nói: điều này sẽ hữu ích để làm cho việc chọn các phạm vi của các hàng, song song với nhau, bởi các chỉ mục của chúng, nhanh hơn. Ví dụ: nếu tôi muốn select * where id >1000 and id<2000(có thể có lỗi trong cú pháp MySQL, tôi không biết rõ về nó), thì cột id có thể được đọc nhanh từ đĩa vì có lẽ các ô của nó từ 1000 đến 2000 nằm cùng nhau trên đĩa vật lý . Nhưng nội dung cột khác tương ứng với id 1000 đến 2000 có thể được ghi trên các vị trí khác nhau trên đĩa vật lý. Nếu chúng cũng được sắp xếp, chúng sẽ được đọc nhanh hơn. Tôi nghĩ, có lẽ MySQL tự động sắp xếp các cột đó trên đĩa vật lý, để thực hiện các hoạt động đó.

Chúng có được sắp xếp trong các loại cơ sở dữ liệu khác (PostgreSQL, v.v.) không?

27 tháng 12: Tôi thấy từ 2 câu trả lời, trong trường hợp khi có chỉ mục / khóa chính được phân cụm, các hàng đơn giản không được sắp xếp trên đĩa vật lý (như tôi nghĩ nó có thể / có thể) và thậm chí chỉ mục được nhóm không được sắp xếp, nếu đó là b-cây, tôi đã đọc về b-cây và thấy rằng các nút của nó, theo tôi hiểu, ở lại các vị trí ngẫu nhiên trên đĩa.

Họ có thể được sắp xếp trong một số trường hợp. Các sắp xếp chỉ số thường được gọi là chìa khóa phân nhóm . Nếu đó là trường hợp thì toàn bộ bảng được lưu trữ bên trong chỉ mục đó (thường là trong một loại cấu trúc cây B).

Trong trường hợp khác, cấu trúc bảng được gọi là một đống , các hàng được lưu trữ khi chúng đến, xóa các "lỗ" trong các khối dữ liệu và các lỗ đó sau đó được lấp đầy bằng các hàng mới, do đó, ngay cả "thứ tự chèn" cũng không được giữ nguyên.

MyISAM sử dụng cấu trúc heap , với mỗi hàng được xác định bởi offset (loại chỉ mục mảng ) vào tệp dữ liệu. Mỗi chỉ mục sau đó chứa (các) cột được lập chỉ mục cho mỗi hàng, được sắp xếp theo thứ tự phù hợp và với số bù để xác định hàng thực. Điều đó có nghĩa là việc truy cập hàng bằng bất kỳ chỉ mục nào có nghĩa là định vị (các) nút bên phải trong chỉ mục (cây B) và sau đó đọc (các) phần bù bên phải từ tệp dữ liệu (tìm kiếm ngẫu nhiên đến một phần khác của đĩa có thể xảy ra ).

InnoDB sử dụng phân cụm theo khóa chính (hoặc nếu không được xác định, khóa duy nhất không null đầu tiên được sử dụng hoặc cột tự động nội bộ được thêm vào - vì vậy các hàng luôn được sắp xếp theo cách nào đó). Trong trường hợp như vậy, quyền truy cập của khóa chính là "trực tiếp", khi giá trị phù hợp được đặt, bạn có toàn bộ hàng trong tay, không cần phải đọc lần thứ hai. Mặt khác, các chỉ mục phụ không thể lưu trữ một phần bù như trong MyISAM (vì cây B tự động tự cân bằng lại, do đó phần bù của một hàng cụ thể có thể thay đổi bất cứ lúc nào) và thay vào đó chúng lưu trữ các giá trị khóa chính của hàng - truy cập bằng khóa phụ có nghĩa là hai tìm kiếm cây B trong InnoDB.

MS SQL Server cung cấp tùy chọn để tạo khóa chính (hoặc chỉ mục khác) được phân cụm hoặc không được bao gồm, do đó bạn có thể chọn giữa heap (không có chỉ mục nào được phân cụm) và cấu trúc cây (một chỉ mục được phân cụm). Tất cả các chỉ mục không phân cụm khác lưu trữ một giá trị đặc biệt (RowID) trong trường hợp heap hoặc các giá trị khóa được nhóm của hàng trong trường hợp CI.

PostgreSQL chỉ sử dụng các bảng heap nhưng cho phép bạn sắp xếp lại chúng theo một số chỉ mục theo yêu cầu (bạn phải kích hoạt nó, vì vậy các hàng được sắp xếp sau hành động nhưng ghi thêm vào bảng có thể phá vỡ thứ tự đó một lần nữa).

TokuDB (công cụ MySQL / MariaDB của bên thứ 3) có thể sử dụng nhiều khóa phân cụm trên một bảng - hiệu quả là nó duy trì nhiều bản sao của bảng, mỗi cách được sắp xếp khác nhau. Nó đi kèm với một hình phạt về việc viết, nhưng TokuDB tuyên bố sẽ sử dụng đôi khi họ gọi các chỉ số fractal sẽ làm cho hình phạt đó khá nhỏ.

Nếu bạn cần sử dụng chức năng đó cho một số truy vấn, bạn có thể "mô phỏng" nó bằng cách tạo một chỉ mục bao phủ - theo cách đó các colums nhu cầu truy vấn của bạn có sẵn theo đúng thứ tự bất cứ lúc nào, nhưng một lần nữa, điều đó có nghĩa là duy trì một bản sao được đặt hàng của (các phần của ) bảng trong chỉ mục của bạn.

Câu trả lời ngắn gọn và đơn giản cho cơ sở dữ liệu nói chung là: không, thứ tự vật lý của các hàng trong một bảng thường không giống như trong một số chỉ mục trên bảng đó.

Nói chung (tôi nói chung vì có những trường hợp đặc biệt không đúng) bảng và chỉ mục là hai cấu trúc vật lý khác nhau trên đĩa. Các RDBM thông thường lưu trữ dữ liệu sao cho các giá trị từ một hàng của bảng (không phải cột ) được đặt cạnh nhau trên đĩa; các hàng không được lưu trữ theo thứ tự cụ thể. Các mục chỉ mục, mặt khác, được lưu trữ theo thứ tự; một chỉ mục cây b điển hình chứa các giá trị được sắp xếp của các cột được lập chỉ mục (nhưng không phải các cột khác!) và một số loại con trỏ tới vị trí của toàn bộ hàng trong bảng, như tôi đã nói trước đây, một cấu trúc vật lý riêng biệt trên đĩa.

Điều đó đang được nói, có những trường hợp đặc biệt. Ví dụ: InnoDB của MySQL lưu trữ các hàng dữ liệu thực tế trong một cấu trúc giống như chỉ mục. Lập chỉ mục theo đó các hàng được đặt trong "bảng chỉ mục" như vậy thường là khóa chính của bảng; và một chỉ mục như vậy được gọi là một chỉ mục cụm . Nhưng tất nhiên, một bảng InnoDB có thể có các chỉ mục và thứ tự các hàng khác (nghĩa là các cột hàng được bao gồm trong chỉ mục tương ứng) trong các chỉ mục đó không liên quan gì đến việc sắp xếp các hàng trong chính bảng đó.