SQL Azure Query - terribly chậm Ngay cả Với Tuned Queries

Question

Dưới đây là một truy vấn cơ bản dựa trên hai chỉ số không clustered:

SELECT cc.categoryid, count(*) from company c 
INNER JOIN companycategory cc on cc.companyid = c.id 
WHERE c.placeid like 'ca_%' 
GROUP BY cc.categoryid order by count(*) desc 

Khi cùng cơ sở dữ liệu chính xác được lưu trữ trên SQL Server 2008, trên hầu như bất kỳ phần cứng , điều này trả về < 500 ms. Ngay cả khi bộ đệm cache đã xóa:

DBCC FREEPROCCACHE 
DBCC DROPCLEANBUFFERS 

... điều này vẫn trả về trong ~ 1 giây trên SQL truyền thống.

Trên Azure, mất khoảng 3,5 giây để trả lại mỗi lần.

Một số articles có vẻ như gợi ý rằng mọi người thường hài lòng với hiệu suất truy vấn trong SQL Azure. Và đây là một kịch bản cơ bản trong đó việc điều chỉnh 'hiển nhiên' đã cạn kiệt và không có vấn đề về độ trễ mạng. Nó chỉ là thực sự chậm khi làm việc w/bảng lớn (companycategroy có 1,2 triệu hồ sơ, địa điểm có 7,5K).

Tổng kích thước cơ sở dữ liệu không quá 4GB. Chọn phiên bản 'Web' so với phiên bản 'Doanh nghiệp' dường như không tạo ra nhiều sự khác biệt.

Tôi đang thiếu gì?

Đây chỉ là một ví dụ cơ bản, nó chỉ trở nên tồi tệ hơn với các truy vấn phức tạp hơn, tất cả đều là reviewed, được điều chỉnh và thực hiện tốt tại chỗ.

Dưới đây là kế hoạch thực hiện:

|--Sort(ORDER BY:([Expr1004] DESC)) 
     |--Compute Scalar(DEFINE:([Expr1004]=CONVERT_IMPLICIT(int,[Expr1007],0))) 
      |--Hash Match(Aggregate, HASH:([cc].[CategoryId]), RESIDUAL:([XX].[dbo].[CompanyCategory].[CategoryId] as [cc].[CategoryId] = [XX].[dbo].[CompanyCategory].[CategoryId] as [cc].[CategoryId]) DEFINE:([Expr1007]=COUNT(*))) 
       |--Hash Match(Inner Join, HASH:([c].[Id])=([cc].[CompanyId])) 
         |--Index Scan(OBJECT:([XX].[dbo].[Company].[IX_Company_PlaceId] AS [c]), WHERE:([XX].[dbo].[Company].[PlaceId] as [c].[PlaceId] like N'ca_%')) 
         |--Index Scan(OBJECT:([XX].[dbo].[CompanyCategory].[IX_CompanyCategory_CompanyId] AS [cc])) 

Và đây là những số liệu thống kê:

SQL Server parse and compile time: 
    CPU time = 0 ms, elapsed time = 0 ms. 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 0 ms. 
SQL Server parse and compile time: 
    CPU time = 14 ms, elapsed time = 14 ms. 

(789 row(s) affected) 

Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'CompanyCategory'. Scan count 1, logical reads 5183, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'Company'. Scan count 1, logical reads 8710, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 

(1 row(s) affected) 

SQL Server Execution Times: 
    CPU time = 3328 ms, elapsed time = 3299 ms. 
SQL Server parse and compile time: 
    CPU time = 0 ms, elapsed time = 0 ms. 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 0 ms. 

định nghĩa Index như sau:

CREATE NONCLUSTERED INDEX [IX_Company_PlaceId] ON [dbo].[Company] 
(
    [PlaceId] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) 
GO 

CREATE NONCLUSTERED INDEX [IX_CompanyCategory_CompanyId] ON [dbo].[CompanyCategory] 
(
    [CompanyId] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) 
GO 

ALTER TABLE [dbo].[Company] ADD CONSTRAINT [PK_Company_Id] PRIMARY KEY CLUSTERED 
(
    [Id] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) 
GO 

Answer 1

Dường như họ sử dụng một số CPU lõi cho truy vấn của bạn trong khi trên máy, truy vấn có thể song song (tất cả các thao tác được truy vấn làm song song).

Tuy nhiên, quét chỉ mục được sử dụng cho vị từ LIKE vì một số lý do trong khi chỉ mục tìm kiếm có thể đủ.

hãy thử sử dụng điều kiện rõ ràng này thay vì LIKE:

c.placeid >= 'ca' 
AND c.placeid < 'cb' 

và xem nếu nó thay đổi kế hoạch cho một Index Seek trên IX_CompanyPlaceId.

Answer 2

Chỉ cần một vài điều:

• Số liệu thống kê có được cập nhật trên Azure không? Tôi hơi cảnh giác với Hash Match đó cho một bảng hàng 1.2M
• Azure có số liệu thống kê tự động không? Nếu không, cơ sở dữ liệu địa phương của bạn có thể có rất nhiều thông tin mà SQL Azure không thể sử dụng để chọn một kế hoạch truy vấn tối ưu
• Index c.placeid đối với một số liệu thống kê về nó
• Tại sao c.placeid một chuỗi? Việc này có tuân theo companyid và c.id không? Tôi nghĩ rằng đây là lý do tại sao bạn có Hash Match - hãy thử tham gia vào các phím thay thế số nguyên thay thế.

Answer 3

Tôi đang đăng liên kết này lên bảo trì chỉ mục Cơ sở dữ liệu Azure SQL vì việc duy trì chỉ mục vẫn cần một bàn tay giúp đỡ.

https://blogs.msdn.microsoft.com/azuresqldbsupport/2016/07/03/how-to-maintain-azure-sql-indexes-and-statistics/

Chúng tôi sử dụng một runbook để thực hiện trên cơ sở dữ liệu của chúng tôi 350+ trên hồ đàn hồi khác nhau để thực hiện việc duy trì chỉ số. Hy vọng những người khác tìm thấy thông tin hữu ích như chúng tôi đã làm.