Các cột được tính toán phù hợp

Hầu hết mọi vấn đề về hiệu suất liên quan đến cột được tính toán mà tôi gặp phải trong nhiều năm đều có một (hoặc nhiều) nguyên nhân gốc rễ sau:

Giới hạn triển khai
Thiếu hỗ trợ mô hình chi phí trong trình tối ưu hóa truy vấn
Mở rộng định nghĩa cột được tính toán trước khi bắt đầu tối ưu hóa

Ví dụ về giới hạn triển khai không thể tạo chỉ mục được lọc trên cột được tính toán (ngay cả khi vẫn tồn tại). Chúng ta không thể làm gì nhiều về hạng mục vấn đề này; chúng tôi phải sử dụng các giải pháp thay thế trong khi chờ đợi các cải tiến sản phẩm đến.

Việc thiếu trình tối ưu hóa hỗ trợ mô hình chi phí nghĩa là SQL Server ấn định một khoản chi phí cố định nhỏ cho các phép tính vô hướng, bất kể mức độ phức tạp hoặc cách triển khai. Do đó, máy chủ thường quyết định tính toán lại giá trị cột được tính toán được lưu trữ thay vì đọc trực tiếp giá trị đã tồn tại hoặc được lập chỉ mục. Điều này đặc biệt khó khăn khi biểu thức được tính toán đắt tiền, chẳng hạn như khi nó liên quan đến việc gọi một hàm vô hướng do người dùng xác định.

Các vấn đề xung quanh mở rộng định nghĩa tham gia nhiều hơn một chút và có tác động trên phạm vi rộng.

Các vấn đề khi mở rộng cột được tính toán

SQL Server thường mở rộng các cột được tính toán thành các định nghĩa cơ bản của chúng trong giai đoạn ràng buộc của quá trình chuẩn hóa truy vấn. Đây là giai đoạn rất sớm trong quá trình biên dịch truy vấn, trước khi đưa ra bất kỳ quyết định lựa chọn kế hoạch nào (kể cả kế hoạch tầm thường).

Về lý thuyết, việc thực hiện mở rộng sớm có thể cho phép tối ưu hóa mà nếu không sẽ bị bỏ qua. Ví dụ:trình tối ưu hóa có thể áp dụng các đơn giản hóa cung cấp thông tin khác trong truy vấn và siêu dữ liệu (ví dụ:ràng buộc). Đây là cùng một kiểu lập luận dẫn đến việc mở rộng định nghĩa chế độ xem (trừ khi NOEXPAND gợi ý được sử dụng).

Sau đó trong quá trình biên dịch (nhưng vẫn còn trước khi một kế hoạch tầm thường được xem xét), trình tối ưu hóa sẽ tìm cách đối sánh các biểu thức với các cột được tính toán được lập chỉ mục hoặc liên tục. Vấn đề là các hoạt động của trình tối ưu hóa trong thời gian chờ đợi có thể đã thay đổi các biểu thức được mở rộng khiến việc đối sánh ngược lại không còn khả thi.

Khi điều này xảy ra, kế hoạch thực thi cuối cùng có vẻ như trình tối ưu hóa đã bỏ lỡ một cơ hội "hiển nhiên" để sử dụng một cột được tính toán được duy trì hoặc được lập chỉ mục. Có một số chi tiết trong kế hoạch thực thi có thể giúp xác định nguyên nhân, khiến đây trở thành một vấn đề có thể gây khó chịu cần gỡ lỗi và khắc phục.

Đối sánh các biểu thức với các cột được tính toán

Điều cần đặc biệt rõ ràng là có hai quy trình riêng biệt ở đây:

Mở rộng sớm các cột được tính toán; và
Sau đó, các nỗ lực so khớp các biểu thức với các cột được tính toán.

Đặc biệt, lưu ý rằng sau này bất kỳ biểu thức truy vấn nào cũng có thể được so khớp với một cột được tính toán phù hợp, không chỉ các biểu thức phát sinh từ việc mở rộng các cột được tính toán.

