Có phải là xấu khi có không gian chỉ mục lớn hơn không gian dữ liệu?


22

Thường thì tôi cần chạy các truy vấn đối với các bảng lớn không có chỉ mục đúng. Vì vậy, tôi yêu cầu DBA tạo ra chỉ số như vậy. Điều đầu tiên anh ta làm là nhìn vào số liệu thống kê bảng và xem kích thước không gian chỉ mục.

Thường thì anh ta sẽ bảo tôi tìm giải pháp thay thế vì "chỉ số đã lớn hơn bảng". Anh ấy cảm thấy chỉ số phải nhỏ hơn dữ liệu, bởi vì, anh ấy nói với tôi "bạn đã bao giờ nhìn thấy chỉ mục trong một cuốn sách chưa? Nó nhỏ hơn nhiều so với chính cuốn sách đó và đó là cách chỉ mục bảng".

Tôi không cảm thấy triết lý của anh ấy là đúng, nhưng tôi không thể thách thức anh ấy vì anh ấy là một DBA chính và tôi là một nhà phát triển. Tôi cảm thấy nếu một truy vấn cần một chỉ mục, thì chỉ mục đó sẽ được tạo, thay vì tìm "cách giải quyết" chỉ tạo ra các SP không thể đọc được và không thể nhầm lẫn.

Tôi chỉ chọn các cột cần thiết. Vấn đề là tôi đang lọc theo ngày nên công cụ sẽ nhất thiết phải quét bảng để khớp với các cột. Truy vấn chạy một lần một ngày, vào ban đêm, để thu thập số liệu thống kê, nhưng phải mất 15 phút để chạy (chúng tôi có một quy tắc khó và nhanh khác: Không có thủ tục nào phải mất hơn 3 phút).

DBA cho tôi thấy số liệu thống kê chỉ số. Có khoảng 10 chỉ mục trên bảng đó, trong đó chỉ có 6 chỉ số được sử dụng (số liệu thống kê cho thấy không có lần truy cập nào đối với 4 trong số chúng). Đây là một hệ thống lớn với hơn 20 nhà phát triển tham gia. Các chỉ mục được tạo ra vì bất kỳ lý do gì, và có lẽ không còn được sử dụng.

Chúng tôi được yêu cầu hỗ trợ SQL Server 2008, vì đó là những gì DB thử nghiệm chạy trên đó. Nhưng các khách hàng là tất cả vào năm 2014 và 2016.

Câu trả lời:


34

Hãy nghĩ về thiết kế chỉ số giống như một công tắc trượt. Bạn có thể di chuyển núm chuyển đổi hình tam giác màu đỏ này bất cứ nơi nào dọc theo đường mà bạn muốn:

Quyết định thiết kế chỉ số

Tôi thường không đo lường nó theo kích thước - tôi thường nghĩ về mặt số lượng chỉ số, nhưng kích thước cũng sẽ ổn.

Có vẻ như DBA của bạn nghĩ rằng công tắc quá xa về bên phải - rằng bạn đã thêm quá nhiều chỉ mục và việc xóa / cập nhật / chèn đang hoạt động quá chậm.

Thay vì tranh luận về vị trí của công tắc, hãy thử hỏi anh ấy về các vấn đề về hiệu suất mà bạn gặp phải do số lượng chỉ mục cao. Có thể người dùng của bạn đang phàn nàn về tốc độ xóa / cập nhật / chèn hoặc anh ta đang thấy khóa chờ hoặc anh ta gặp khó khăn trong việc sao lưu cơ sở dữ liệu do kích thước của nó.

Điểm bắt đầu của tôi thường là 5 và 5: khoảng 5 chỉ mục trên mỗi bảng, với khoảng 5 hoặc ít hơn các trường cho mỗi chỉ mục. Không có gì kỳ diệu về con số đó - nó xuất phát từ việc tôi có 5 ngón tay trên mỗi bàn tay, vì vậy thật dễ dàng để giơ tay lên và giải thích quy tắc.

Bạn có thể cần có nhiều chỉ số LESS hơn 5 khi khối lượng công việc của bạn thiên về các hoạt động xóa / cập nhật / chèn và bạn không có đủ mã lực phần cứng để theo kịp.

Bạn có thể có nhiều chỉ mục THÊM khi khối lượng công việc của bạn chủ yếu ở chế độ chỉ đọc hoặc khi bạn đầu tư nhiều vào phần cứng (như lưu trữ toàn bộ cơ sở dữ liệu trong bộ nhớ và có tất cả lưu trữ trạng thái rắn bên dưới nó.)


4

Ngoài ra, mong muốn có nhiều hơn các chỉ mục "The Ozar 5" trên một bảng có thể chỉ ra rằng bạn có rất nhiều loại truy vấn đọc nặng khác nhau trên bảng.

Điều này có thể chỉ ra rằng bạn có thể hưởng lợi từ một chỉ mục cửa hàng cột được phân cụm hoặc không phân cụm trên bảng.

Thay vì có chỉ số tối ưu cho mỗi N đường dẫn truy cập khác nhau, một cửa hàng cột cung cấp cho bạn chức năng quét cực nhanh và khả năng bỏ qua các cột không cần thiết và các phân đoạn hàng. Vì vậy, bạn có thể có một số lượng nhỏ các chỉ mục BTree cho các giao dịch cực kỳ quan trọng và quay trở lại cửa hàng cột cho mọi thứ khác.

