是否应将表记录数存储在另一张表中？接手项目后的技术咨询

我刚好之前做过类似的需求，来聊聊这两种方案的优劣和适用场景吧：

一、直接使用COUNT(*)的方案 #

优点 #

• 简单省心：不需要额外的表结构和同步逻辑，一行SQL搞定：SELECT COUNT(*) FROM Table1
• 数据绝对准确：直接读取表的真实记录数，不会出现统计值和实际值不一致的情况
• 无需维护成本：不用考虑插入/删除/更新操作对统计值的影响，数据库自身会处理统计逻辑

缺点 #

• 性能瓶颈：如果表的数据量达到千万级甚至更高，且没有合适的索引优化，COUNT(*)的查询速度会明显变慢；要是高并发的展示场景，频繁调用会给数据库带来不小的IO和CPU压力
• 数据库差异：不同数据库对COUNT(*)的优化程度不同，比如MySQL的InnoDB引擎需要遍历主键索引统计，而MyISAM会直接维护总行数字段，两者性能差异很大

二、用storageTable同步计数的方案 #

优点 #

• 查询速度极快：只需要简单的SELECT Table1 FROM storageTable就能拿到统计值，完全适配高并发、低延迟的展示场景
• 降低主表负载：避免了频繁对大表执行COUNT(*)操作，减少主表的资源消耗

缺点 #

• 同步逻辑复杂：需要在插入、删除、甚至软更新（比如标记删除）操作时，同步更新storageTable的对应列值，稍有疏忽就会出现统计值与实际值不一致的问题
• 事务一致性风险：如果主表操作和计数更新不在同一个事务中，可能出现主表插入成功但计数没更新，或者计数更新了但主表操作失败的情况
• 额外维护成本：需要监控统计值的准确性，还要处理异常场景（比如批量操作、异步任务失败）的补偿逻辑

三、方案选择建议 #

• 如果你的数据量不大，或者对统计准确性要求极高（比如财务类核心数据），直接用COUNT(*)更靠谱，现在多数数据库对COUNT(*)都有针对性优化，小表场景完全不用担心性能问题
• 如果是大表+高并发展示场景，且可以接受极少量的统计延迟或偶尔的不一致（后续可通过定时任务修正），那现有同步方案更合适，但要做好这些优化：
  • 把主表操作和计数更新放在同一个事务里，保证原子性
  • 批量操作时直接批量更新计数（比如批量插入100条，执行UPDATE storageTable SET Table1 = Table1 + 100），避免循环更新带来的性能损耗
  • 定时跑校验任务：比如每天凌晨执行SELECT COUNT(*) FROM Table1，与storageTable的数值对比，修正不一致的情况

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