Đối sánh biểu thức cột được tính toán có thể cho phép cải tiến kế hoạch ngay cả khi không thể sửa đổi văn bản của truy vấn ban đầu. Ví dụ:việc tạo một cột được tính toán để khớp với một biểu thức truy vấn đã biết cho phép trình tối ưu hóa sử dụng thống kê và chỉ mục được liên kết với cột được tính toán. Tính năng này về mặt khái niệm tương tự như đối sánh chế độ xem được lập chỉ mục trong Phiên bản Doanh nghiệp. Đối sánh cột được tính toán có chức năng trong tất cả các phiên bản.

Từ quan điểm thực tế, kinh nghiệm của riêng tôi là kết hợp các biểu thức truy vấn chung với các cột được tính toán thực sự có thể mang lại hiệu suất, hiệu quả và sự ổn định của kế hoạch thực thi. Mặt khác, tôi hiếm khi (nếu đã từng) thấy việc mở rộng cột được tính toán là đáng giá. Nó dường như không bao giờ mang lại bất kỳ tối ưu hóa hữu ích nào.

Sử dụng cột được tính toán

Các cột được tính toán không phải vẫn tồn tại hoặc được lập chỉ mục có sử dụng hợp lệ. Ví dụ:chúng có thể hỗ trợ thống kê tự động nếu cột là xác định và chính xác (không có phần tử dấu chấm động). Chúng cũng có thể được sử dụng để tiết kiệm không gian lưu trữ (với chi phí sử dụng bộ xử lý thời gian chạy thêm một chút). Ví dụ cuối cùng, chúng có thể cung cấp một cách gọn gàng để đảm bảo rằng một phép tính đơn giản luôn được thực hiện chính xác, thay vì được viết rõ ràng trong các truy vấn mỗi lần.

Vẫn tồn tại các cột được tính toán đã được thêm vào sản phẩm một cách cụ thể để cho phép các chỉ mục được tạo trên các cột xác định nhưng "không chính xác" (dấu phẩy động). Theo kinh nghiệm của tôi, mục đích sử dụng này tương đối hiếm. Có thể điều này chỉ đơn giản là vì tôi không gặp nhiều dữ liệu dấu phẩy động.

Các chỉ mục dấu phẩy động sang một bên, các cột tồn tại khá phổ biến. Ở một mức độ nào đó, điều này có thể là do người dùng thiếu kinh nghiệm cho rằng một cột được tính toán phải luôn được duy trì trước khi nó có thể được lập chỉ mục. Những người dùng có kinh nghiệm hơn có thể sử dụng các cột liên tục chỉ vì họ nhận thấy rằng hiệu suất có xu hướng tốt hơn theo cách đó.

Đã lập chỉ mục Các cột được tính toán (tồn tại hoặc không) có thể được sử dụng để cung cấp thứ tự và một phương pháp truy cập hiệu quả. Nó có thể hữu ích khi lưu trữ một giá trị được tính toán trong một chỉ mục mà không cần duy trì nó trong bảng cơ sở. Tương tự, các cột được tính toán phù hợp cũng có thể được bao gồm trong các chỉ mục thay vì là các cột chính.

Hiệu suất kém

Nguyên nhân chính của hiệu suất kém là do lỗi đơn giản trong việc sử dụng giá trị cột được lập chỉ mục hoặc được tính toán liên tục như mong đợi. Tôi đã không đếm được số lượng câu hỏi mà tôi đã có trong nhiều năm hỏi tại sao trình tối ưu hóa lại chọn một kế hoạch thực thi tồi tệ khi một kế hoạch rõ ràng tốt hơn bằng cách sử dụng cột được lập chỉ mục hoặc được tính toán liên tục tồn tại.

Nguyên nhân chính xác trong mỗi trường hợp khác nhau, nhưng hầu như luôn luôn là một quyết định dựa trên chi phí sai lầm (vì các đại lượng vô hướng được ấn định một chi phí cố định thấp); hoặc không thể khớp biểu thức mở rộng trở lại cột hoặc chỉ mục được tính toán liên tục.

