Bài viết này là bài thứ tư trong loạt bài về ngưỡng tối ưu hóa. Loạt bài này bao gồm nhóm và tổng hợp dữ liệu, giải thích các thuật toán khác nhau mà SQL Server có thể sử dụng và mô hình chi phí giúp nó lựa chọn giữa các thuật toán. Trong bài viết này, tôi tập trung vào các cân nhắc về tính song song. Tôi đề cập đến các chiến lược song song khác nhau mà SQL Server có thể sử dụng, các ngưỡng để lựa chọn giữa một kế hoạch nối tiếp và song song và logic chi phí mà SQL Server áp dụng bằng cách sử dụng một khái niệm được gọi là mức độ song song cho chi phí (DOP để tính chi phí).
Tôi sẽ tiếp tục sử dụng bảng dbo.Orders trong cơ sở dữ liệu mẫu PerformanceV3 trong các ví dụ của tôi. Trước khi chạy các ví dụ trong bài viết này, hãy chạy mã sau để loại bỏ một vài chỉ mục không cần thiết:
DROP INDEX NẾU CÓ idx_nc_sid_od_cid TRÊN dbo.Orders; DROP INDEX NẾU CÓ idx_unc_od_oid_i_cid_eid ON dbo.Orders;
Hai chỉ mục duy nhất nên được để lại trên bảng này là idx_cl_od (nhóm với orderdate làm khóa) và PK_Orders (không gộp với orderid làm khóa).
Chiến lược song song
Bên cạnh việc cần lựa chọn giữa các chiến lược nhóm và tổng hợp khác nhau (Tổng hợp luồng được sắp xếp trước, Tổng hợp theo thứ tự + Tổng hợp luồng, Tổng hợp băm), SQL Server cũng cần phải chọn đi theo kế hoạch nối tiếp hay song song. Trên thực tế, nó có thể lựa chọn giữa nhiều chiến lược song song khác nhau. SQL Server sử dụng logic chi phí dẫn đến các ngưỡng tối ưu hóa mà trong các điều kiện khác nhau làm cho một chiến lược được ưu tiên hơn các chiến lược khác. Chúng ta đã thảo luận sâu về logic chi phí mà SQL Server sử dụng trong các kế hoạch nối tiếp trong các phần trước của loạt bài này. Trong phần này, tôi sẽ giới thiệu một số chiến lược song song mà SQL Server có thể sử dụng để xử lý nhóm và tổng hợp. Ban đầu, tôi sẽ không đi sâu vào chi tiết của logic chi phí, thay vì chỉ mô tả các tùy chọn có sẵn. Ở phần sau của bài viết, tôi sẽ giải thích cách hoạt động của các công thức tính giá thành và một yếu tố quan trọng trong các công thức đó được gọi là DOP để tính chi phí.
Như bạn sẽ học ở phần sau, SQL Server tính đến số lượng CPU logic trong máy trong công thức tính giá của nó cho các kế hoạch song song. Trong các ví dụ của tôi, trừ khi tôi nói khác, tôi giả sử hệ thống đích có 8 CPU logic. Nếu bạn muốn thử các ví dụ mà tôi sẽ cung cấp, để có được các gói và giá trị chi phí giống như tôi làm, bạn cũng cần chạy mã trên máy có 8 CPU logic. Nếu máy của bạn tình cờ có một số lượng CPU khác nhau, bạn có thể mô phỏng một máy có 8 CPU — vì mục đích chi phí — như vậy:
DBCC OPTIMIZER_WHATIF (CPU, 8);
Mặc dù công cụ này không được tài liệu hóa và hỗ trợ chính thức, nhưng nó khá thuận tiện cho các mục đích nghiên cứu và học tập.
Bảng Đơn hàng trong cơ sở dữ liệu mẫu của chúng tôi có 1.000.000 hàng với ID đơn đặt hàng trong phạm vi từ 1 đến 1.000.000. Để chứng minh ba chiến lược song song khác nhau để nhóm và tổng hợp, tôi sẽ lọc các đơn hàng trong đó ID đơn hàng lớn hơn hoặc bằng 300001 (700.000 kết quả phù hợp) và nhóm dữ liệu theo ba cách khác nhau (theo custid [20.000 nhóm trước khi lọc], bởi empid [500 nhóm] và shipperid [5 nhóm]) và tính toán số lượng đơn đặt hàng cho mỗi nhóm.
Sử dụng mã sau để tạo chỉ mục nhằm hỗ trợ các truy vấn được nhóm lại:
TẠO CHỈ SỐ idx_oid_i_eid TRÊN dbo.Orders (orderid) BAO GỒM (empid); TẠO CHỈ SỐ idx_oid_i_sid TRÊN dbo.Orders (orderid) BAO GỒM (shipperid); TẠO CHỈ SỐ idx_oid_i_cid TRÊN dbo.Orders (orErid) INCLUD (orErid) trước>Các truy vấn sau thực hiện lọc và nhóm đã nói ở trên:
- Truy vấn 1:Serial SELECT custid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =300001GROUP BY custidOPTION (MAXDOP 1); - Truy vấn 2:Parallel, not local / global SELECT custid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =300001GROUP BY custid; - Truy vấn 3:Local song song toàn cục song song SELECT empid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =300001GROUP BY empid; - Truy vấn 4:Nối tiếp toàn cục song song cục bộ SELECT shipperid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =300001GROUP BY shipperid;Lưu ý rằng Truy vấn 1 và Truy vấn 2 giống nhau (cả hai đều được nhóm theo custid), chỉ có cái trước bắt buộc kế hoạch nối tiếp và cái sau nhận được kế hoạch song song trên máy có 8 CPU. Tôi sử dụng hai ví dụ này để so sánh các chiến lược nối tiếp và song song cho cùng một truy vấn.
Hình 1 cho thấy các kế hoạch ước tính cho cả bốn truy vấn:
Hình 1:Các chiến lược song song
Hiện tại, đừng lo lắng về các giá trị chi phí được hiển thị trong hình và việc đề cập đến thuật ngữ DOP cho chi phí. Tôi sẽ nói về những điều đó sau. Trước tiên, hãy tập trung vào việc hiểu các chiến lược và sự khác biệt giữa chúng.
Chiến lược được sử dụng trong kế hoạch nối tiếp cho Truy vấn 1 sẽ quen thuộc với bạn từ các phần trước của loạt bài này. Kế hoạch lọc các đơn đặt hàng có liên quan bằng cách sử dụng tìm kiếm trong chỉ mục bao gồm bạn đã tạo trước đó. Sau đó, với số lượng hàng ước tính được nhóm và tổng hợp, trình tối ưu hóa ưu tiên chiến lược Hash Aggregate hơn chiến lược Sort + Stream Aggregate.
Kế hoạch cho Truy vấn 2 sử dụng một chiến lược song song đơn giản chỉ sử dụng một toán tử tổng hợp. Toán tử Tìm kiếm chỉ mục song song phân phối các gói hàng đến các luồng khác nhau theo kiểu vòng tròn. Mỗi gói hàng có thể chứa nhiều ID khách hàng riêng biệt. Để một toán tử tổng hợp có thể tính đúng số nhóm cuối cùng, tất cả các hàng thuộc cùng một nhóm phải được xử lý bởi cùng một luồng. Vì lý do này, toán tử trao đổi Parallelism (Repartition Streams) được sử dụng để phân vùng lại các luồng theo tập hợp nhóm (custid). Cuối cùng, toán tử trao đổi Song song (Gom Streams) được sử dụng để tập hợp các luồng từ nhiều luồng thành một luồng kết quả duy nhất.
Các kế hoạch cho Truy vấn 3 và Truy vấn 4 sử dụng chiến lược song song phức tạp hơn. Các kế hoạch bắt đầu tương tự như kế hoạch cho Truy vấn 2 trong đó toán tử Tìm kiếm Chỉ mục song song phân phối các gói hàng cho các luồng khác nhau. Sau đó, công việc tổng hợp được thực hiện theo hai bước:một toán tử tổng hợp cục bộ nhóm và tổng hợp các hàng của luồng hiện tại (thông báo thành viên kết quả partagg1004) và toán tử tổng hợp thứ hai nhóm trên toàn cầu và tổng hợp kết quả của tổng hợp cục bộ (lưu ý globalagg1005 thành viên kết quả). Mỗi bước trong số hai bước tổng hợp — cục bộ và toàn cầu — có thể sử dụng bất kỳ thuật toán tổng hợp nào mà tôi đã mô tả trước đó trong loạt bài này. Cả hai kế hoạch cho Truy vấn 3 và Truy vấn 4 đều bắt đầu với Tổng hợp băm cục bộ và tiếp tục với Tổng sắp xếp + Luồng toàn cầu. Sự khác biệt giữa hai bước này là trước đây sử dụng song song trong cả hai bước (do đó, trao đổi Luồng phân vùng lại được sử dụng giữa hai và trao đổi Luồng phân vùng sau tổng hợp toàn cục) và sau đó xử lý tổng hợp cục bộ trong một vùng song song và toàn cầu tổng hợp trong một vùng nối tiếp (do đó, trao đổi Gather Streams được sử dụng giữa hai).
Khi thực hiện nghiên cứu của bạn về tối ưu hóa truy vấn nói chung và đặc biệt là tính song song, bạn nên làm quen với các công cụ cho phép bạn kiểm soát các khía cạnh tối ưu hóa khác nhau để xem tác dụng của chúng. Bạn đã biết cách bắt buộc kế hoạch nối tiếp (với gợi ý MAXDOP 1) và cách mô phỏng một môi trường, vì mục đích chi phí, có một số CPU logic nhất định (DBCC OPTIMIZER_WHATIF, với tùy chọn CPU). Một công cụ hữu ích khác là gợi ý truy vấn ENABLE_PARALLEL_PLAN_PREFERENCE (được giới thiệu trong SQL Server 2016 SP1 CU2), tối đa hóa tính song song. Ý tôi muốn nói ở đây là nếu một kế hoạch song song được hỗ trợ cho truy vấn, thì tính năng song song sẽ được ưu tiên trong tất cả các phần của kế hoạch có thể được xử lý song song, như thể nó miễn phí. Ví dụ, quan sát trong Hình 1 rằng theo mặc định, kế hoạch cho Truy vấn 4 xử lý tổng cục bộ trong một vùng nối tiếp và tổng thể toàn cục trong một vùng song song. Đây là cùng một truy vấn, chỉ lần này với gợi ý truy vấn ENABLE_PARALLEL_PLAN_PREFERENCE được áp dụng (chúng tôi sẽ gọi nó là Truy vấn 5):
SELECT shipperid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =300001GROUP BY shipperidOPTION (SỬ DỤNG GỢI Ý ('ENABLE_PARALLEL_PLAN_PREFERENCE'));Kế hoạch cho Truy vấn 5 được thể hiện trong Hình 2:
Hình 2:Tối đa hóa tính song song
Lưu ý rằng lần này cả tổng cục bộ và tổng thể toàn cầu đều được xử lý trong các vùng song song.
Lựa chọn kế hoạch nối tiếp / song song
Nhớ lại rằng trong quá trình tối ưu hóa truy vấn, SQL Server tạo ra nhiều kế hoạch ứng viên và chọn một kế hoạch có chi phí thấp nhất trong số các kế hoạch mà nó tạo ra. Thuật ngữ chi phí hơi nhầm lẫn vì theo ước tính, kế hoạch ứng viên có chi phí thấp nhất được cho là kế hoạch có thời gian chạy thấp nhất, không phải là kế hoạch có lượng tài nguyên được sử dụng tổng thể thấp nhất. Ví dụ:giữa một kế hoạch ứng cử viên nối tiếp và một kế hoạch song song được tạo ra cho cùng một truy vấn, kế hoạch song song có thể sẽ sử dụng nhiều tài nguyên hơn, vì nó cần sử dụng các toán tử trao đổi đồng bộ hóa các luồng (phân phối, phân vùng lại và thu thập các luồng). Tuy nhiên, để kế hoạch song song cần ít thời gian hơn để hoàn thành việc chạy so với kế hoạch nối tiếp, mức tiết kiệm đạt được khi thực hiện công việc với nhiều luồng cần nhiều hơn công việc bổ sung do các nhà khai thác trao đổi thực hiện. Và điều này cần được phản ánh bằng các công thức tính phí mà SQL Server sử dụng khi có liên quan đến tính song song. Không phải là một nhiệm vụ đơn giản để thực hiện chính xác!
Ngoài chi phí gói song song cần phải thấp hơn chi phí gói nối tiếp để được ưu tiên, chi phí của phương án kế hoạch nối tiếp cần phải lớn hơn hoặc bằng ngưỡng chi phí cho phương án song song . Đây là một tùy chọn cấu hình máy chủ được đặt thành 5 theo mặc định để ngăn các truy vấn với chi phí khá thấp được xử lý song song. Suy nghĩ ở đây là một hệ thống với một số lượng lớn các truy vấn nhỏ về tổng thể sẽ được hưởng lợi nhiều hơn từ việc sử dụng các kế hoạch nối tiếp, thay vì lãng phí nhiều tài nguyên vào việc đồng bộ hóa các luồng. Bạn vẫn có thể có nhiều truy vấn với các gói nối tiếp được thực thi cùng một lúc, sử dụng hiệu quả tài nguyên đa CPU của máy. Trên thực tế, nhiều chuyên gia SQL Server muốn tăng ngưỡng chi phí cho tính song song từ giá trị mặc định là 5 lên giá trị cao hơn. Một hệ thống chạy đồng thời một số lượng khá nhỏ các truy vấn lớn sẽ được hưởng lợi nhiều hơn từ việc sử dụng các gói song song.
Tóm lại, để SQL Server thích gói song song hơn so với phương án nối tiếp, chi phí gói nối tiếp cần ít nhất là ngưỡng chi phí cho song song và chi phí gói song song cần phải thấp hơn chi phí gói nối tiếp (ngụ ý có khả năng thời gian chạy thấp hơn).
Trước khi đi vào chi tiết của các công thức chi phí thực tế, tôi sẽ minh họa bằng các ví dụ về các tình huống khác nhau trong đó lựa chọn được thực hiện giữa kế hoạch nối tiếp và song song. Đảm bảo rằng hệ thống của bạn giả định có 8 CPU logic để nhận chi phí truy vấn tương tự như của tôi nếu bạn muốn thử các ví dụ.
Hãy xem xét các truy vấn sau (chúng tôi sẽ gọi chúng là Truy vấn 6 và Truy vấn 7):
- Truy vấn 6:Serial SELECT empid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =400001GROUP BY empid; - Truy vấn 7:Bắt buộc song song SELECT empid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =400001GROUP BY empidOPTION (SỬ DỤNG HINT ('ENABLE_PARALLEL_PLAN_PREFERENCE'));Kế hoạch cho các truy vấn này được thể hiện trong Hình 3.
Hình 3:Chi phí nối tiếp
Ở đây, chi phí kế hoạch song song [bắt buộc] thấp hơn chi phí kế hoạch nối tiếp; tuy nhiên, chi phí gói nối tiếp thấp hơn ngưỡng chi phí mặc định cho tính song song là 5, do đó SQL Server đã chọn gói nối tiếp theo mặc định.
Hãy xem xét các truy vấn sau (chúng tôi sẽ gọi chúng là Truy vấn 8 và Truy vấn 9):
- Truy vấn 8:Parallel SELECT empid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =300001GROUP BY empid; - Truy vấn 9:Bắt buộc truy vấn nối tiếp SELECT empid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =300001GROUP BY empidOPTION (MAXDOP 1);Kế hoạch cho các truy vấn này được thể hiện trong Hình 4.
Hình 4:Chi phí nối tiếp> =ngưỡng chi phí cho tính song song, chi phí song song
Ở đây, chi phí gói nối tiếp [bắt buộc] lớn hơn hoặc bằng ngưỡng chi phí cho tính song song và chi phí gói song song thấp hơn chi phí gói nối tiếp, do đó SQL Server đã chọn gói song song theo mặc định.
Hãy xem xét các truy vấn sau (chúng tôi sẽ gọi chúng là Truy vấn 10 và Truy vấn 11):
- Truy vấn 10:Serial SELECT * FROM dbo.OrdersWHERE orderid> =100000; - Truy vấn 11:Bắt buộc song song SELECT * FROM dbo.OrdersWHERE orderid> =100000OPTION (SỬ DỤNG HINT ('ENABLE_PARALLEL_PLAN_PREFERENCE'));Kế hoạch cho các truy vấn này được thể hiện trong Hình 5.
Hình 5:Chi phí nối tiếp> =ngưỡng chi phí cho tính song song, chi phí song song> =chi phí nối tiếp
Ở đây, chi phí kế hoạch nối tiếp lớn hơn hoặc bằng ngưỡng chi phí cho phương pháp song song; tuy nhiên, chi phí gói nối tiếp thấp hơn chi phí gói song song [bắt buộc], do đó SQL Server đã chọn gói nối tiếp theo mặc định.
Có một điều khác mà bạn cần biết về việc cố gắng tối đa hóa tính song song với gợi ý ENABLE_PARALLEL_PLAN_PREFERENCE. Để SQL Server thậm chí có thể sử dụng một kế hoạch song song, phải có một số công cụ hỗ trợ song song như một vị từ dư, một loại, một tổng hợp, v.v. Một kế hoạch chỉ áp dụng quét chỉ mục hoặc tìm kiếm chỉ mục mà không có vị từ dư và không có bất kỳ trình hỗ trợ song song nào khác, sẽ được xử lý với một kế hoạch nối tiếp. Hãy xem xét các truy vấn sau đây làm ví dụ (chúng tôi sẽ gọi chúng là Truy vấn 12 và Truy vấn 13):
- Truy vấn 12 SELECT * FROM dbo.OrdersOPTION (SỬ DỤNG HINT ('ENABLE_PARALLEL_PLAN_PREFERENCE')); - Truy vấn 13 SELECT * FROM dbo.OrdersWHERE orderid> =100000OPTION (SỬ DỤNG HINT ('ENABLE_PARALLEL_PLAN_PREFERENCE'));Kế hoạch cho các truy vấn này được thể hiện trong Hình 6.
Hình 6:Trình kích hoạt song song
Truy vấn 12 nhận được một kế hoạch nối tiếp bất chấp gợi ý vì không có trình kích hoạt tính năng song song. Truy vấn 13 có một kế hoạch song song vì có một vị từ còn lại tham gia.
Tính toán và kiểm tra DOP để tính chi phí
Microsoft đã phải hiệu chỉnh các công thức tính giá để cố gắng có chi phí kế hoạch song song thấp hơn chi phí kế hoạch nối tiếp phản ánh thời gian chạy thấp hơn và ngược lại. Một ý tưởng tiềm năng là lấy chi phí CPU của người vận hành nối tiếp và chỉ cần chia nó cho số CPU logic trong máy để tạo ra chi phí CPU của người vận hành song song. Số lượng CPU hợp lý trong máy là yếu tố chính xác định mức độ song song của truy vấn, hay nói ngắn gọn là DOP (số luồng có thể được sử dụng trong một vùng song song trong kế hoạch). Suy nghĩ đơn giản ở đây là nếu một toán tử mất T đơn vị thời gian để hoàn thành khi sử dụng một luồng và mức độ song song của truy vấn là D, thì nhà điều hành sẽ mất T / D thời gian để hoàn thành khi sử dụng D luồng. Trong thực tế, mọi thứ không đơn giản như vậy. Ví dụ:thông thường bạn có nhiều truy vấn chạy đồng thời chứ không chỉ một truy vấn, trong trường hợp đó, một truy vấn duy nhất sẽ không nhận được tất cả tài nguyên CPU của máy. Vì vậy, Microsoft đã đưa ra ý tưởng về mức độ song song đối với chi phí (Nói ngắn gọn là DOP cho chi phí). Số đo này thường thấp hơn số lượng CPU logic trong máy và là hệ số mà chi phí CPU của người vận hành nối tiếp được chia cho để tính chi phí CPU của người vận hành song song.
Thông thường, DOP để tính chi phí được tính bằng số CPU logic chia cho 2, sử dụng phép chia số nguyên. Tuy nhiên, vẫn có những ngoại lệ. Khi số lượng CPU là 2 hoặc 3, DOP để tính giá được đặt thành 2. Với 4 CPU trở lên, DOP để tính giá được đặt thành #CPUs / 2, một lần nữa, sử dụng phép chia số nguyên. Đó là mức tối đa nhất định, tùy thuộc vào dung lượng bộ nhớ có sẵn trên máy. Trong một máy có bộ nhớ lên đến 4.096 MB, DOP tối đa cho chi phí là 8; với hơn 4.096 MB, DOP tối đa cho chi phí là 32.
Để kiểm tra logic này, bạn đã biết cách mô phỏng số lượng CPU logic mong muốn bằng cách sử dụng DBCC OPTIMIZER_WHATIF, với tùy chọn CPU, như sau:
DBCC OPTIMIZER_WHATIF (CPU, 8);Sử dụng lệnh tương tự với tùy chọn MemoryMBs, bạn có thể mô phỏng một lượng bộ nhớ mong muốn tính bằng MB, như sau:
DBCC OPTIMIZER_WHATIF (MemoryMB, 16384);Sử dụng mã sau để kiểm tra trạng thái hiện có của các tùy chọn được mô phỏng:
DBCC TRACEON (3604); DBCC OPTIMIZER_WHATIF (Trạng thái); DBCC TRACEOFF (3604);Sử dụng mã sau để đặt lại tất cả các tùy chọn:
DBCC OPTIMIZER_WHATIF (ResetAll);Dưới đây là một truy vấn T-SQL mà bạn có thể sử dụng để tính DOP để tính chi phí dựa trên số lượng đầu vào của CPU logic và dung lượng bộ nhớ:
DECLARE @NumCPUs AS INT =8, @MemoryMBs AS INT =16384; CHỌN TRƯỜNG HỢP KHI @NumCPUs =1 THÌ 1 KHI @NumCPUs <=3 THÌ 2 KHI @NumCPUs> =4 THÌ (CHỌN MIN (n) TỪ (VALUES (@NumCPUs / 2), (MaxDOP4C)) NHƯ D2 (n)) KẾT THÚC NHƯ DOP4CFROM (CÁC GIÁ TRỊ (TRƯỜNG HỢP KHI @MemoryMBs <=4096 THÌ 8 ELSE 32 END)) NHƯ D1 (MaxDOP4C);Với các giá trị đầu vào được chỉ định, truy vấn này trả về 4.
Bảng 1 nêu chi tiết DOP về chi phí mà bạn nhận được dựa trên số lượng CPU và dung lượng bộ nhớ hợp lý trong máy của bạn.
| #CPUs | DOP để tính phí khi MB bộ nhớ <=4096 | DOP để tính phí khi MB bộ nhớ> 4096 |
|---|---|---|
| 1 | 1 | 1 |
| 2-5 | 2 | 2 |
| 6-7 | 3 | 3 |
| 8-9 | 4 | 4 |
| 10-11 | 5 | 5 |
| 12-13 | 6 | 6 |
| 14-15 | 7 | 7 |
| 16-17 | 8 | 8 |
| 18-19 | 8 | 9 |
| 20-21 | 8 | 10 |
| 22-23 | 8 | 11 |
| 24-25 | 8 | 12 |
| 26-27 | 8 | 13 |
| 28-29 | 8 | 14 |
| 30-31 | 8 | 15 |
| 32-33 | 8 | 16 |
| 34-35 | 8 | 17 |
| 36-37 | 8 | 18 |
| 38-39 | 8 | 19 |
| 40-41 | 8 | 20 |
| 42-43 | 8 | 21 |
| 44-45 | 8 | 22 |
| 46-47 | 8 | 23 |
| 48-49 | 8 | 24 |
| 50-51 | 8 | 25 |
| 52-53 | 8 | 26 |
| 54-55 | 8 | 27 |
| 56-57 | 8 | 28 |
| 58-59 | 8 | 29 |
| 60-61 | 8 | 30 |
| 62-63 | 8 | 31 |
| > =64 | 8 | 32 |
Bảng 1:DOP cho chi phí
Ví dụ:hãy truy cập lại Truy vấn 1 và Truy vấn 2 được hiển thị trước đó:
- Truy vấn 1:Bắt buộc nối tiếp SELECT custid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =300001GROUP BY custidOPTION (MAXDOP 1); - Truy vấn 2:Tự nhiên song song SELECT custid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =300001GROUP BY custid;
Kế hoạch cho các truy vấn này được thể hiện trong Hình 7.
Hình 7:DOP cho chi phí
Truy vấn 1 buộc một kế hoạch nối tiếp, trong khi Truy vấn 2 nhận một kế hoạch song song trong môi trường của tôi (mô phỏng 8 CPU logic và 16.384 MB bộ nhớ). Điều này có nghĩa là DOP cho chi phí trong môi trường của tôi là 4. Như đã đề cập, chi phí CPU của nhà điều hành song song được tính bằng chi phí CPU của nhà điều hành nối tiếp chia cho DOP cho chi phí. Bạn có thể thấy rằng đó thực sự là trường hợp trong kế hoạch song song của chúng tôi với các toán tử Tìm kiếm chỉ mục và Tổng hợp băm thực thi song song.
Đối với chi phí của các nhà khai thác sàn giao dịch, chúng được tạo thành từ chi phí khởi động và một số chi phí không đổi trên mỗi hàng, bạn có thể dễ dàng thiết kế ngược lại.
Lưu ý rằng trong chiến lược tổng hợp và nhóm song song đơn giản, chiến lược được sử dụng ở đây, ước tính bản số trong kế hoạch nối tiếp và song song là giống nhau. Đó là bởi vì chỉ có một toán tử tổng hợp được sử dụng. Sau này, bạn sẽ thấy rằng mọi thứ sẽ khác khi sử dụng chiến lược địa phương / toàn cầu.
Các truy vấn sau đây giúp minh họa ảnh hưởng của số lượng CPU logic và số hàng liên quan đến chi phí truy vấn (10 truy vấn, với gia số là 100 nghìn hàng):
SELECT empid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =900001GROUP BY empid; SELECT empid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =800001GROUP BY empid; SELECT empid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =700001GROUP BY empid; SELECT empid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =600001GROUP BY empid; SELECT empid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =500001GROUP BY empid; SELECT empid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =400001GROUP BY empid; SELECT empid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =300001GROUP BY empid; SELECT empid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =200001GROUP BY empid; SELECT empid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =100001GROUP BY empid; CHỌN empid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =000001GROUP BY empid;
Hình 8 cho thấy kết quả.
Hình 8:Chi phí truy vấn liên quan đến #CPU và #rows
Đường màu xanh lục biểu thị chi phí của các truy vấn khác nhau (với số lượng hàng khác nhau) bằng cách sử dụng kế hoạch nối tiếp. Các dòng khác thể hiện chi phí của các kế hoạch song song với số lượng CPU logic khác nhau và DOP tương ứng của chúng để tính chi phí. Đường màu đỏ thể hiện điểm tại đó chi phí truy vấn nối tiếp là 5 — ngưỡng chi phí mặc định cho cài đặt song song. Ở bên trái của điểm này (ít hàng được nhóm và tổng hợp hơn), thông thường, trình tối ưu hóa sẽ không xem xét một kế hoạch song song. Để có thể nghiên cứu chi phí của các phương án song song dưới ngưỡng chi phí cho phương thức song song, bạn có thể thực hiện một trong hai việc. Một tùy chọn là sử dụng gợi ý truy vấn ENABLE_PARALLEL_PLAN_PREFERENCE, nhưng xin nhắc lại, tùy chọn này tối đa hóa tính song song thay vì chỉ ép buộc. Nếu đó không phải là hiệu quả mong muốn, bạn chỉ có thể vô hiệu hóa ngưỡng chi phí cho song song, như sau:
EXEC sp_configure 'hiển thị các tùy chọn nâng cao', 1; CẤU HÌNH TÁI TẠO; EXEC sp_configure 'ngưỡng chi phí cho song song', 0; EXEC sp_configure 'hiển thị các tùy chọn nâng cao', 0; CẤU HÌNH TÁI TẠO;
Rõ ràng, đó không phải là một bước đi thông minh trong hệ thống sản xuất, nhưng hoàn toàn hữu ích cho mục đích nghiên cứu. Đó là những gì tôi đã làm để tạo ra thông tin cho biểu đồ trong Hình 8.
Bắt đầu với 100 nghìn hàng và thêm 100 nghìn gia số, tất cả các biểu đồ dường như ngụ ý rằng ngưỡng chi phí cho tính song song không phải là một yếu tố, một kế hoạch song song sẽ luôn được ưu tiên. Đó thực sự là trường hợp với các truy vấn của chúng tôi và số lượng hàng có liên quan. Tuy nhiên, hãy thử số lượng hàng nhỏ hơn, bắt đầu với 10 nghìn và tăng thêm 10 nghìn khoảng gia bằng cách sử dụng năm truy vấn sau (một lần nữa, giữ ngưỡng chi phí cho tính năng song song bị vô hiệu hóa ngay bây giờ):
SELECT empid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =990001GROUP BY empid; SELECT empid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =980001GROUP BY empid; SELECT empid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =970001GROUP BY empid; SELECT empid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =960001GROUP BY empid; CHỌN empid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =950001GROUP BY empid;
Hình 9 cho thấy chi phí truy vấn với cả kế hoạch nối tiếp và song song (mô phỏng 4 CPU, DOP với chi phí 2).
Hình 9:Serial / ngưỡng kế hoạch song song
Như bạn có thể thấy, có một ngưỡng tối ưu hóa mà gói nối tiếp được ưu tiên và trên đó ưu tiên cho gói song song. Như đã đề cập, trong một hệ thống thông thường, nơi bạn giữ ngưỡng chi phí cho cài đặt song song ở giá trị mặc định là 5 hoặc cao hơn, thì ngưỡng hiệu quả vẫn cao hơn trong biểu đồ này.
Trước đó tôi đã đề cập rằng khi SQL Server chọn chiến lược song song nhóm và tổng hợp đơn giản, các ước tính về bản số của các kế hoạch nối tiếp và song song là như nhau. Câu hỏi đặt ra là, SQL Server xử lý các ước tính bản số cho chiến lược song song cục bộ / toàn cầu như thế nào.
Để tìm ra điều này, tôi sẽ sử dụng Truy vấn 3 và Truy vấn 4 từ các ví dụ trước đó của chúng tôi:
- Truy vấn 3:Local song song song song toàn cục SELECT empid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =300001GROUP BY empid; - Truy vấn 4:Nối tiếp toàn cục song song cục bộ SELECT shipperid, COUNT (*) AS numordersFROM dbo.OrdersWHERE orderid> =300001GROUP BY shipperid;
Trong một hệ thống có 8 CPU logic và DOP hiệu quả cho giá trị chi phí là 4, tôi nhận được các kế hoạch được hiển thị trong Hình 10.
Hình 10:Ước tính số lượng
Truy vấn 3 nhóm các đơn đặt hàng theo trống. Cuối cùng dự kiến sẽ có 500 nhóm nhân viên riêng biệt.
Truy vấn 4 nhóm các đơn đặt hàng theo shipperid. Cuối cùng dự kiến sẽ có 5 nhóm người giao hàng riêng biệt.
Thật kỳ lạ, có vẻ như ước tính bản số cho số lượng các nhóm được tạo bởi tổng hợp cục bộ là {số lượng các nhóm riêng biệt được mong đợi bởi mỗi luồng} * {DOP cho chi phí}. Trong thực tế, bạn nhận ra rằng con số này thường sẽ nhiều gấp đôi vì những gì được tính là DOP để thực thi (hay còn gọi là DOP), chủ yếu dựa trên số lượng CPU logic. Phần này hơi phức tạp để mô phỏng cho mục đích nghiên cứu vì lệnh DBCC OPTIMIZER_WHATIF với tùy chọn CPU ảnh hưởng đến việc tính toán DOP để tính chi phí, nhưng DOP để thực thi sẽ không lớn hơn số CPU logic thực tế mà phiên bản SQL Server của bạn nhìn thấy. Con số này về cơ bản dựa trên số bộ lập lịch SQL Server bắt đầu với. Bạn có thể kiểm soát số lượng bộ lập lịch SQL Server bắt đầu bằng cách sử dụng tham số khởi động -P {#schedulers}, nhưng đó là công cụ nghiên cứu tích cực hơn một chút so với tùy chọn phiên.
Ở bất kỳ mức độ nào, mà không cần mô phỏng bất kỳ tài nguyên nào, máy thử nghiệm của tôi có 4 CPU logic, dẫn đến DOP có giá 2 và DOP để thực thi 4. Trong môi trường của tôi, tổng hợp cục bộ trong kế hoạch cho Truy vấn 3 hiển thị ước tính 1.000 nhóm kết quả (500 x 2) và thực tế là 2.000 (500 x 4). Tương tự, tổng hợp cục bộ trong kế hoạch cho Truy vấn 4 cho thấy ước tính là 10 nhóm kết quả (5 x 2) và thực tế là 20 (5 x 4).
Khi bạn thử nghiệm xong, hãy chạy mã sau để dọn dẹp:
- Đặt ngưỡng chi phí cho song song thành EXEC sp_configure mặc định 'hiển thị các tùy chọn nâng cao', 1; CẤU HÌNH TÁI TẠO; EXEC sp_configure 'ngưỡng chi phí cho song song', 5; EXEC sp_configure 'hiển thị các tùy chọn nâng cao', 0; RECONFIGURE; GO - Đặt lại tùy chọn OPTIMIZER_WHATIF DBCC OPTIMIZER_WHATIF (ResetAll); - Thả chỉ mục DROP INDEX idx_oid_i_sid ON dbo.Orders; DROP INDEX idx_oid_i_eid ON dbo.Orders; DROP INDEX idx_oid_i_cid ON dbo.Orders;
Kết luận
Trong bài viết này, tôi đã mô tả một số chiến lược song song mà SQL Server sử dụng để xử lý nhóm và tổng hợp. Một khái niệm quan trọng cần hiểu trong việc tối ưu hóa các truy vấn với các kế hoạch song song là mức độ song song (DOP) đối với chi phí. Tôi đã hiển thị một số ngưỡng tối ưu hóa, bao gồm ngưỡng giữa các kế hoạch nối tiếp và song song và ngưỡng chi phí đặt cho chế độ song song. Hầu hết các khái niệm mà tôi mô tả ở đây không phải là duy nhất để nhóm và tổng hợp, mà chỉ áp dụng cho việc xem xét kế hoạch song song trong SQL Server nói chung. Tháng tới, tôi sẽ tiếp tục loạt bài này bằng cách thảo luận về tối ưu hóa với các đoạn viết lại truy vấn.
