sql中select字段影响性能分析

bayaci

很多人都说Select 后面 * 好还是字段名称好,都有疑问。我也以前对此问题模糊不清，经常以为select后面直接写每一个字段会好。
但是今天我对论坛查询情况跟踪分析的时候，一个翻页查询的read始终很高，不管我用*还是每一个字段写上， 都是很高。
这个表格大概有七十万条数据。
select * from table 或者 select col1,col2,col3 from table两种情况。

在下图中黄色注释部分描述上看到，这条语句偏偏在主键id上消耗那么资源，太不可思议。就此把select后面的字段少些几个都是一样的分析结果。最后我就只剩下主键ID来查询，果然凑效！～～～～

select top 40 topic_Id
from Forum_topic with(nolock) where 1=1
and IsDelete=0 and IsTop2=0 and Board_ID=13 order by istop desc,LastReplyTime desc,Topic_id desc

以上两个图片在select 查询的字段的选择上，性能预计成本大不相同。甚至万级别的成本，是在不可忍受。
有了这样的初步结果之后，我就对此论坛的数据库i/o一直很高有了初步的解决办法。
还有一个就是一下查询中，不知道为什么有些参数（红色）那么特别，请高人指点～～～
dbcc memorystatus
Buffer Distribution Buffers
------------------------------ -----------
Stolen 7119
Free 3608
Procedures 711
Inram 0
Dirty 1171
Kept 0
I/O 0
Latched 18
Other 194077
（所影响的行数为 9 行）
Buffer Counts Buffers
------------------------------ -----------
Commited 206704
Target 206704
Hashed 195266
InternalReservation 526
ExternalReservation 0
Min Free 1936
Visible 206704
（所影响的行数为 7 行）
Procedure Cache Value
------------------------------ -----------
TotalProcs 445
TotalPages 711
InUsePages 291
（所影响的行数为 3 行）
Dynamic Memory Manager Buffers
------------------------------ -----------
Stolen 7830
OS Reserved 13648
OS Committed 13626
OS In Use 13147
General 1187
QueryPlan 708
Optimizer 0
Utilities 11
Connection 18480
（所影响的行数为 9 行）

Global Memory Objects Buffers
------------------------------ -----------
Resource 931
Locks 225
XDES 112
SQLCache 70
Replication 2
LockBytes 2
ServerGlobal 23
（所影响的行数为 7 行）

Query Memory Objects Value
------------------------------ -----------
Grants 0
Waiting 0
Available (Buffers) 99648
Maximum (Buffers) 99648
（所影响的行数为 4 行）
Optimization Queue Value
------------------------------ -----------
Optimizing 0
Waiting 0
Available 64
Maximum 64
（所影响的行数为 4 行）
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。