Những thất bại đối đầu đặc biệt thú vị với tôi, bởi vì chúng thường liên quan đến những tương tác phức tạp với các tính năng của động cơ trực giao. Thông thường, việc không thể "khớp lại" để lại một biểu thức (chứ không phải một cột) ở một vị trí trong cây truy vấn nội bộ, ngăn không cho một quy tắc tối ưu hóa quan trọng đối sánh. Trong cả hai trường hợp, kết quả là như nhau:một kế hoạch thực hiện dưới mức tối ưu.

Bây giờ, tôi nghĩ thật công bằng khi nói rằng mọi người thường lập chỉ mục hoặc duy trì một cột được tính toán với kỳ vọng mạnh mẽ rằng giá trị được lưu trữ sẽ thực sự được sử dụng. Nó có thể gây sốc khi thấy SQL Server tính toán lại biểu thức cơ bản mỗi lần, trong khi bỏ qua giá trị được lưu trữ được cố ý cung cấp. Mọi người không phải lúc nào cũng quan tâm nhiều đến các tương tác nội bộ và thiếu sót mô hình chi phí dẫn đến kết quả không mong muốn. Ngay cả khi các giải pháp thay thế tồn tại, chúng đòi hỏi thời gian, kỹ năng và nỗ lực để khám phá và kiểm tra.

Tóm lại:nhiều người chỉ đơn giản thích SQL Server sử dụng giá trị được lập chỉ mục hoặc cố định. Luôn luôn.

Một tùy chọn mới

Về mặt lịch sử, không có cách nào để buộc SQL Server luôn sử dụng giá trị được lưu trữ (không tương đương với NOEXPAND gợi ý cho các lượt xem). Có một số trường hợp mà hướng dẫn kế hoạch sẽ hoạt động, nhưng không phải lúc nào cũng có thể tạo ra hình dạng kế hoạch cần thiết ngay từ đầu và không phải tất cả các yếu tố và vị trí của kế hoạch đều có thể bị ép buộc (ví dụ:bộ lọc và tính toán tỷ lệ vô hướng).

Vẫn chưa có giải pháp gọn gàng, được ghi chép đầy đủ, nhưng bản cập nhật gần đây cho SQL Server 2016 đã cung cấp một cách tiếp cận mới thú vị. Nó áp dụng cho các phiên bản SQL Server 2016 được vá với ít nhất là Bản cập nhật tích lũy 2 cho SQL Server 2016 SP1 hoặc Bản cập nhật tích lũy 4 cho SQL Server 2016 RTM.

Bản cập nhật liên quan được ghi lại trong:Khắc phục:Không thể tạo lại phân vùng trực tuyến cho bảng có chứa cột phân vùng được tính toán trong SQL Server 2016

Như thường lệ với tài liệu hỗ trợ, điều này không cho biết chính xác những gì đã được thay đổi trong công cụ để giải quyết vấn đề. Nó chắc chắn trông không liên quan đến mối quan tâm hiện tại của chúng tôi, xét theo tiêu đề và mô tả. Tuy nhiên, bản sửa lỗi này giới thiệu cờ theo dõi mới được hỗ trợ 176 , được kiểm tra trong một phương pháp mã có tên là FDontExpandPersistedCC . Như tên phương pháp gợi ý, điều này ngăn không cho mở rộng cột được tính toán liên tục.

Có ba lưu ý quan trọng đối với điều này:

Cột được tính toán phải được tồn tại . Ngay cả khi được lập chỉ mục, cột cũng phải được duy trì.
Khớp lại từ các biểu thức truy vấn chung với các cột được tính toán liên tục bị tắt .
Tài liệu không mô tả chức năng của cờ theo dõi và không quy định nó cho bất kỳ mục đích sử dụng nào khác. Nếu bạn chọn sử dụng cờ theo dõi 176 để ngăn việc mở rộng các cột được tính toán liên tục, do đó, bạn sẽ tự chịu rủi ro.

