Vấn đề về hiệu năng với xpath trong SQL Server 2008


7

Tôi có một bảng có nhiều tài liệu xml lớn.

Khi tôi chạy các biểu thức xpath để chọn dữ liệu từ các tài liệu đó, tôi gặp phải một vấn đề hiệu năng đặc biệt.

Truy vấn của tôi là

SELECT
p.n.value('.', 'int') AS PurchaseOrderID
,x.ProductID 
FROM XmlLoadData x
CROSS APPLY x.PayLoad.nodes('declare namespace NS="http://schemas.datacontract.org/2004/07/XmlDbPerfTest"; 
/NS:ProductAndRelated[1]/NS:Product[1]/NS:PurchaseOrderDetails[1]/NS:PurchaseOrderDetail/NS:PurchaseOrderID[1]') p(n)

Truy vấn mất 2 phút 8 giây.

Khi tôi loại bỏ các [1]phần của các nút đơn lẻ như thế này:

SELECT
p.n.value('.', 'int') AS PurchaseOrderID
,x.ProductID 
FROM XmlLoadData x
CROSS APPLY x.PayLoad.nodes('declare namespace NS="http://schemas.datacontract.org/2004/07/XmlDbPerfTest"; 
/NS:ProductAndRelated/NS:Product/NS:PurchaseOrderDetails/NS:PurchaseOrderDetail/NS:PurchaseOrderID') p(n)

Thời gian thực hiện giảm xuống chỉ còn 18 giây.
Vì các [1]nút xảy ra chỉ một lần trong mỗi nút cha trong các tài liệu, kết quả là như nhau ngoại trừ việc đặt hàng.

Kế hoạch thực hiện thực tế cho truy vấn đầu tiên (chậm) là Lập kế hoạch cho truy vấn 1

và truy vấn thứ hai (nhanh hơn) là

nhập mô tả hình ảnh ở đây

Truy vấn 1 toàn màn hình Truy vấn 2 toàn màn hình .

Theo như tôi có thể thấy truy vấn [1]thực hiện giống như truy vấn mà không có, nhưng với việc thêm một số bước tính toán bổ sung để tìm mục đầu tiên.

Câu hỏi của tôi là tại sao truy vấn thứ hai nhanh hơn.
Tôi đã dự kiến ​​việc thực hiện truy vấn [1]sẽ bị hỏng sớm khi tìm thấy kết quả khớp và do đó giảm thời gian thực hiện thay vì ngược lại.
Có bất kỳ lý do tại sao việc thực thi không phá vỡ sớm [1]và do đó làm giảm thời gian thực hiện.

Đây là bàn của tôi

CREATE TABLE [dbo].[XmlLoadData](
    [ProductID] [int] NOT NULL,
    [PayLoad] [xml] NOT NULL,
    [Size]  AS (len(CONVERT([nvarchar](max),[PayLoad],0))),
 CONSTRAINT [PK_XmlLoadData] PRIMARY KEY CLUSTERED 
(
    [ProductID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, 
       IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, 
       ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

Chỉnh sửa:
Số hiệu suất từ ​​SQL Profiler:

Truy vấn 1:

CPU     Reads   Writes  Duration 
126251  1224892 0       129797

Truy vấn 2:

CPU     Reads   Writes  Duration 
50124   612499  0       16307

1
Xin vui lòng không đăng một hình ảnh của kế hoạch thực hiện, nhưng kế hoạch . Có nghĩa là tệp XML. Có rất nhiều thông tin trong các tệp XML không được hiển thị trong ảnh của kế hoạch.
Remus Rusanu

Câu trả lời:


2

Truy vấn thứ hai sử dụng song song. Đó là, nó đủ đắt để trình tối ưu hóa nhắm mắt lại với chi phí bổ sung.

Tôi đoán truy vấn thứ hai bảo trình tối ưu hóa "kết xuất mọi thứ", được thực hiện với quét song song. SQL Server thích "đổ mọi thứ" theo cách này khi được hỏi.
Trong khi truy vấn đầu tiên yêu cầu "phân tích và sau đó đưa ra một số." Trình tối ưu hóa không có cách nào để biết chỉ có một nút, vì vậy kế hoạch thực hiện mà nó kết thúc chọn là rất khác nhau.

Tôi muốn nói nó tương tự như tình huống khi quét một bảng rẻ hơn nhiều lần tìm kiếm chỉ mục.


Bạn đúng ở chỗ truy vấn thứ hai sử dụng song song. Nhưng tôi không thể hiểu làm thế nào điều đó có thể giải thích cho sự khác biệt lớn như vậy trên máy lõi tứ của tôi. Tôi đã chỉnh sửa câu hỏi với các số từ trình lược tả SQL, tổng thời gian CPU đã sử dụng thấp hơn 50% cho truy vấn thứ hai. Là mức tiêu thụ CPU giảm có phải là một ảnh hưởng của kế hoạch truy vấn song song đó cũng hiệu quả hơn ngoài việc song song không?
Albin Sunnanbo

1

Hãy xem Tối ưu hóa hiệu suất cho Kiểu dữ liệu XML trong SQL Server 2005 và phần về "Di chuyển thông thường đến cuối đường dẫn".

Các thông thường được sử dụng trong các biểu thức đường dẫn cho tính chính xác của kiểu tĩnh là các ứng cử viên tốt cho vị trí ở cuối các biểu thức đường dẫn. Biểu thức đường dẫn /book[1]/title[1]tương đương với (/book/title)[1]nếu mọi <book>phần tử có <title>con. Cái sau có thể được đánh giá nhanh hơn cho cả trường hợp được lập chỉ mục XML và trường hợp blob XML bằng cách xác định <title>phần tử đầu tiên dưới một <book>phần tử theo thứ tự tài liệu. Tương tự, biểu thức đường dẫn (/book/@ISBN)[1]mang lại sự thực thi nhanh hơn /book[1]/@ISBN.


0

Truy vấn XML là một con thú. Thêm các chỉ mục XML vào bảng của bạn sẽ làm cho các truy vấn RẤT nhanh hơn.


Tôi dự định chạy các truy vấn đó một lần để xây dựng các bảng quan hệ có chứa dữ liệu tôi muốn tìm kiếm. Lý do tôi cần tốc độ là chúng tôi muốn giảm thiểu các nhiễu loạn trong cơ sở dữ liệu sản xuất của chúng tôi khi chúng tôi trích xuất dữ liệu. Xây dựng một chỉ mục XML cũng mất rất nhiều thời gian.
Albin Sunnanbo
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.