sql中select字段影响性能分析
很多⼈都说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 0sql中select是什么意思
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 输出了错误信息,请与系统管理员联系。
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。
发表评论