Các chỉ mục của cột được thiết kế để hoạt động trong khối lượng công việc nặng OLTP với SQL Server 2016+. Xem tài liệu để phân tích hoạt động thời gian thực .


3

Tôi thích câu trả lời của Brents và tôi đã nâng cao nó. Tôi muốn thêm một quan điểm khác mặc dù. Tôi đã làm việc như một người dùng, một nhà phát triển và một DBA và cảm thấy rằng các ý kiến ​​không liên quan. Tôi tin rằng tùy thuộc vào người dùng (hoặc các bên liên quan) để quyết định cách truy vấn thực hiện và mất bao lâu để có kết quả. Sau đó, nhà phát triển và DBA phải hợp tác để biến nó thành hiện thực.

Nếu vị trí DBA tại công ty của bạn 'phụ trách' chủ đề này, họ có thể phân tích truy vấn của bạn và đưa ra đề xuất về thiết kế truy vấn tốt hơn hoặc câu trả lời khác cho hiệu suất.

Nếu truy vấn và / hoặc cấu trúc dữ liệu không thể được sửa đổi để đạt được mục tiêu thì tôi nghĩ rằng nó có ba lựa chọn.

  1. Truy xuất dữ liệu chậm
  2. Cập nhật dữ liệu chậm
  3. Thêm tài nguyên phần cứng $$$$

Tất nhiên mọi tình huống đều có nhiều biến số tùy thuộc vào nhiều yếu tố kinh doanh và công nghệ, nhưng tôi tin rằng ba tùy chọn áp dụng cho hầu hết các trường hợp nếu không phải tất cả các trường hợp.


0

Có vẻ quá nghiêm ngặt để cấm các chỉ mục> bảng. Nếu bảng của bạn hiếm khi thay đổi (hoặc thay đổi vào ban đêm khi không có nhiều cạnh tranh về tài nguyên) và nó được truy vấn rất nhiều theo nhiều cách khác nhau, nhiều chỉ mục lớn có thể được biện minh. Các DBA cũng nên cẩn thận không dính mũi vào nơi không thuộc về nó. Nếu anh ta cho bạn / hệ thống của bạn giới hạn về gigabyte, anh ta không nên quan tâm quá nhiều đến việc không gian đó được sử dụng như thế nào. Nếu anh ấy làm việc quá sức, đây có thể là lý do.

Tuy nhiên, có nhiều điều cần xem xét:

  • Rất nhiều chỉ mục làm cho việc chèn / cập nhật / xóa chậm hơn. Vì vậy, nếu bảng của bạn thay đổi nhiều, hãy cẩn thận đừng tạo quá nhiều trong số chúng.
  • Không gian có thể là một vấn đề quá. Không chỉ vì gigabyte tốn tiền (hiện tại không nhiều), mà cả thời gian kể từ khi sao lưu sẽ chậm hơn (tùy thuộc vào cách sao lưu được thực hiện).
  • Hầu hết các cơ sở dữ liệu nghiêm trọng có thể được theo dõi để tìm các chỉ mục hiếm khi hoặc không bao giờ được sử dụng. Xem xét bỏ một số trong số họ.
  • Đôi khi bạn nghĩ rằng bạn cần một chỉ mục, nhưng khi bạn kiểm tra truy vấn của mình chặt chẽ hơn, nó có thể được điều chỉnh và viết lại khác nhau với cùng một kết quả và không cần chỉ mục. Sử dụng kế hoạch giải thích để xem liệu chỉ số được sử dụng hay không.
  • Đôi khi (các) cột cuối cùng có thể được loại bỏ khỏi chỉ mục nhiều cột mà không cần nhiều hiệu suất. Và đôi khi điều này thậm chí có thể thực hiện các truy vấn nhanh hơn vì không gian lưu trữ chỉ mục nhỏ hơn và nhiều chỉ mục sẽ được giữ / lưu vào bộ nhớ trong bất kỳ thời điểm nào.
  • Các chỉ mục dựa trên chức năng có thể thay thế các chỉ số bình thường để tiết kiệm nhiều không gian hơn. Ví dụ: thay vì truy vấn họ đầy đủ, truy vấn cho hai chữ cái đầu tiên cũng ( where substr(surname, 1, 2) = substr(<userinput>, 1, 2) and surname=<userinput>) và create index i on customers(substr(surname,1,2)). Điều này có thể đủ nhanh và chỉ số của bạn sẽ nhỏ hơn.
  • Cơ sở dữ liệu hỗ trợ các loại chỉ mục khác nhau. Một số loại sử dụng ít không gian hơn những loại khác. Có lẽ một số chỉ mục của bạn có thể được chuyển đổi sang loại ít tốn dung lượng hơn? Trước tiên hãy chắc chắn hiểu các loại chỉ mục khác nhau và những tình huống chúng tốt và xấu.
  • Nếu một công việc hàng loạt không thường xuyên là điều duy nhất cần một chỉ mục cụ thể, hãy xem xét việc tạo chỉ mục đó cho công việc hàng loạt đó và bỏ nó sau đó.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.