First, the preparatory work
For a query cache performance impact is very large, so to clear the cache before optimization.
Clear all caches inside the Buffer Pool
DBCC DROPCLEANBUFFERS
Clear Buffer Pool where all cached execution plan, has been pre-compiled content herein will be cleared
DBCC FREEPROCCACHE
Two, SET STATISTICS TIME ON / OFF switch
The switching time of the SQL statement can output various stages consumed
Return Value:
CPU Time, SQL Server pure CPU time spent is much, that statement is how much CPU resources
elapsed Time, the length of the sentence run time, some action I / O operation will occur, resulting in I / O wait, or experience blocking, obstruction of a wait, spent a short time, but did not use CPU resources, CPU time Elapsed time longer than is normal. But the CPU Time is the sum of all the CPU time on the statement, if the statement uses a number of pieces CPU, while others hardly wait, then the CPU Time Elapsed Time greater than is normal.
SQL Server parse and compile time, compile-time statements
SQL Server Execution Times, the statement really run out of time
Results are as follows:
Three, SET STATISTICS IO ON / OFF switch
This switch can output the number of statements do physical read and logical reading of this switch is very important for performance tuning SQL Server execution plan. Usually the number of logical reads (logical reads) the smaller the better.
Return Value:
Scan COUNT: the number of scans performed. According to the implementation plan, the table is Scan several times. In general, the more the number of large tables Scan the bad, the only exception is if the execution plan chosen to run concurrently by multiple Thread do a table read at the same time, part of each Thread read, but will be displayed here the number of all Thread. That is, there are several concurrent Thread do, there will be a few Scan. At this time the number of larger, no problem.
logical reads: Number of pages read from the data buffer. The more pages, indicating the amount of data to be accessed on the query, the greater memory consumption, the more expensive the query. You can check whether the index should be adjusted, to reduce the number of scans, reduce the scan range.
physical reads: Number of pages read from disk.
read-ahead reads: For the query read-ahead cache of the pages.
physical reads + read ahead reads that the number of pages in order to complete the sentence SQL Server query read from the disk. If not 0, indicating that the data is not cached in memory, the speed will be affected.
lob logical reads: Text read from the data buffer, the number Ntext, Image type or a large value (Varchar (max), Nvarchar ( max), Varbinary (max)) page.
lob physical reads: Number read from the disk Text, Ntext, Image or large value type pages.
lob read-ahead reads: For inquiries and placed in the cache of Text, the number of Ntext, Image or large value type pages.
Results are as follows:
Four, SET STATISTICS PROFILE ON / OFF switch
This switch can return statement execution plan, and the statement is run in the actual number of rows returned each step
Rows: actual number of rows each step implementation plan to return.
Executes: every step of the implementation of the plan is to run how many times.
StmtText: details of the implementation plan. Execution plan is displayed in a tree form. Each row, step is running, there will be a return result sets, also will have their own cost.
EstimateRows: SQL Server according to statistics the number of rows on the table, every step of return estimated. In the analysis of the implementation plan, and we will often be Rows EstimateRows two columns do comparison, make sure the SQL Server estimate was accurate.
EstimateIO: SQL Server according to field length EstimateRows and statistical information in the record, I estimated each step will produce / O cost.
EstimateCPU: SQL Server based on the complexity of the field length EstimateRows and statistical information in the record, as well as things to do, estimated every step will have a CPU cost.
TotalSubtreeCost: SQL Server based on EstimateIO and EstimateCPU by some formula to calculate every step of the execution plan sub-tree cost (including the sum of the cost of this step and its own cost all the lower steps).
Warnings: SQL Server encountered every step of warning is running, for example, a step no statistics to support cost estimates and so on.
Parallel: This step is the implementation of the plan instead of using a parallel execution plan.
Results are as follows:
