以下內容節錄自Transaction blog，希望對你有幫助。
Firstly, Reads represent the number of 8kb "page reads" performed by SQL Server to execute any given query. SQL Server stores table rows on 8kb pages on disk & these pages are read from disk or memory buffers (if they're already cached in memory)
during query execution. The Reads value reported for each SQL Trace event includes the number of these reads performed by each query (whether from disk or memory) & is therefore a key indicator of general query performance. The more Reads performed by
any given query, the less efficiently it is performing. Common causes of inefficiencies in this area are lack of suitable indexes on tables, leading to table scans when SQL Server executes its queries. Usually these problems can be resolved by "tuning" the
query by adding better indexes to the database (Database Tuning Advisor is useful in this area for less experienced DBAs).
A couple of problems with filtering by the Reads column though - firstly, it includes non data page reads such as Procedure Cache page reads. Don't forget that SQL Server tries to avoid compiling every query it runs by "remembering" query plans
by caching them in its Procedure Cache. Later, when the same query runs again, SQL Server first looks up its Procedure Cache to try & find a query plan rather than recompiling it each time it is run. The reads performed when looking up the Procedure Cache
(which also uses 8kb memory buffers) are also included in the figure reported by SQL Trace's Reads output. Another problem is that the figure reported in the Reads output provides only a whole query total, giving no table by table breakdown. To obtain a more
granular breakdown (at a table by table level), SET STATISTICS IO ON can be used at the connection level when re-running a query. So, whilst Reads does provide a generally useful measurement of query workload, it isn't perfect & can sometimes be mis-leading
if the Procedure Cache is abnormally large or transient.
以上說明若有錯誤請指教，謝謝。
http://www.dotblogs.com.tw/terrychuang/