Cờ theo dõi này có hiệu lực như một –T khởi động tùy chọn, ở cả phạm vi toàn cầu và phiên bằng cách sử dụng DBCC TRACEON và cho mỗi truy vấn với OPTION (QUERYTRACEON) .

Ví dụ

Đây là phiên bản đơn giản hóa của một câu hỏi (dựa trên một vấn đề trong thế giới thực) mà tôi đã trả lời trên Stack Exchange của Quản trị viên Cơ sở dữ liệu cách đây vài năm. Định nghĩa bảng bao gồm một cột được tính toán liên tục:

 TẠO BẢNG dbo.T (ID số nguyên IDENTITY NOT NULL, A varchar (20) NOT NULL, B varchar (20) NOT NULL, C varchar (20) NOT NULL, D date NULL, Computed AS A + '-' + B + '-' + C PERSISTED, CONSTRAINT PK_T_ID PRIMARY KEY CLUSTERED (ID),); GOINSERT dbo.T WITH (TABLOCKX) (A, B, C, D) CHỌN A =STR (SV. Số% 10, 2 ), B =STR (SV.number% 20, 2), C =STR (SV.number% 30, 2), D =DATEADD (DAY, 0 - SV.number, SYSUTCDATETIME ()) FROM master.dbo.spt_values NHƯ SVWHERE SV. [Type] =N'P ';

Truy vấn bên dưới trả về tất cả các hàng từ bảng theo một thứ tự cụ thể, đồng thời trả về giá trị tiếp theo của cột D theo thứ tự tương tự:

 SELECT T1.ID, T1.Computed, T1.D, NextD =(SELECT TOP (1) t2.D FROM dbo.T AS T2 WHERE T2.Computed =T1.Computed AND T2.D> T1.D ORDER THEO T2.D ASC) TỪ dbo.T AS T1ORDER BY T1.Computed, T1.D;

Một chỉ mục bao trùm rõ ràng để hỗ trợ việc sắp xếp và tra cứu cuối cùng trong truy vấn phụ là:

 TẠO CHỈ SỐ KHÔNG CHỈNH SỬA DUY NHẤT IX_T_Computed_D_IDON dbo.T (Tính, D, ID);

Kế hoạch thực thi do trình tối ưu hóa cung cấp thật đáng ngạc nhiên và đáng thất vọng:

Tìm kiếm Chỉ mục ở phía bên trong của Tham gia các vòng lặp lồng nhau dường như đều tốt. Tuy nhiên, việc quét và sắp xếp chỉ mục theo cụm ở đầu vào bên ngoài là không mong muốn. Thay vào đó, chúng tôi hy vọng sẽ thấy bản quét có thứ tự đối với chỉ mục không phân tán bao trùm của chúng tôi.

Chúng tôi có thể buộc trình tối ưu hóa sử dụng chỉ mục không phân biệt với gợi ý bảng:

 SELECT T1.ID, T1.Computed, T1.D, NextD =(SELECT TOP (1) t2.D FROM dbo.T AS T2 WHERE T2.Computed =T1.Computed AND T2.D> T1.D ORDER THEO T2.D ASC) TỪ dbo.T AS T1 VỚI (INDEX (IX_T_Computed_D_ID)) - Mới! ĐẶT HÀNG THEO T1.Computed, T1.D;

Kế hoạch thực hiện kết quả là:

Việc quét chỉ mục không phân biệt sẽ xóa Sắp xếp, nhưng thêm Tra cứu khóa! Các tra cứu trong kế hoạch mới này thật đáng ngạc nhiên, vì chỉ mục của chúng tôi chắc chắn bao gồm tất cả các cột cần thiết cho truy vấn.

Xem xét các thuộc tính của toán tử Tra cứu Khóa:

