新方法不是通用的，如果要求特精确还是使用select count(1),如果是类似分页的，且分页数量超过比较多的，也不是要求特别精准的，这就是一个好方法！
count(1) over 计算记录数
select count(1) over(), * from table_name;
补充
count 是最常用的聚集函数之一，看似简单，其实还是有坑的，如：
1、count(*)：返回结果集的行数，是null也统计
2、count(1)：和count(*)基本没区别，pg92之前都是扫描全表的，pg92之后增加了index only scan一般会变成扫主键索引，如果没有主键或者是表的列很多的情况下，count(1)快一些，因为不会考虑表的全部字段
3、count(field)：返回数据表中指定字段值不等于null的行数
拓展：理解 PostgreSQL 的 count 函数的行为
关于 count 函数的使用一直存在争议，尤其是在 MySQL 中，作为流行度越来越高的 PostgreSQL 是否也有类似的问题呢，我们通过实践来理解一下 PostgreSQL 中 count 函数的行为。
构建测试数据库创建测试数据库，并创建测试表。测试表中有自增 ID、创建时间、内容三个字段，自增 ID 字段是主键。
create database performance_test;
create table test_tbl (id serial primary key, created_at timestamp, content varchar(512));
生成测试数据使用 generate_series 函数生成自增 ID，使用 now() 函数生成 created_at 列，对于 content 列，使用了 repeat(md5(random()::text), 10) 生成 10 个 32 位长度的 md5 字符串。使用下列语句，插入 1000w 条记录用于测试。
performance_test=# insert into test_tbl select generate_series(1,10000000),now(),repeat(md5(random()::text),10); INSERT 0 10000000 Time: 212184.223 ms (03:32.184)
由 count 语句引发的思考
默认情况下 PostgreSQL 不开启 SQL 执行时间的显示，所以需要手动开启一下，方便后面的测试对比。
\timing on
count(*) 和 count(1) 的性能区别是经常被讨论的问题，分别使用 count(*) 和 count(1) 执行一次查询。
可以看到两次查询的速度差别非常大，count(1) 真的有这么大的性能提升？接下来再次运行查询语句。
可以看到第一次查询时候会非常的慢，后面三次速度非常快并且时间相近，这里就有两个问题出现了：
为什么第一次查询速度这么慢？
count(*) 和 count(1) 到底存不存在性能差别？
查询缓存使用 explain 语句重新执行查询语句
explain (analyze,buffers,verbose) select count(*) from test_tbl;
可以看到如下输出：
注意里面的 shared hit，表示命中了内存中缓存的数据，这就可以解释为什么后面的查询会比第一次快很多。接下来去掉缓存，并重启 PostgreSQL。
重新执行 SQL 语句，速度慢了很多。
shared read 表示没有命中缓存，通过这个现象可以推断出，上一小节的四次查询中，第一次查询没有命中缓存，剩下三次查询都命中了缓存。
count(1) 和 count(*) 的区别接下来探究 count(1) 和 count(*) 的区别是什么，继续思考最开始的四次查询，第一次查询使用了 count(*)，第二次查询使用了 count(1) ，却依然命中了缓存，不正是说明 count(1) 和 count(*) 是一样的吗？
事实上，PostgreSQL 官方对于 is there a difference performance-wise between select count(1) and select count(*)? 问题的回复也证实了这一点：
Nope. In fact, the latter is converted to the former during parsing.[2]
既然 count(1) 在性能上没有比 count(*) 更好，那么使用 count(*) 就是更好的选择。
sequence scan 和 index scan接下来测试一下，在不同数据量大小的情况下 count(*) 的速度，将查询语句写在 count.sql 文件中，使用 pgbench 进行测试。
pgbench -c 5 -t 20 performance_test -r -f count.sql
分别测试 200w - 1000w 数据量下的 count 语句耗时
数据大小 count耗时(ms) 200w 738.758 300w 1035.846 400w 1426.183 500w 1799.866 600w 2117.247 700w 2514.691 800w 2526.441 900w 2568.240 1000w 2650.434绘制成耗时曲线
曲线的趋势在 600w - 700w 数据量之间出现了转折，200w - 600w 是线性增长，600w 之后 count 的耗时就基本相同了。使用 explain 语句分别查看 600w 和 700w 数据时的 count 语句执行。
700w：
600w：
根据以上现象推断，PostgreSQL 似乎在 count 的数据量小于数据表长度的某一比例时，才使用 index scan，通过查看官方 wiki 也可以看到相关描述：
It is important to realise that the planner is concerned with minimising the total cost of the query. With databases, the cost of I/O typically dominates. For that reason, "count(*) without any predicate" queries will only use an index-only scan if the index is significantly smaller than its table. This typically only happens when the table's row width is much wider than some indexes'.[3]
根据 Stackoverflow 上的回答，count 语句查询的数量大于表大小的 3/4 时候就会用使用全表扫描代替索引扫描[4]。
结论不要用 count(1) 或 count(列名) 代替 count(*)
count 本身是非常耗时的
count 可能是 index scan 也可能是 sequence scan，取决于 count 数量占表大小的比例
以上为个人经验，希望能给大家一个参考，也希望大家多多支持七叶笔记。如有错误或未考虑完全的地方，望不吝赐教。
