Morning test the performance of the pressure test, we found that a large number of service sequence to take a timeout error, monitor SQL query line:
A lot of this inquiry, I built a composite index on DeviceID and Isdelete, should soon, but I tested, value, high efficiency, slow does not happen.
But by SQL Profile tools to monitor, we found this sql, CPU and IO execution is high, remove the profile out of the monitor sql:
exec sp_executesql N'select * from AppCustomerDevice where DeviceID=@DeviceID and IsDelete=0',N'@DeviceID nvarchar(4000)',@DeviceID=N''
The original of this data to detect more than 17 million data, so the implementation is very slow. Later communication down DeviceID = '' are some of the erroneous data, these techniques can IsDelete = 0 data into IsDelete = 1, after a change, as the case may be optimized SQL Well,
But by SQL Profile Tool, or the sql execution is slow to look at its implementation plan is still to go full table scan, so that the technical parameters of the wording changed to non-parametric, but the version you want to send later in the @ DeviceID = N'2 'casual value or IO high.
Look at the situation is the implementation plan have lunch or fix its implementation plan, coupled with (index = index name), but long hair version of the time, the feeling is not statistics,
This library is executed on a little updating statistics: EXEC sp_updatestats, look at empty the cache: dbcc freeproccache
Executed again, use the index found. problem solved.
to sum up:
1, always thought indexed on OK, in fact, depends on the amount of data sql query number, the query is just to look up the largest, more than 17 million pieces and all out,
2, parameterized query, choose the best execution plan, it can consider updating statistics about the database, look at the empty cache
Reproduced in: https: //www.cnblogs.com/zping/p/11053286.html