Đây là câu hỏi đầu tiên và quan trọng nhất về hiệu suất. Bạn đang đối phó với một mã hoạt động kém và bạn phải xác định nút cổ chai và giải quyết nó. Tôi đang nói về 2 giây tồi tệ hiệu suất ngay bây giờ. Thực hiện theo các hướng dẫn tại Cách phân tích hiệu suất SQL Server . Khi bạn nhận được truy vấn này để thực thi cục bộ có thể chấp nhận được đối với một ứng dụng web (dưới 5 mili giây) thì bạn có thể đặt câu hỏi về việc chuyển nó sang Azure SQL DB. Hiện tại, tài khoản dùng thử của bạn chỉ làm nổi bật những điểm kém hiệu quả hiện có.
Sau khi cập nhật
...
@iddepartment int
...
iddepartment='+convert(nvarchar(max),@iddepartment)+'
...
vậy đo la cai gi? là iddepartment cột một int hoặc một nvarchar ? Và tại sao lại sử dụng (max) ?
Đây là những gì bạn nên làm:
- tham số hóa
@iddepartmenttrong SQL động bên trong - ngừng hoạt động
nvarchar(max)sự chuyển đổi. Tạoiddepartmentvà@iddertmentcác loại khớp với nhau - đảm bảo các chỉ mục trên
iddepartmentvà tất cảidkpis
Đây là cách tham số hóa SQL bên trong:
set @sql =N'
Select * from (
select kpiname, target, ivalues, convert(decimal(18,2),day(idate)) as iDay
from kpi
inner join kpivalues on kpivalues.idkpi=kpi.idkpi
inner join kpitarget on kpitarget.idkpi=kpi.idkpi
inner join departmentbscs on departmentbscs.idkpi=kpi.idkpi
where [email protected]
group by kpiname,target, ivalues,idate)x
pivot
(
avg(ivalues)
for iDay in (' [email protected] + N')
) p'
execute sp_executesql @sql, N'@iddepartment INT', @iddepartment;
Các chỉ số bao trùm, cho đến nay, là bản sửa lỗi quan trọng nhất. Điều đó rõ ràng đòi hỏi nhiều thông tin hơn hiện tại ở đây. Đọc Thiết kế Chỉ mục bao gồm tất cả các chương phụ.
Như một nhận xét chung hơn:loại truy vấn này phù hợp với columnstores nhiều hơn rowstore, mặc dù tôi cho rằng kích thước dữ liệu về cơ bản là rất nhỏ. Azure SQL DB hỗ trợ các chỉ mục cột lưu trữ được phân cụm có thể cập nhật, bạn có thể thử nghiệm với nó với dự đoán về kích thước dữ liệu nghiêm trọng. Họ yêu cầu Enterprise / Development trên hộp cục bộ, đúng.
