评论区：Ruby建站优化的隐形引擎

　　2025年7月12号下午三点零七分，我盯着后台日志里那条重复出现的 Comment::LoadFailed (timeout: 3.1s)，手还在敲键盘，嘴里叼着半截没点的烟——烟盒是上周在新宿站买的，薄荷味，但其实我早戒了，就图它捏在手里有点事干。

　　那是我们给“茶山读书会”做评论区重构后的第七天，Ruby 3.3 + ActiveRecord 7.2 + PostgreSQL 16，用的是自己写的 commentable_polymorphic_cache 补丁，缓存逻辑全在 model 里跑，没动 Redis。一切看起来很稳，直到那天中午开始，每过四十来分钟，就有一个用户发不出评论，前端报 502，Nginx 日志里写得清清楚楚：upstream timed out (110: Connection timed out) while reading response header from upstream。

　　我原以为是数据库连接池撑不住了，把 pool: 25 拉到 40，又加了超时兜底重试——结果更糟，第八次部署后，连首页都开始卡三秒。运维小王蹲我工位边啃饭团，忽然说：“哥，你查过 comments 表的 created_at 索引没？”我一愣，他扒拉出 psql 说：“你昨天删的迁移文件，add_index :comments, :created_at，删得挺干净。”

　　我手抖了一下，点开 Git 历史——真删了。不是我删的，是实习生小陈，他合了 PR 后顺手清理“冗余索引”，觉得 commentable_type 和 commentable_id 已经有复合索引了，“单列 created_at 肯定没人查”。我看着那行 drop_index :comments, :created_at 的提交信息写着“clean up unused index”，忽然想起上周五客户老李站在投影仪前，手指戳着大屏上的“最新评论”模块，说：“这个‘最新’，是不是真的最新？别拿排序糊弄人。”

　　——我原以为他是在质疑时间戳精度，结果他要的是物理意义上的实时性：刚发完，立刻进流，不排队，不缓冲，不延迟渲染。而我们的 scope :latest, -> { order(created_at: :desc).limit(20) } 在没索引时，PostgreSQL 对一百二十万条评论全表扫描了八百多次。每次扫，平均耗时 3.08 秒。刚好卡在 Puma worker 的 timeout 阈值上。可笑的是，缓存层根本没机会触发，请求全死在 active_record.finder 那一层，像被钉在门框上的蝉蜕，空壳还在动。

　　小王吃完最后一口饭团，把竹签往杯子里一插，说：“你看这根签子，斜着插进水里，是不是看着弯的？但水底下它没弯。”——他不是在讲光学，就是在说我们写的 scope 逻辑。我嗯了一声，把烟盒扔进抽屉，没点火。

　　改回去花了十一分钟：加索引、重启 puma、等三轮健康检查绿掉。之后那整个下午，再没出现一次 502。所有评论都准时落进列表里，按秒排序，毫秒级偏差。没人欢呼，也没人发 Slack 通报，只有老李在凌晨一点二十三分，默默点了个“赞”，是他注册三年来第一次点赞。

文章配图，仅供参考

　　后来我翻代码，发现那段 scope 其实从 2018 年就在那儿了，只是过去七年，表数据一直压在八十万条以下，没撞上临界点。而“优胜劣汰”这事，从来就不是靠测试覆盖率或者 CI 流水线判的，是真实用户点下“发送”那一瞬间，服务器喉咙里发出的第一声闷咳。

　　（冰箱贴掉下来过两次，一次是周三下午，一次是周五早餐前；我同事阿哲的左手小指上有个淡褐色胎记，形状像半枚旧邮票）

　　有谁碰到过这个吗——加了索引还是慢，explain 显示走了 index scan，但实际执行就是卡在 2.9~3.2 秒之间，上下浮动不超过两百毫秒，像钟摆一样准？

（编辑：航空爱好网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!