[[410900]]
本文转载自微信公众号「有关SQL」,飞起作者一只小小鸟鸟。何让转载本文请联系有关SQL公众号。飞起
COUNT(*)是何让每个初学者的最爱,但凡漂亮的飞起按下回车时,看着转啊转的何让进度条,总是飞起有种莫名的喜感。平时总被老板催着干这干那,何让现在我也能指挥下电脑帮我跑跑数据!
虽说平时面试官总爱问 COUNT(*) 有什么坏处啊,飞起为什么要避免使用 COUNT(*) 这类怪问题。何让真要说起来,他们也是一脸懵圈,因为面试题都有可能是网上随便摘的。
至于原理,多少人真正懂呢,真正在乎呢?
那么,COUNT(*)的性能真那么差吗?怎么才能提高性能呢!今天就盘它
已知 SQL Server 中有这样张表 (其他数据库也适用):
- CREATE TABLE [dbo].[MobileLink](
- [user_id] [varchar](50) NULL,
- [item_id] [varchar](50) NULL,
- [behavior_type] [varchar](50) NULL,
- [user_geohash] [varchar](50) NULL,
- [item_category] [varchar](50) NULL,
- [time] [varchar](50) NULL
- )
这张表没有索引,是张堆表(Heap Table). 总共有4000多万条数据。
第一次,运行 count(*)
- SELECT COUNT(*) AS CNT
- FROM dbo.MobileLink
可以看到运行大约花了 3 秒时间 执行计划也简单,走了全表扫描
我之前也分享过,数据是存在数据页上的。这个数据页可以看做是一页纸。在纸上把字写得越紧凑,得到的信息越多。反之,如果你把字写得够大,行与行之间又很松散,每页纸能容纳的信息量也就少了。
于是,像这样全表扫描的效率就很低,理论上,只要把每页上,每一行的第一个字段统计下,就能知道有多少行了。于是索引就排上用场了。
第一个提高性能的方案就出来了,建一个索引
- CREATE INDEX IDX_USR_ITEM ON dbo.MobileLink(user_id,item_id) ;
执行计划如我所料,肯定走索引
总耗时2.036s 比刚才 3s 好上一丢丢。
经常看到网上有贴发表,count 单列(如 count(user_id) )会比 count(*) 有优势,果真如此吗?
- SELECT COUNT(user_id) AS CNT
- FROM dbo.MobileLink
2.813s 对 2.036s , 并无优势。
那么按照刚才的思路,现在已经取 user_id , item_id 作为统计基数了,那么是不是还有办法可以更小?对,那就是压缩
- ALTER INDEX IDX_USR_ITEM ON dbo.MobileLink REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE);
执行上面压缩语句,再运行 count(*). 对比结果与执行计划
耗时已经进入1s级,又进一步。
再反观,使用单列( COUNT(user_id) )来统计行数:
依旧在2s级徘徊!
可见, COUNT(USER_ID) 并无优势!
还有更快的方法,列式索引。它的优点除了节省空间外,还外加压缩,双重优化。
- CREATE NONCLUSTERED COLUMNSTORE INDEX COL_IDX ON dbo.MobileLink(user_id,item_id) ;
已经破1s 级。在列式索引面前,其他索引都得让道!
列式索引的结构比较复杂,详细可见这篇(SQL Server Storage)。在这里提到列式索引,旨在分享,列式索引的存储和压缩优势。
对数据库各项特性了解越多,对待同一问题可用的方法也就越多。所以,我找不到理由,不去通读数据库体系类的书。
责任编辑:武晓燕 来源: 有关SQL SQL面试COUNT(*)
(责任编辑:时尚)
北京汽车(01958.HK)年度净利跌59.4% 每股收益为人民币0.24元
诠释极致速度!全能旗舰iQOO 5 Pro满足你的所有期待 -
华阳股份(600348.SH)公布消息:拟开展应收账款保理业务
一加8T带来不一样的手机体验 8GB+128GB售价3399元 -