Hiệu suất CTE đệ quy


8

Cần giúp đỡ với hiệu suất CTE đệ quy. Bên dưới CTE đang chạy rất chậm vì nó đang cố gắng kéo dữ liệu theo kiểu bá đạo. Bảng là lớn với mỗi id gốc có tối đa 3 itemid đệ quy. Có thể có khoảng 200000 id gốc trở lên. Tôi biết CTE đệ quy rất chậm đối với tập dữ liệu khổng lồ vì với mỗi rootid trong neo, nó sẽ được đệ quy đệ quy.

Lược đồ :

Create table RootItem (ItemId int primary key, RootIt int , insertdate datetime)

Bảng trên có hơn 1 triệu hàng.

Truy vấn CTE:

; With rootcte as

( select itemid from RootItem where rootid is null

union all

  select r.itemid as RootId , i.itemid from RootItem i join rootcte r
    on i.rootid = r.itemid
)

Chúng ta không thể sửa đổi lược đồ bảng và sử dụng heirarchyid. Tôi đã thử trong khi loop quá nhưng điều đó cũng chậm.

Có cách nào khác để tôi có thể tối ưu hóa truy vấn này không?

 ; With rootcte as

( select itemid from RootItem where rootid is null

 union all

 select r.itemid as RootId , i.itemid from RootItem i join rootcte r
 on i.rootid = r.itemid
) 
  SELECT  
     Cust.CustomerID  
    , Cust.BusinessName  
    , sCust.RegionCustomerID  
    , ord.OrderID  
    , ord.OrderItemID  
    , prd.ProductCode  
    , rc.itemid
    , rc.rootid 
    , mf.FileID  
FROM  
    vw_Customer Cust  
    INNER JOIN SrcCustomer scust ON Cust.CustomerID = sCust.RegionCustomerID  
    INNER JOIN OrderItem ord ON Cust.MasterCustomerID = ord.MasterCustomerID  
    INNER JOIN Product ON ord.ProductID = Product.ProductID  
    INNER JOIN rootcte rc ON ord.RootOrderId = rc.Rootid   
    INNER JOIN MFolder mf ON mf.mfolderid = rc.itemid  
    INNER JOIN MVersion mv ON mv.mfolderversionid = mf.mfolderid   
    WHERE ord.IsActive = 1  and product.IsSelling = 1 and mf.fileid in (23,45,29)
     and mv.isdeleted = 'N' 

Tôi cũng đang làm việc với nhóm BI để thay đổi logic truy vấn và lọc dữ liệu trong chính cte của việc di chuyển vài phép nối và tiêu chí thành cte .. Cảm ơn tất cả các ý kiến.


2
Tại sao bạn cần tất cả các thứ bậc? Không nên có một nơi nào đó ở đâu đó để bạn chỉ ghi lại cho các bản ghi bạn định sử dụng. Chắc chắn bạn không cần phải xây dựng hàng triệu thứ bậc mỗi khi bạn chạy cái này.
HLGEM

Đây là báo cáo tài sản thế chấp được chạy khoảng 5-6 lần trong một giờ làm việc và yêu cầu phải được chạy trên toàn bộ dữ liệu. Tôi có thể tải trước dữ liệu nếu dữ liệu tĩnh hoặc không được chèn thường xuyên nhưng trong trường hợp này, các hoạt động DML thường xuyên đang chạy trên bảng này trong DB.
njvds

Những chỉ số nào bạn có trong bảng này?
ypercubeᵀᴹ

ItemID là khóa chính và cũng không có chỉ mục phân cụm trên itemid và rootid.
njvd

1
Bạn phải hiển thị truy vấn bạn đang thực sự sử dụng. Như bây giờ, tất cả những gì bạn làm là một cách phức tạp để trả lại tất cả ItemID từ bảng. CTE đệ quy không thêm bất kỳ giá trị nào.
Mikael Eriksson

Câu trả lời:


3

Bạn nói rằng hệ thống phân cấp được sửa đổi. Có lẽ trong khi hoạt động này đang chạy, có một số lượng chặn đang diễn ra sau đó?

Ngay cả khi hệ thống phân cấp đang thay đổi, gốc rễ của các mặt hàng có thay đổi không?

Bạn đã xem xét thời gian cần thiết để tạo bảng ánh xạ từ gốc đến mục và lập chỉ mục chưa?

Tôi muốn xem kế hoạch thực hiện để xem điều gì đang xảy ra - CTE sẽ được lưu lại, nhưng như một bảng được vật liệu hóa và lập chỉ mục thủ công, nó có thể hoạt động tốt hơn trong các bước sau.

Ngay cả với hoạt động nặng nề, dường như ai đó sẽ bị chặn nếu các hoạt động DML đang thay đổi dữ liệu mà quá trình này đang đọc.

Vì vậy, tôi rất muốn xem xét việc chụp ảnh phân cấp.

Ngoài ra, bạn có một số THAM GIA INNER khác - bạn nên xem lại liệu trên thực tế, đó có phải là CTE hay không và liệu có bất kỳ chỉ mục nào bị thiếu để làm cho những tham gia đó có hiệu quả hay không. Kế hoạch thực hiện sẽ cho bạn biết rằng.

Bạn dường như có khá nhiều điều trong mệnh đề WHERE có thể giúp giảm một số thao tác (và xác định chỉ mục nào có thể là tốt nhất)), nhưng thật khó để nói mà không nhìn vào kế hoạch thực hiện hoặc các chỉ mục.


Tại sao một hoạt động DML sẽ chặn CHỌN? SQL Server có còn hạn chế không?
a_horse_with_no_name

@a_horse_with_no_name msdn.microsoft.com/en-us/l Library / ms173763.aspx có thể nhưng người dùng đã đề cập có hoạt động cao, vì vậy anh ta cần xem xét chiến lược của mình
Cade Roux
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.