Vì một số lý do, trình tối ưu hóa đã quyết định rằng ba cột không được đề cập trong truy vấn cần được tìm nạp từ bảng cơ sở (vì chúng không có trong chỉ mục không phân biệt của chúng tôi theo thiết kế).

Xem xét kế hoạch thực thi, chúng tôi phát hiện ra rằng các cột được tra cứu là cần thiết cho Tìm kiếm chỉ mục bên trong:

Phần đầu tiên của vị từ tìm kiếm này tương ứng với tương quan T2.Computed = T1.Computed trong truy vấn ban đầu. Trình tối ưu hóa đã mở rộng định nghĩa của cả hai cột được tính toán, nhưng chỉ quản lý để khớp trở lại cột được tính toán được lập chỉ mục và tồn tại cho bí danh bên trong T1 . Rời khỏi T2 tham chiếu được mở rộng đã dẫn đến việc phía bên ngoài của phép nối cần cung cấp các cột của bảng cơ sở (A , B và C ) cần thiết để tính biểu thức đó cho mỗi hàng.

Đôi khi trong trường hợp này, có thể viết lại truy vấn này để sự cố biến mất (một tùy chọn được hiển thị trong câu trả lời cũ của tôi cho câu hỏi Stack Exchange). Sử dụng SQL Server 2016, chúng tôi cũng có thể thử cờ theo dõi 176 để ngăn các cột được tính toán được mở rộng:

 SELECT T1.ID, T1.Computed, T1.D, NextD =(SELECT TOP (1) t2.D FROM dbo.T AS T2 WHERE T2.Computed =T1.Computed AND T2.D> T1.D ORDER THEO T2.D ASC) TỪ dbo.T AS T1ORDER BY T1.Computed, T1.DOPTION (QUERYTRACEON 176); - Mới!

Kế hoạch thực thi hiện đã được cải thiện nhiều:

Kế hoạch thực thi này chỉ chứa các tham chiếu đến các cột được tính toán. Tính toán Scalars không có ích gì và sẽ bị xóa sạch nếu xung quanh nhà tối ưu hóa gọn gàng hơn một chút.

Điểm quan trọng là chỉ mục tối ưu hiện đã được sử dụng đúng cách, và Tra cứu Phân loại và Khoá đã bị loại bỏ. Tất cả bằng cách ngăn SQL Server làm điều gì đó mà chúng tôi không bao giờ mong đợi nó làm được ngay từ đầu (mở rộng một cột được tính toán được lập chỉ mục và tồn tại lâu dài).

Sử dụng LEAD

Câu hỏi Stack Exchange ban đầu được nhắm mục tiêu vào SQL Server 2008, nơi LEAD không có sẵn. Hãy để chúng tôi thử diễn đạt yêu cầu trên SQL Server 2016 bằng cú pháp mới hơn:

CHỌN T1.ID, T1.Computed, T1.D, NextD =LEAD (T1.D) HẾT (PHẦN THEO T1. LỆNH ĐƯỢC TÍNH THEO T1.D) TỪ dbo.T NHƯ T1ORDER BY T1.Computed;

Kế hoạch thực thi SQL Server 2016 là:

Hình dạng kế hoạch này khá điển hình cho chức năng cửa sổ chế độ hàng đơn giản. Một mục không mong đợi là toán tử Sắp xếp ở giữa. Nếu tập dữ liệu lớn, thì Sắp xếp này có thể có tác động lớn đến hiệu suất và việc sử dụng bộ nhớ.

Vấn đề, một lần nữa, là mở rộng cột được tính toán. Trong trường hợp này, một trong các biểu thức mở rộng nằm ở vị trí ngăn chặn logic của trình tối ưu hóa thông thường, đơn giản hóa việc Sắp xếp đi.

Đang thử chính xác cùng một truy vấn với cờ theo dõi 176:

 CHỌN T1.ID, T1.Computed, T1.D, NextD =LEAD (T1.D) HẾT (PHẦN THEO T1. LỆNH ĐƯỢC TÍNH THEO T1.D) TỪ dbo.T NHƯ T1ORDER BY T1.ComputedOPTION (QUERYTRACEON 176 );

