The next article is to record what they have blind spots, but also reveal their own development process (development is not really possible, can only say that Xiahun). Of course, some blind spots also work and inquiry process looks somewhat slowly, but now they are willing to carry forward the spirit of dedication blog park, out and share with you.
See above the door, directly into the title
In view an execution plan, do you have, like me, have such doubts it? What exactly is search and scanning, as well as their What is the difference in query performance. Here to share my understanding.
Find SQL Server are scanned and read iterators data used from a table or index, and because often seen in the execution plan, and therefore understand the differences between them, for us to optimize query has very important significance.
Table scan is performed on an entire table, and the index scan is processed across the page level, however, it is in the index lookup to find on one or several pages on predicates, so he usually, the index will find there are fewer IO overhead.
Since the scanning is a whole page or row in the table, regardless of whether the condition, one by one the. Therefore, its query cost value is given, and returns the result set is independent. Index lookup is performed on several pages where the predicate, usually, the more the result set returned, the greater the cost.
However, by the above description, we can not believe that, look is good, but the scan is not good (because of the influence of scanning performance as well as the degree of parallelism), but in most cases, especially large amount of data, the result set returned relatively small, it has a better look than scanning performance, while not all of the scans can be optimized away.
Here, we come to know, the inquiry scan and the difference in performance by example.
We also use SQL Server execution plan that thing (1) example (indexing previously deleted) in.
We performed the following query
1. In the absence of the index case
select ID ,Amount,Discount,BuyDate from Headers
select ID ,Amount,Discount,BuyDate from Headers where BuyDate='2008-09-15'
Results: In the case of table scans, although the result set, only one data, but did not reduce the IO overhead, and still return the entire result set is the same.
2. In an index (non-clustered index to cover the return column, otherwise it will cause RID search, or look for the key, which will be covered in a future article.)
Creating an index
create nonclustered index index_headers_buyDate on Headers(BuyDate)
include (ID ,Amount,Discount)
go
select ID ,Amount,Discount,BuyDate from Headers
select ID ,Amount,Discount,BuyDate from Headers where BuyDate='2008-09-15'
Results: In the index scan and index lookup circumstances, the use of overhead and return results closely
to sum up
1. When data in the table that satisfy the predicate rows little or relatively long time, more effective use of the scanning operation.
2. If the table when there are fewer or greater amount of data rows that satisfy the predicate, the read scanning performed more pages or more I / O operations to acquire data, which is significantly not the most effective way.
3. Find and scan compared to not always look good, scanning is also not bad, because the query assign multiple threads (parallelism) SQL Server may be for.
Reproduced in: https: //www.cnblogs.com/mrzl/p/4076249.html