Giới thiệu
Kiến thức phổ biến trong vòng kết nối cơ sở dữ liệu là các chỉ mục cải thiện hiệu suất truy vấn bằng cách đáp ứng hoàn toàn tập kết quả được yêu cầu (Bao gồm các chỉ mục) hoặc hoạt động như các tra cứu giúp dễ dàng hướng Công cụ truy vấn đến vị trí chính xác của tập dữ liệu được yêu cầu. Tuy nhiên, như những DBA có kinh nghiệm đều biết, không nên quá nhiệt tình với việc tạo chỉ mục trong môi trường OLTP mà không hiểu bản chất của khối lượng công việc. Sử dụng Cửa hàng truy vấn trong phiên bản SQL Server 2019 (Cửa hàng truy vấn đã được giới thiệu trong SQL Server 2016), khá dễ dàng để hiển thị ảnh hưởng của chỉ mục đối với các lần chèn.
Chèn mà không có chỉ mục
Chúng tôi bắt đầu bằng cách khôi phục cơ sở dữ liệu Mẫu WideWorldImporters và sau đó tạo một bản sao của Bán hàng. Bảng hóa đơn sử dụng tập lệnh trong Liệt kê 1. Lưu ý rằng cơ sở dữ liệu mẫu đã bật Cửa hàng truy vấn ở chế độ đọc-ghi.
-- Listing 1 Make a Copy Of Invoices SELECT * INTO [SALES].[INVOICES1] FROM [SALES].[INVOICES] WHERE 1=2;
Lưu ý rằng không có chỉ mục nào trong bảng mà chúng tôi vừa tạo. Tất cả những gì chúng ta có là cấu trúc bảng. Sau khi hoàn tất, chúng tôi thực hiện chèn trong bảng mới bằng cách sử dụng dữ liệu từ cha của nó như được hiển thị trong Liệt kê 2.
-- Listing 2 Populate Invoices1 -- TRUNCATE TABLE [SALES].[INVOICES1] INSERT INTO [SALES].[INVOICES1] SELECT * FROM [SALES].[INVOICES]; GO 100
Trong hoạt động này, Cửa hàng truy vấn nắm bắt kế hoạch thực thi của truy vấn. Hình 1 cho thấy ngắn gọn những gì đang xảy ra dưới mui xe. Đọc từ trái sang phải, chúng tôi thấy rằng SQL Server thực thi chèn bằng cách sử dụng ID kế hoạch 563 - Quét chỉ mục trên Khóa chính của bảng nguồn để tìm nạp dữ liệu và sau đó là Chèn bảng trên bảng đích. (Đọc từ trái sang phải). Quan sát rằng trong trường hợp này, phần lớn chi phí nằm ở Phụ trang bảng - 99% chi phí truy vấn.
Hình 1 Kế hoạch thực hiện 563
Hình 2 Chèn bảng về điểm đến
Hình 3 Quét chỉ mục theo cụm trên bảng nguồn
Chèn bằng chỉ mục
Sau đó, chúng ta tạo một chỉ mục trên bảng đích bằng cách sử dụng DDL trong Liệt kê 3. Khi chúng ta lặp lại câu lệnh trong Liệt kê 2 sau khi cắt bớt bảng đích, chúng ta thấy một kế hoạch thực thi hơi khác (Plan ID 593 được hiển thị trong Hình 4). Chúng tôi vẫn thấy Bảng chèn nhưng nó chỉ đóng góp 58% chi phí của truy vấn. Các động lực thực thi bị sai lệch một chút với sự ra đời của một loại và một Chèn chỉ mục. Về cơ bản những gì đang xảy ra là SQL Server phải giới thiệu các hàng tương ứng trên chỉ mục khi các bản ghi mới được giới thiệu trong bảng.
-- LISTING 3 Create Index on Destination Table CREATE NONCLUSTERED INDEX [IX_Sales_Invoices_ConfirmedDeliveryTime] ON [Sales].[Invoices1] ( [ConfirmedDeliveryTime] ASC ) INCLUDE ( [ConfirmedReceivedBy]) WITH (PAD_INDEX = OFF , STATISTICS_NORECOMPUTE = OFF , SORT_IN_TEMPDB = OFF , DROP_EXISTING = OFF , ONLINE = OFF , ALLOW_ROW_LOCKS = ON , ALLOW_PAGE_LOCKS = ON) ON [USERDATA] GO
Hình 4 Kế hoạch thực hiện 593
Nhìn sâu hơn
Chúng tôi có thể kiểm tra chi tiết của cả hai kế hoạch và xem các yếu tố mới này làm leo thang thời gian thực hiện tuyên bố như thế nào. Kế hoạch 593 bổ sung thêm 300 mili giây vào Khoảng thời gian trung bình của câu lệnh. Dưới khối lượng công việc nặng nề trong môi trường sản xuất, sự khác biệt này có thể là đáng kể.
Bật IO THỐNG KÊ khi thực hiện câu lệnh chèn chỉ một lần trong cả hai trường hợp - với Chỉ mục trên bảng đích và không có chỉ mục trên bảng Đích - cũng cho thấy rằng nhiều công việc hơn được thực hiện về mặt IO lôgic khi chèn các hàng trong bảng có chỉ mục.
Hình 5 Chi tiết về Kế hoạch Thực thi 563
Hình 4 Chi tiết Kế hoạch Thực hiện 593
Không có chỉ mục:Đầu ra với IO STATISTICS được bật:
Bảng 'Hóa đơn1'. Số lượt quét là 0, số lần đọc logic 78372 , đọc vật lý 0, đọc trước 0, đọc logic 0, đọc vật lý 0, đọc trước lob 0, đọc trước 0.
Bảng "Hóa đơn". Số lượt quét 1, số lần đọc logic 11400, đọc vật lý 0, đọc trước đọc 0, đọc lôgic 0, ghi lôgic vật lý 0, đọc trước hành động đọc 0.
(70510 hàng bị ảnh hưởng)
Chỉ mục:Đầu ra với THỐNG KÊ IO Được bật:
Bảng 'Hóa đơn1'. Số lượt quét là 0, số lần đọc logic 81119 , đọc vật lý 0, đọc trước 0, đọc logic 0, đọc vật lý 0, đọc trước lob 0, đọc trước 0.
Bảng 'Bàn làm việc'. Quét đếm 0, đọc lôgic 0, đọc vật lý 0, đọc trước đọc 0, đọc lôgic 0, đọc lôgic vật lý 0, đọc trước lôgic đọc 0.
Bảng "Hóa đơn". Số lượt quét 1, số lần đọc logic 11400 , đọc vật lý 0, đọc trước 0, đọc logic 0, đọc vật lý 0, đọc trước lob 0, đọc trước 0.
(70510 hàng bị ảnh hưởng)
Thông tin bổ sung
Microsoft và các nguồn khác cung cấp các tập lệnh để kiểm tra môi trường sản xuất chỉ mục và xác định các tình huống như:
- Chỉ mục dự phòng - Các chỉ mục bị trùng lặp
- Thiếu chỉ mục - Các chỉ số có thể cải thiện hiệu suất dựa trên khối lượng công việc
- Hàng đống - Các bảng không có chỉ mục được phân cụm
- Bảng được lập chỉ mục quá mức - Các bảng có nhiều chỉ mục hơn cột
- Sử dụng Chỉ mục - Số lượt tìm kiếm, quét và tra cứu các chỉ mục
Mục 2, 3 và 5 liên quan nhiều hơn đến tác động hiệu suất đối với lượt đọc, trong khi mục 1 và 4 liên quan đến tác động đến hiệu suất đối với lượt viết. Danh sách 4 và 5 là hai ví dụ về các truy vấn có sẵn công khai này.
-- LISTING 4 Check Redundant Indexes
;WITH INDEXCOLUMNS AS(
SELECT DISTINCT
SCHEMA_NAME (O.SCHEMA_ID) AS 'SCHEMANAME'
, OBJECT_NAME(O.OBJECT_ID) AS TABLENAME
,I.NAME AS INDEXNAME, O.OBJECT_ID,I.INDEX_ID,I.TYPE
,(SELECT CASE KEY_ORDINAL WHEN 0 THEN NULL ELSE '['+COL_NAME(K.OBJECT_ID,COLUMN_ID) +']' END AS [DATA()]
FROM SYS.INDEX_COLUMNS AS K WHERE K.OBJECT_ID = I.OBJECT_ID AND K.INDEX_ID = I.INDEX_ID
ORDER BY KEY_ORDINAL, COLUMN_ID FOR XML PATH('')) AS COLS
FROM SYS.INDEXES AS I INNER JOIN SYS.OBJECTS O ON I.OBJECT_ID =O.OBJECT_ID
INNER JOIN SYS.INDEX_COLUMNS IC ON IC.OBJECT_ID =I.OBJECT_ID AND IC.INDEX_ID =I.INDEX_ID
INNER JOIN SYS.COLUMNS C ON C.OBJECT_ID = IC.OBJECT_ID AND C.COLUMN_ID = IC.COLUMN_ID
WHERE I.OBJECT_ID IN (SELECT OBJECT_ID FROM SYS.OBJECTS WHERE TYPE ='U') AND I.INDEX_ID <>0 AND I.TYPE <>3 AND I.TYPE <>6
GROUP BY O.SCHEMA_ID,O.OBJECT_ID,I.OBJECT_ID,I.NAME,I.INDEX_ID,I.TYPE
)
SELECT
IC1.SCHEMANAME,IC1.TABLENAME,IC1.INDEXNAME,IC1.COLS AS INDEXCOLS,IC2.INDEXNAME AS REDUNDANTINDEXNAME, IC2.COLS AS REDUNDANTINDEXCOLS
FROM INDEXCOLUMNS IC1
JOIN INDEXCOLUMNS IC2 ON IC1.OBJECT_ID = IC2.OBJECT_ID
AND IC1.INDEX_ID <> IC2.INDEX_ID
AND IC1.COLS <> IC2.COLS
AND IC2.COLS LIKE REPLACE(IC1.COLS,'[','[[]') + ' %'
ORDER BY 1,2,3,5;
-- LISTING 5 Check Indexes Usage
SELECT O.NAME AS TABLE_NAME
, I.NAME AS INDEX_NAME
, S.USER_SEEKS
, S.USER_SCANS
, S.USER_LOOKUPS
, S.USER_UPDATES
FROM SYS.DM_DB_INDEX_USAGE_STATS S
INNER JOIN SYS.INDEXES I
ON I.INDEX_ID=S.INDEX_ID
AND S.OBJECT_ID = I.OBJECT_ID
INNER JOIN SYS.OBJECTS O
ON S.OBJECT_ID = O.OBJECT_ID
INNER JOIN SYS.SCHEMAS C
ON O.SCHEMA_ID = C.SCHEMA_ID;
Kết luận
Chúng tôi đã chỉ ra rằng, bằng cách sử dụng Query Store, khối lượng công việc bổ sung với một chỉ mục có thể giới thiệu trong kế hoạch thực thi của một câu lệnh chèn mẫu. Trong quá trình sản xuất, các chỉ mục quá mức và dư thừa có thể có tác động tiêu cực đến hiệu suất, đặc biệt là trong cơ sở dữ liệu dành cho khối lượng công việc OLTP. Điều quan trọng là sử dụng các tập lệnh và công cụ có sẵn để kiểm tra các chỉ mục và xác định xem chúng thực sự giúp ích hay làm tổn hại đến hiệu suất.
Công cụ hữu ích:
dbForge Index Manager - phần bổ trợ SSMS tiện dụng để phân tích trạng thái của chỉ mục SQL và khắc phục sự cố với phân mảnh chỉ mục.
