PostgreSQL中带索引的简单查询为何在流量高峰时变慢？

一、先锁定并发与锁争用问题 #

• 实时查锁：高流量慢的时候直接跑heroku pg:locks，重点看那两个慢查询涉及的表有没有长期持有的锁——比如写事务占着行锁/表锁，会把读查询堵在队列里，越积越慢。
• 盯紧事务状态：用heroku pg:ps看state列，要是有idle in transaction的进程，赶紧处理——这类进程占着连接还攥着锁，是拖慢查询的常见元凶。
• 检查连接数上限：跑heroku pg:info看当前连接数和套餐上限，要是接近满额，新查询得排队等连接，自然会超时变慢。

二、排查执行计划的“变脸”问题 #

• 高负载下抓真实执行计划：单独跑EXPLAIN ANALYZE是低负载状态，高流量时PostgreSQL可能因为统计信息过时、内存不够（比如work_mem太小导致排序用磁盘）换执行计划。慢查询发生时，用heroku pg:psql带上生产环境的真实参数（比如实际的用户ID、时间范围）跑EXPLAIN ANALYZE，和低负载时的计划对比差异。
• 更新统计信息：执行ANALYZE <你的表名>，高流量下数据变化快，统计信息过时会让PostgreSQL选错执行计划，导致索引白加。

三、检查数据库资源瓶颈 #

• 看负载指标：用Heroku数据库仪表盘或者heroku pg:metrics盯CPU、内存、磁盘IO——CPU跑满、磁盘IO打满的话，再好的索引也救不了慢查询。
• 核对配置参数：跑heroku pg:settings看work_mem和shared_buffers的大小，Heroku默认配置可能扛不住高流量，比如work_mem太小，查询里的排序、哈希操作落到磁盘，速度直接砍半。必要时升级套餐或者找Heroku调参数。

四、排查应用层的并发问题 #

• 检查连接池配置：看config/database.yml里的pool参数，要是设得太小，高流量下应用得等数据库连接，看起来是查询慢，实际是连接排队。结合heroku logs --tail搜could not obtain a connection from the pool，有这日志就是连接池不够。
• 揪出批量操作和N+1：高流量时，应用层的批量写（比如批量更新）会占满数据库资源，隐藏的N+1查询也会让并发请求下的数据库压力暴增。用NewRelic的追踪看API调用里有没有额外的查询开销。

五、复现问题精准定位 #

• staging环境模拟流量：用ab、wrk这类工具压测staging环境，同时监控数据库的锁、连接、负载，和生产环境的异常情况对比，更容易找到根因。
• 开慢查询日志：跑heroku pg:settings:set log_min_duration_statement=100（记录超过100ms的查询），然后用heroku pg:logs下载日志分析，看慢查询发生时有没有其他查询在抢资源，或者有没有特殊参数导致的慢查询。

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