Nếu một cơ sở dữ liệu chỉ có một lần chèn, việc lập chỉ mục cho mọi tổ hợp cột có thể là không tốt?

Tôi đang làm việc trên một hệ thống báo cáo sẽ yêu cầu các truy vấn chọn lớn, nhưng dựa trên cơ sở dữ liệu chỉ được điền một lần. Hệ thống quản lý cơ sở dữ liệu là Microsoft SQL Server 2017. Có lẽ có một cách tốt hơn để thiết kế một hệ thống như thế này, nhưng hãy tiếp cận về mặt lý thuyết này.

Về mặt lý thuyết:

1. Nếu chúng ta có một cơ sở dữ liệu rất lớn (150M + hàng trên nhiều bảng)
2. Và chúng ta có thể giả sử cơ sở dữ liệu sẽ chỉ được điền một lần.

Có thể lập chỉ mục mọi kết hợp cột có thể có tác động tiêu cực đến một truy vấn được chọn không?

Có, nó sẽ ảnh hưởng đến thời gian biên dịch kế hoạch ban đầu vì trình tối ưu hóa sẽ có nhiều đường dẫn truy cập bổ sung vào dữ liệu để xem xét.

Vì bạn đang sử dụng SQL Server 2017, tải một lần và chạy báo cáo, tại sao không sử dụng chỉ mục lưu trữ cột cụm?

Đó dường như là giải pháp lý tưởng cho nhu cầu của bạn để lập chỉ mục mọi kết hợp cột có thể.

Chỉ mục của cột - Tổng quan

Nếu bạn có N cột trong một bảng, mọi kết hợp cột có thể là 2 ^ N-1 (loại bỏ tập hợp trống). Đối với 10 cột có nghĩa là 1023 chỉ mục, trong 20 cột, chúng tôi kết thúc với 1048575 chỉ mục. Hầu hết các chỉ mục sẽ không bao giờ được sử dụng nhưng sẽ phải được xem xét bởi trình tối ưu hóa. Có thể là trình tối ưu hóa sẽ chọn một chỉ số tối ưu phụ thay vì chỉ số tốt hơn. Tôi sẽ không đi theo con đường tạo ra tất cả các loại chỉ mục, thay vì cố gắng tìm ra những chỉ mục nào thực sự có lợi.

EDIT đã sửa số chỉ mục có thể

Như Jeff chỉ ra, nó thậm chí còn tệ hơn 2 ^ N (bộ sức mạnh) vì (3,2,1) rõ ràng khác với (1,2,3). Đối với N cột, chúng ta có thể chọn vị trí đầu tiên trong một chỉ mục chứa tất cả các cột theo N cách. Đối với vị trí thứ hai theo cách N-1, v.v. Chúng tôi, do đó, kết thúc với N! chỉ số khác nhau của kích thước đầy đủ. Không có chỉ mục nào trong số này được thay thế bởi một chỉ mục khác trong bộ này. Ngoài ra, chúng tôi không thể thêm một chỉ mục ngắn hơn để nó không bị bao phủ bởi bất kỳ chỉ mục đầy đủ nào. Do đó, số lượng các chỉ số là N!. Ví dụ cho 10 cột, do đó, trở thành 10! = 3628800 chỉ mục và cho 20 (trống) 2432902008176640000 chỉ mục. Đây là một con số lớn đến mức nực cười, nếu chúng ta đặt một dấu chấm cho mỗi chỉ số một mm một phần, sẽ mất một ngày ánh sáng 94 ngày để vượt qua tất cả các dấu chấm. Tất cả và tất cả, không ;-)

Không.

Nó không thực tế để lập chỉ mục "mọi thứ", nhưng bạn có thể lập chỉ mục "hầu hết" của nó.

Vấn đề là như thế này. Nếu một bảng có Ncác cột, thì số lượng các chỉ mục có thể là N!. Giả sử một bảng có 10 cột, sau đó bạn không chỉ có 10các chỉ mục có thể, nhưng 10!. Đó là ... 3.628.800 ... trên một bảng. Đó là rất nhiều không gian đĩa, I / O đĩa, bộ đệm và thời gian tìm kiếm.

Tại sao? Một vài lý do:

• Các chỉ số Lightwwight thường được lưu trong bộ nhớ cache, một cái gì đó làm cho chúng phát sáng nhanh. Nếu bạn có 3 triệu trong số họ, họ sẽ KHÔNG được lưu vào bộ nhớ cache.

• Trình tối ưu hóa SQL có thể mất nhiều thời gian để quyết định cái nào tốt hơn để sử dụng, đặc biệt khi sử dụng các phép nối.

• Trình tối ưu hóa SQL có thể từ bỏ việc sử dụng thuật toán toàn diện và thay vào đó hãy thử một thuật toán heuristic. Điều này có thể là "ít hơn tối ưu". Ví dụ, PostgreSQL có các tùy chọn khác nhau cho "truy vấn bảng nhỏ hơn 8" và "truy vấn bảng nhiều hơn 8".

• Các chỉ số được cho là nhẹ hơn heap. Nếu bạn đang lập chỉ mục mọi thứ, thì chỉ số sẽ trở nên nặng nề như đống ... thứ gì đó đánh bại mục đích của chỉ mục.

Không, nó có thể sẽ không có tác động tiêu cực đến các SELECTtruy vấn, nhưng

• Nó sẽ gây ra việc sử dụng đĩa cao.
• Nó sẽ làm tăng chi phí rất nhiềuINSERT .
• Hầu hết các chỉ số của bạn sẽ không bao giờ được sử dụng.
• Nhiều WHEREbiểu thức điều kiện vẫn không sử dụng các chỉ số, chủ yếu là các biểu thức phức tạp hơn.
• Số lượng các chỉ số cần thiết sẽ tăng theo cấp số nhân với số lượng cột. Tức là nếu bạn có, ví dụ, 8 cột, bạn cần 256 chỉ mục cho tất cả các kết hợp có thể.