COUNT(*)是每个初学者的最爱，但凡漂亮的按下回车时，看着转啊转的进度条，总是有种莫名的喜感。平时总被老板催着干这干那，现在我也能指挥下电脑帮我跑跑数据！
虽说平时面试官总爱问 COUNT(*) 有什么坏处啊，为什么要避免使用 COUNT(*) 这类怪问题。真要说起来，他们也是一脸懵圈，因为面试题都有可能是网上随便摘的。
至于原理，多少人真正懂呢，真正在乎呢？
那么，COUNT(*)的性能真那么差吗？怎么才能提高性能呢！今天就盘它
已知 SQL Server 中有这样张表 (其他数据库也适用):
代码语言：javascript复制
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)
这张表没有索引，是张堆表(Heap Table). 总共有4000多万条数据。
第一次，运行 count(*)
代码语言：javascript复制SELECT COUNT(*) AS CNT
FROM dbo.MobileLink
可以看到运行大约花了 3 秒时间 执行计划也简单，走了全表扫描
万能的性能杀-索引
我之前也分享过，数据是存在数据页上的。这个数据页可以看做是一页纸。在纸上把字写得越紧凑，得到的信息越多。反之，如果你把字写得够大，行与行之间又很松散，每页纸能容纳的信息量也就少了。
于是，像这样全表扫描的效率就很低，理论上，只要把每页上，每一行的第一个字段统计下，就能知道有多少行了。于是索引就排上用场了。
第一个提高性能的方案就出来了，建一个索引
代码语言：javascript复制
CREATE INDEX IDX_USR_ITEM ON dbo.MobileLink(user_id,item_id) ;
执行计划如我所料，肯定走索引
总耗时2.036s 比刚才 3s 好上一丢丢。
经常看到网上有贴发表，count 单列(如 count(user_id) )会比 count(*) 有优势，果真如此吗？
代码语言：javascript复制
SELECT COUNT(user_id) AS CNT
FROM dbo.MobileLink
2.813s 对 2.036s , 并无优势。
快上加快-压缩
那么按照刚才的思路，现在已经取 user_id , item_id 作为统计基数了，那么是不是还有办法可以更小？对，那就是压缩
代码语言：javascript复制ALTER INDEX IDX_USR_ITEM ON dbo.MobileLink REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE);
执行上面压缩语句，再运行 count(*). 对比结果与执行计划
耗时已经进入1s级，又进一步。
再反观，使用单列（ COUNT(user_id) ）来统计行数：
依旧在2s级徘徊！
可见， COUNT(USER_ID) 并无优势！
SQL Server: 我还可以更快
还有更快的方法，列式索引。它的优点除了节省空间外，还外加压缩，双重优化。
代码语言：javascript复制CREATE NONCLUSTERED COLUMNSTORE INDEX COL_IDX ON dbo.MobileLink(user_id,item_id) ;
已经破1s 级。在列式索引面前，其他索引都得让道！
列式索引的结构比较复杂，详细可见这篇（SQL Server Storage）。在这里提到列式索引，旨在分享，列式索引的存储和压缩优势。
对数据库各项特性了解越多，对待同一问题可用的方法也就越多。所以，我找不到理由，不去通读数据库体系类的书。
--完--
