Kịch bản: SQL Server 2014 (v12.0.4100.1)
Dịch vụ .NET chạy truy vấn này:
SELECT name, base_object_name
FROM sys.synonyms
WHERE schema_id IN (SELECT schema_id
FROM sys.schemas
WHERE name = N'XXXX')
ORDER BY name
... Trả về khoảng 6500 hàng nhưng thường hết sau 3+ phút. Ở XXXXtrên không phải là 'dbo'.
Nếu tôi chạy truy vấn này trong SSMS dưới dạng UserA, truy vấn sẽ trả về sau chưa đầy một giây.
Khi chạy dưới dạng UserB (đó là cách dịch vụ .NET kết nối), truy vấn mất 3-6 phút và có% CPU ở mức 25% (trong 4 lõi) trong toàn bộ thời gian.
UserA là một Đăng nhập tên miền trong vai trò sysadmin.
UserB là một Đăng nhập SQL với:
EXEC sp_addrolemember N'db_datareader', N'UserB'
EXEC sp_addrolemember N'db_datawriter', N'UserB'
EXEC sp_addrolemember N'db_ddladmin', N'UserB'
GRANT EXECUTE TO [UserB]
GRANT CREATE SCHEMA TO [UserB]
GRANT VIEW DEFINITION TO [UserB]
Tôi có thể nhân đôi điều này trong SSMS bằng cách gói SQL ở trên vào một Execute as...Revertkhối, vì vậy mã .NET nằm ngoài hình ảnh.
Kế hoạch thực hiện trông giống nhau. Tôi khác với XML và chỉ có những khác biệt nhỏ (CompileTime, CompileCPU, CompileMemory).
Chỉ số IO tất cả hiển thị không đọc vật lý:
Bảng 'sysobjvalues'. Quét số 0, đọc logic 19970, đọc vật lý 0, đọc trước đọc 0, đọc logic 0, đọc vật lý lob 0, đọc trước đọc 0, đọc trước 0. Bảng 'Workfile'. Quét số 0, đọc logic 0, đọc vật lý 0, đọc trước đọc 0, đọc logic 0, đọc vật lý lob 0, đọc trước đọc 0, đọc trước 0. Bảng 'Bàn làm việc'. Quét số 0, đọc logic 0, đọc vật lý 0, đọc trước đọc 0, đọc logic 0, đọc vật lý lob 0, đọc trước đọc 0, đọc trước 0. Bảng 'sysschobjs'. Quét số 1, đọc logic 9122, đọc vật lý 0, đọc trước đọc 0, đọc logic 0, đọc vật lý lob 0, đọc trước đọc 0, đọc trước 0. Bảng 'sysclsobjs'. Quét số 0, đọc logic 2, đọc vật lý 0, đọc trước đọc 0, đọc logic 0, đọc vật lý lob 0, đọc trước đọc 0, đọc trước 0.
Trạng thái chờ XEvent (cho truy vấn ~ 3 phút) là:
+ --------------------- + ------------ + -------------- -------- + ------------------------------ + ---------- ------------------- + | Loại chờ | Đếm chờ | Tổng thời gian chờ (ms) | Tổng thời gian chờ tài nguyên (ms) | Tổng thời gian chờ tín hiệu (ms) | + --------------------- + ------------ + -------------- -------- + ------------------------------- + --------- -------------------- + | SOS_SCHEDULER_YIELD | 37300 | 427 | 20 | 407 | | MẠNG_IO | 5 | 26 | 26 | 0 | | IO_COMPLETION | 3 | 1 | 1 | 0 | + --------------------- + ------------ + -------------- -------- + ------------------------------- + --------- -------------------- +
Nếu tôi viết lại truy vấn (trong SSMS, tôi không có quyền truy cập vào Mã ứng dụng) để
declare @id int
SELECT @id=schema_id FROM sys.schemas WHERE name = N'XXXX'
SELECT a.name, base_object_name FROM sys.synonyms a
WHERE schema_id = @id
ORDER BY name
sau đó UserB chạy với tốc độ (nhanh) tương tự như UserA.
Nếu tôi thêm db_ownervào UserB, thì, một lần nữa, truy vấn sẽ chạy <1 giây.
Lược đồ được tạo thông qua mẫu này:
DECLARE @TranName VARCHAR(20)
SELECT @TranName = 'MyTransaction'
BEGIN TRANSACTION @TranName
GO
IF NOT EXISTS (SELECT SCHEMA_NAME FROM INFORMATION_SCHEMA.SCHEMATA
WHERE SCHEMA_NAME = '{1}')
BEGIN
EXEC('CREATE SCHEMA [{1}]')
EXEC sp_addextendedproperty @name='User', @value='{0}', @level0type=N'Schema', @level0name=N'{1}'
END
GO
{2}
COMMIT TRANSACTION MyTransaction;
GO
Và {2}, tôi tin rằng, một danh sách các Từ đồng nghĩa được tạo trong lược đồ đó.
Hồ sơ truy vấn tại hai điểm vào truy vấn:
Tôi đã mở một vé với Microsoft.
Ngoài ra, chúng tôi đã thử thêm UserB vào db_owner, và sau đó lấy DENYtất cả các đặc quyền mà chúng tôi biết có liên quan db_owner. Kết quả là một truy vấn nhanh. Hoặc là chúng tôi đã bỏ lỡ một cái gì đó (hoàn toàn có thể), hoặc có một kiểm tra đặc biệt cho db_ownervai trò.
