MySQL RDS中count(*)查询性能过慢，PostgreSQL是否更高效？

1. 280万行表COUNT(*)跑一分钟，这合理吗？ #

当然有可能，哪怕你的执行计划显示已经在Using index（用了覆盖索引，不用回表查数据）。结合你给出的执行计划，这里用的是IDX_91F547DA98AFEB75这个二级索引，几个关键原因可能导致慢：

• RDS实例资源不够：如果你的实例规格偏低（比如内存小、CPU性能弱），扫描索引时可能频繁读磁盘而非命中缓存，速度会被拖慢。尤其是内存不足时，数据库没法把整个索引放进内存，只能反复从磁盘读数据。
• 索引碎片太多：要是这张表经常做插入、更新、删除，二级索引很容易产生大量碎片，扫描的时候要读更多磁盘块，自然变慢。
• 存储IO瓶颈：如果用的是GP2存储，当IOPS达到上限后，磁盘读写速度会暴跌，大索引的扫描肯定受影响。换成GP3或者IO2能缓解这个问题。
• 并发干扰：如果此时有大量写入或者其他大查询在跑，抢占了CPU、IO资源，COUNT(*)的执行速度也会打折扣。

2. PostgreSQL做相同查询会高效很多吗？ #

不一定，但多数场景下确实会表现更好，核心是两者的实现逻辑差异：

• 并行扫描支持：PostgreSQL在合适的配置下，会用多个CPU核心并行扫描索引，这对大表COUNT()的提速非常明显；而MySQL的并行查询支持有限，尤其是在InnoDB引擎下，COUNT()基本是单线程扫描。
• 近似计数更靠谱：PostgreSQL的pg_stat_user_tables里的n_live_tup字段，能给出非常接近真实值的行数统计，查询这个几乎是瞬间的；MySQL的information_schema.tables里的TABLE_ROWS也是近似值，但准确性往往不如PostgreSQL，而且很多场景下大家需要精确值。
• 索引扫描效率差异：PostgreSQL对覆盖索引扫描的优化更到位，在资源充足的情况下，哪怕是单线程扫描，速度也可能比MySQL快一些。
• 但也要看场景：如果PostgreSQL的实例资源同样受限，或者索引一样有严重碎片，那耗时也不会低。另外，两者都没有像MyISAM那样存储精确总行数，都需要扫描索引来获取精确计数，只是PostgreSQL的优化更胜一筹。

给你的MySQL优化小建议 #

• 先查资源监控：去RDS控制台看看CPU、内存、IOPS的使用率，要是有瓶颈，升级实例规格或者换更好的存储类型。
• 整理索引碎片：可以试试重建索引或者优化表（注意锁表风险，最好在业务低峰期做）：

  ALTER TABLE data_sample ENGINE=InnoDB;
  -- 或者
  OPTIMIZE TABLE data_sample;
  

• 用近似计数替代（如果业务允许）：直接查系统表拿近似行数，速度超快：

  SELECT TABLE_ROWS 
  FROM information_schema.tables 
  WHERE TABLE_SCHEMA = '你的数据库名' 
    AND TABLE_NAME = 'data_sample';
  

• 换更小的索引扫描：InnoDB会自动选最小的索引来做COUNT(*)，如果有比IDX_91F547DA98AFEB75更小的索引（比如单个小字段的非空索引），会更快。没有的话可以建一个：

  CREATE INDEX idx_for_count ON data_sample (id); -- 假设id是非空主键，或者其他小体积非空字段
  

内容的提问来源于stack exchange，提问作者olidem