Table ' T_epz_inout_entry_detail '. Scan count 1, logic read 4,825 times, physical read 6 times, pre-read 19,672 times.
SQL Server Database engine when a query statement is encountered, the SQL Server database engine generates an execution plan (consuming CPU and memory resources) separately, while the storage engine reads IAM to generate a sorted list of the disk addresses that must be read. This allows SQL Server to optimize its I/O to large sequential reads, which are done sequentially based on their location on disk. Disk to get the data needed (take the I/O resources, this is read-ahead), note that two steps are parallel, SQL server in this way can let compute and I/O overlap, so as to make full use of CPU and disk, thereby improving performance.
Scan count: The number of times the number of tables visited or the index involved in the query data was queried. In our case, whether the table scan (example one and example two) or index Scan (example three) is accessed only 1 times, this information is not very useful because the connection command is not included in the query, but this information is useful if the query contains one or more connections.
The scan count value for a table outside a loop is 1, but for a table within a loop, its value is the number of cycles. As you can imagine, for a table within a loop, the smaller the value of its scanner, the less resources it uses, and the higher the performance of the query. Therefore, when adjusting the performance of a connected query, you need to pay attention to the value of the scan count, and when adjusting, pay attention to whether it is increased or decreased.
Logical read: This is the most useful data provided by the set STATISTICS IO or set STATISTICS time command. We know that before SQL Server operates on any data, it must first read the data page or index page on which the data resides, and then store the data page or index page in the data buffer cache.
So what is the meaning of logical reading? Logical read is the number of pages that SQL Server must read from the data buffer cache to get the results in the query. When a query is executed, SQL Server does not read more or less data than is actually required, so when executing the same query on the same dataset, the resulting logical read numbers are always the same.
Why is it important to know the logical read value of SQL Server when executing queries in tuning query performance? Because this number does not change each time the same query is executed. So, when it comes to tuning query performance, this is a good standard to measure the success of your adjustment measures.
When tuning the performance of a query, if the logical read value drops, it indicates that the query uses less server resources and the query has improved performance. If the logical read value increases, the throttling action reduces the performance of the query. In the case of other conditions, the less logical reading a query uses, the more efficient it is, and the faster the query will become.
Physical reading: What I'm going to say here may sound paradoxical at first, but as long as you think over and over, you will understand the true meaning.
Physical reading means that SQL Server must read the data it needs from disk to the data buffer cache before performing a real query operation. Before SQL Server starts executing a query, the first thing it does is check that it needs data in the data buffer cache, read from it, and if not, SQL Server must first read the data it needs from disk to the data buffer cache.
As we can imagine, SQL Server requires more server resources to perform a physical read than to perform a logical read. Therefore, in an ideal situation, we should try to avoid physical reading operations.
This part of the following sounds easy to confuse. When tuning the performance of a query, you can ignore physical reads and focus only on logical reads. You're going to wonder, didn't you just say that physical reading requires more server resources than logical reading?
Indeed, the physical reads that SQL Server needs to perform queries are not likely to be reduced by performance tuning. Reducing the number of physical reads is an important task for DBAs, but it involves tuning the performance of the entire server, not just the performance of the query. In the case of query performance tuning, we cannot control the size of the data buffer cache or how busy the server is, whether the data required to complete the query is in the data buffer or on disk, and the only data that we can control is the number of logical reads that are required to execute the query results.
Thus, in the tuning of query performance, we can safely disregard the physical read value provided by the set STATISTICS IO command. (One way to reduce the number of physical reads and speed up SQL Server is to make sure that the server has enough physical memory.) )
Read-ahead: As with physical reads, this value is not useful in query performance tuning. Read-ahead represents a data page or index page that SQL Server reads from disk when it performs a read-ahead mechanism. To optimize its performance, the SQL Server Data engine first predicts the data and index pages that are required to execute the query execution plan, and then reads them into the buffer cache before the query actually uses the pages. Depending on how accurately SQL Server forecasts data requirements, read-ahead data pages may or may not be useful.
Note: A buffer is a 8KB-sized memory page
Logical read in SQL Server performance tuning, physical read, what does pre-reading mean