encro

pg 100 万数据，select count(*)和 select count(id)也都是一样的索引，一样的 200ms ，刚试过的。

所以：

不要相信关系性数据库 count 能快，是要实际排序计算的。

不要相信数据库工程师很菜，不会自动分析走哪个索引，明明有更优化的索引不走，走个慢的。

@wangxin3

这个特性好像是 20 年前的 myisam 引擎的，不是 innodb 引擎的。

@wangxin3

对不起，我用的 mysql8.17 没有这个功能。
explain
两个走的是一样的索引。
同时走了一个 tinyint 的索引。
你可以在线上试一下看。

@cy1027


就是 navicat 自动给你加了 limit...
然后他的统计是来自 infomation 表的大概统计，如果你仔细看前面有一个约等于符号，我没有记错的话。

你直接用命令行 select * 看看，一片跑一边看 show full processlist ，几十万数据 send data 状态都要几秒吧。

数据库的耗时有几个阶段：

查询解析：分析关系，走哪个索引？
取数据：内存（走了索引）或磁盘（没走索引）？
预处理结果：排序或格式化等，走了内存或者临时表？
发送数据：发数据到客户端，结果集大肯定慢了

结合慢查询，processlist 和 explain 可以发现并解决问题，如果是我前面的问题，基本无解。

如前面所说，我刚才试了下，在我的阿里云小 rds （ 1 核）上，900 多万数据无论是 select * 还是 id ，都需要一分多钟，两者走的是同样的索引，所以实际项目我都是加了条件限制的，默认只查当个月数据，用户加日期建立了组合索引，不让用户直接翻页到最后一页。

一定要精准电量显示，
底盘重一点，没有那么漂，
大一点买菜方便，解锁速度能上来，小一点不能解锁，因为太漂了。

关系数据库几个很多无法解决的问题：

1,count 慢
2,order by xxx limit 1000000,10 （取最后页的慢）
3,like “%xxx”慢
4,没有合理建立索引慢
5,自动更新物理试图
6,。。。

以上等等限制才会有 es,mongo,hbase,redis,InfluxDB,GDB 等等的机会。以上导致关系数据库没有走主键索引的话也就千万级别数据量比较合适吧。如果都是走主键那随便放。

navicat 的统计自动走了统计表，不是准确的。

count 是必须准确的，而且是需要考虑脏数据。

没有优化方法途径。count 就是慢。order by 也是慢

如果想就职，那么选择前端，研究 js 和 ts 也能达到 2w ，就业对学历不严，而且岗位 10 倍。