SQL 语句Count(*)如何优化

[dp517849241]

select count(*) from His_Section where userid>=100

表中有3000多万数据，查询要16秒才有结果。

求高手指点如何优化，或者用系统存储过程或者函数代替什么的都可以

EXEC SP_SPACEUSED 'His_Section' 这样效率很高，但是不能加筛选条件

[Tiger_Zhao]

给 userid 单独建索引，或者 userid 是某个复合索引的第一列。

[还在加载中灬]

select count(userid) from His_Section where userid>=100 在列 userid 上加索引

[dp517849241]

引用 1 楼 Tiger_Zhao 的回复:

给 userid 单独建索引，或者 userid 是某个复合索引的第一列。

这只是一个例子，我实际开发中，表名和 where后面的条件都是页面传过来的。所以where后面有不确定性。

[Tiger_Zhao]

随意条件根本没法优化。
设计方案决定了低性能，苦果自吞。

[KeepSayingNo]

就单个表来说无非就是在查询条件字段上加索引来提升查询速度，你说语句可能会更复杂，那就需要特殊问题特殊分析

[阳泉酒家小当家]

where 后面的动态条件当然可以，但是不能太多，否则就得建很多索引，效率会很差

[专注or全面]

这个问题能否“逃避”开来？ 一般来说，人们对于数据，关心的更多的是内容， 就比如我去淘宝上搜索瓜子，我关系的是瓜子本身，而不是有多少条瓜子的信息 另外，这么大的数据量，关系多少条数，应该不是侧重点，比如1999999条数据和2000001条数据，这个意义不大吧 另外就想京东的ipad客户端那样，只要往下拉，他就不断地显示，关注于内容本身，连神马下一页下一页的就免了 算了，回了跟没回一样

[吉普赛的歌]

按历史记录水平分表或者按功能性垂直分表吧

[Q315054403]

简单的在USER_ID上建个索引（既然已有PK、CLUSTER） 要么从设计上解决，就稍麻烦点了