原来页面有select count(*)查询总条数。几百万条数据量比较大。
现在改为取消掉了查询总条数,直接limit 和 offset 。此为背景。
销售那边反应现在看不到总条数。我就解释了 select count(*)搜索全部数据很浪费性能。然后他问我。你做排序的时候不是也要全表数据排序吗? 意思就是说 count(*)那点性能没关系。
是不是真的这样呢?排序和count(*)性能差距有多少呢?
现在改为取消掉了查询总条数,直接limit 和 offset 。此为背景。
销售那边反应现在看不到总条数。我就解释了 select count(*)搜索全部数据很浪费性能。然后他问我。你做排序的时候不是也要全表数据排序吗? 意思就是说 count(*)那点性能没关系。
是不是真的这样呢?排序和count(*)性能差距有多少呢?
网上搜索了下,发现各种说法都有:
比如认为COUNT(COL)比COUNT(*)快的;
认为COUNT(*)比COUNT(COL)快的;
还有朋友很搞笑的说到这个其实是看人品的。在不加WHERE限制条件的情况下,COUNT(*)与COUNT(COL)基本可以认为是等价的;
但是在有WHERE限制条件的情况下,COUNT(*)会比COUNT(COL)快非常多;http://www.ccvita.com/347.html
1楼看看这篇文章,别自以为是,我也想我们公司那么多大拿都写count(*)也没人说呢。
limit
要是通过索引的话会快 不通过索引反而会慢
1.任何情况下SELECT COUNT(*) FROM tablename是最优选择;
2.尽量减少SELECT COUNT(*) FROM tablename WHERE COL = ‘value’ 这种查询;
3.杜绝SELECT COUNT(COL) FROM tablename WHERE COL2 = ‘value’ 的出现。
以后瞎说不要误人子弟。
哈哈,没想到刚刚,的确,获取最后一条还得需要order by,这样一来又回去了
我认为在表很大的时候,分页显示不需要用COUNT(*)/20得到总的页数,在页面展示的时候用
select * from tbname limit 20
select * from tbname limit 21,40
select * from tbname limit 41,60
根据点到的多少页,确定LIMIT的参数。