Lập kế hoạch:

Sắp xếp đã biến mất như bình thường. Cũng xin lưu ý rằng truy vấn này đủ điều kiện cho một kế hoạch tầm thường, tránh tối ưu hóa hoàn toàn dựa trên chi phí.

Khớp biểu thức chung bị vô hiệu hóa

Một trong những lưu ý đã đề cập trước đó là cờ theo dõi 176 cũng vô hiệu hóa việc so khớp từ các biểu thức trong truy vấn nguồn với các cột được tính toán liên tục.

Để minh họa, hãy xem xét phiên bản sau của truy vấn mẫu. LEAD tính toán đã bị xóa và các tham chiếu đến cột được tính trong SELECT và ORDER BY mệnh đề đã được thay thế bằng các biểu thức bên dưới. Chạy nó trước mà không có dấu vết cờ 176:

 SELECT T1.ID, Computed =T1.A + '-' + T1.B + '-' + T1.C, T1.DFROM dbo.T AS T1ORDER BY T1.A + '-' + T1.B + '-' + T1.C;

Các biểu thức được so khớp với cột được tính toán liên tục và kế hoạch thực thi là một quá trình quét theo thứ tự đơn giản của chỉ mục không phân biệt:

Compute Scalar ở đó một lần nữa chỉ là rác kiến trúc còn sót lại.

Bây giờ hãy thử truy vấn tương tự với cờ theo dõi 176 được bật:

 SELECT T1.ID, Computed =T1.A + '-' + T1.B + '-' + T1.C, T1.DFROM dbo.T AS T1ORDER BY T1.A + '-' + T1.B + '-' + T1.COPTION (QUERYTRACEON 176); - Mới!

Kế hoạch thực hiện mới là:

Quét chỉ mục không phân tán đã được thay thế bằng Quét chỉ mục theo cụm. Tính toán vô hướng đánh giá biểu thức và sắp xếp thứ tự theo kết quả. Không có khả năng so khớp các biểu thức với các cột được tính liên tục, trình tối ưu hóa không thể sử dụng giá trị duy trì hoặc chỉ mục không phân biệt.

Lưu ý rằng giới hạn đối sánh biểu thức chỉ áp dụng cho vẫn tiếp tục các cột được tính toán khi cờ theo dõi 176 đang hoạt động. Nếu chúng tôi làm cho cột đã tính được lập chỉ mục nhưng không tồn tại, thì đối sánh biểu thức hoạt động chính xác.

Để loại bỏ thuộc tính dai dẳng, trước tiên chúng ta cần loại bỏ chỉ mục không phân tán. Sau khi thay đổi được thực hiện, chúng tôi có thể đặt chỉ mục trở lại thẳng hàng (vì biểu thức là xác định và chính xác):

 DROP INDEX IX_T_Computed_D_ID ON dbo.T; GOALTER TABLE dbo.TALTER COLUMN ComputedDROP PERSISTED; GOCREATE UNIQUE NONCLUSTERED INDEX IX_T_Computed_D_IDON dbo.T (Computed, D, ID);

Trình tối ưu hóa hiện không gặp vấn đề gì khi khớp biểu thức truy vấn với cột được tính toán khi cờ theo dõi 176 đang hoạt động:

 - Cột đã tính không còn tồn tại-- nhưng vẫn được lập chỉ mục. TF 176 hoạt động.SELECT T1.ID, Tính =T1.A + '-' + T1.B + '-' + T1.C, T1.DFROM dbo.T AS T1ORDER BY T1.A + '-' + T1. B + '-' + T1.COPTION (QUERYTRACEON 176);

Kế hoạch thực thi quay trở lại quá trình quét chỉ mục không phân tán tối ưu mà không có sắp xếp:

Tóm lại:Cờ theo dõi 176 ngăn chặn việc mở rộng cột được tính toán liên tục. Như một tác dụng phụ, nó cũng ngăn chỉ đối sánh biểu thức truy vấn với các cột được tính toán liên tục.

Siêu dữ liệu lược đồ chỉ được tải một lần trong giai đoạn liên kết. Cờ theo dõi 176 ngăn không cho mở rộng nên định nghĩa cột đã tính không được tải vào thời điểm đó. Đối sánh biểu thức thành cột sau này không thể hoạt động nếu không có định nghĩa cột được tính toán để đối sánh.

Tải siêu dữ liệu ban đầu mang đến tất cả các cột, không chỉ những cột được tham chiếu trong truy vấn (tối ưu hóa đó được thực hiện sau đó). Điều này làm cho tất cả các cột được tính toán có sẵn để đối sánh, đây thường là một điều tốt. Thật không may, nếu một trong các cột được tính toán đã tải chứa một hàm vô hướng do người dùng xác định, thì sự hiện diện của nó sẽ vô hiệu hóa tính song song cho toàn bộ truy vấn ngay cả khi cột có vấn đề không được sử dụng. Cờ theo dõi 176 cũng có thể giúp giải quyết vấn đề này, nếu cột được đề cập vẫn tồn tại. Bằng cách không tải định nghĩa, một hàm vô hướng do người dùng xác định sẽ không bao giờ xuất hiện, do đó tính năng song song không bị vô hiệu hóa.

Lời kết

Đối với tôi, dường như thế giới SQL Server là một nơi tốt hơn nếu trình tối ưu hóa được xử lý vẫn tồn tại hoặc được lập chỉ mục các cột được tính toán giống như các cột thông thường. Trong hầu hết các trường hợp, điều này sẽ phù hợp hơn với mong đợi của nhà phát triển so với sự sắp xếp hiện tại. Việc mở rộng các cột đã tính thành các biểu thức cơ bản của chúng và sau đó cố gắng khớp chúng lại sẽ không thành công trong thực tế như lý thuyết có thể đề xuất.

Cho đến khi SQL Server cung cấp hỗ trợ cụ thể để ngăn chặn việc mở rộng cột được tính toán được lập chỉ mục hoặc liên tục, cờ theo dõi mới 176 là một tùy chọn hấp dẫn cho người dùng SQL Server 2016, mặc dù là một tùy chọn không hoàn hảo. Hơi đáng tiếc là nó vô hiệu hóa kết hợp biểu thức chung như một tác dụng phụ. Cũng rất tiếc khi cột được tính toán phải được duy trì khi được lập chỉ mục. Sau đó, có nguy cơ sử dụng cờ theo dõi cho mục đích khác với mục đích đã được lập thành văn bản của nó để xem xét.

Công bằng mà nói, phần lớn các vấn đề với các truy vấn cột được tính toán cuối cùng có thể được giải quyết theo những cách khác, nếu có đủ thời gian, nỗ lực và chuyên môn. Mặt khác, cờ theo dõi 176 thường có vẻ hoạt động giống như ma thuật. Như họ nói, sự lựa chọn là của bạn.

Để kết thúc, đây là một số vấn đề cột được tính toán thú vị được hưởng lợi từ cờ theo dõi 176:

Chỉ mục cột được tính toán không được sử dụng
Cột được tính PERSISTED không được sử dụng trong phân vùng hàm cửa sổ
Cột được tính toán liên tục gây ra quá trình quét
Chỉ mục cột được tính toán không được sử dụng với MAX kiểu dữ liệu
Vấn đề nghiêm trọng về hiệu suất với các cột và liên kết được tính toán liên tục
Tại sao SQL Server lại "Tính vô hướng" khi tôi CHỌN một cột được tính liên tục?
Cột Cơ sở được sử dụng thay vì cột được tính toán liên tục theo công cụ
Cột được tính toán với UDF vô hiệu hóa tính năng song song đối với các truy vấn trên cột * khác *