聊聊PostgreSQL里那些等待事件到底是啥玩意儿，怎么影响性能的感觉

聊聊PostgreSQL里那些等待事件到底是啥玩意儿，怎么影响性能的感觉

咱们用个生活中的例子来开头，你把PostgreSQL数据库想象成一个特别忙的政府部门，比如车管所，数据库的CPU就像是办事窗口，而数据就是一堆堆的档案和文件，有的放在窗口后面的架子上（内存），更多的则存放在后面巨大的档案库里（磁盘）。

“等待事件”说白了就是来办事的人（也就是数据库正在处理的每个SQL查询任务）因为某种原因卡住了，没法立刻在窗口办业务时的那个“等待原因”，性能好不好，关键就看这些等待事件多不多，每个事件等了多久，如果大部分人去了就能直接办，那效率就高；如果大厅里挤满了人，都在因为各种奇葩原因干等着,那整个系统的速度就慢下来了。

根据PostgreSQL官方文档和一些常见的性能分析资料（比如PgBadger报告、pg_stat_activity视图），这些等待事件可以分成几大类,咱们一类一类掰扯。

第一类：和IO相关，等硬盘干活（I/O Wait Events）

硬盘（特别是机械硬盘）是电脑里最慢的部件之一，比CPU和内存慢成千上万倍,很多等待都是因为它。

• 等读数据（DataFileRead）： 这最常见，办事员需要一份档案来办理业务，但这档案不在手边的架子上（内存里没有），得派人去后面的档案库（磁盘）里取，这个“派人去取”等着拿回来”的过程，就是DataFileRead等待，如果你的查询总是要读很多不在内存里的数据，那就会大量出现这种等待，感觉就是，查询变得巨慢,硬盘灯狂闪。
• 等写数据（DataFileWrite）： 办完业务，有些档案信息需要更新，写回档案库，这个“写回去”的过程也需要时间，虽然PostgreSQL有巧妙的机制（WAL、脏页刷盘）来减少直接写数据文件的等待，但写入量巨大时，它还是会成为瓶颈，感觉就是，当你做大量插入、更新、删除操作时，系统响应变慢,磁盘写入流量很高。
• 等写日志（WALWrite）： 这是PostgreSQL一个非常核心的机制，叫预写式日志，你可以理解为，任何对档案的修改，办事员都必须先详细地记录在一本“变更流水账”（WAL）上，然后才能去实际修改档案，这么做是为了保证数据安全，万一系统崩溃，可以根据流水账恢复，等写日志就是办事员在等着把流水账记录抄写完毕，如果流水账写的慢（比如磁盘慢），那么所有修改数据的操作都得等着，感觉就是，整个数据库的写入操作都被拖慢了,像是遇到了一个共同的瓶颈。

第二类：和锁相关，等别人干完活（Lock Wait Events）

档案就一份，不能两个人同时改，不然就乱套了,锁就是用来协调这个的。

• 等表锁（RelationLock）： 好比说，有个业务需要把整个“车辆型号表”这本大册子从头到尾整理一遍（比如建索引），在这个过程中，这本册子会被锁住，这时候，另一个想来查一下某个车型信息的人，就得等着，直到整理工作完成，这就是等表锁，感觉就是，某个平时很快的查询，突然卡住了，一看是因为有个后台维护任务（如VACUUM FULL、CREATE INDEX）正在锁着表。
• 等行锁（TupleLock）： 更细粒度一点，比如两个人同时想修改同一辆车的车主信息（同一行数据），第一个人先拿到了锁正在改，第二个人就只能干等着第一个人改完提交，在高并发修改同一条数据的场景下（比如抢购商品库存），这种等待会非常严重，感觉就是，系统并发量一高，响应时间急剧上升，但CPU和IO都不忙,就是因为进程都在互相等待。

第三类：和内部资源竞争相关，等自家资源（LWLocks Wait Events）

这类锁更底层，是数据库内部管理各种共享资源用的,比如共享内存的某个区域。

• 等缓冲池锁（BufferLock）： 咱们之前说的那个放常用档案的架子（共享缓冲池），是大家共用的，当一个进程想在架子上找或者放一份档案时，它需要先短暂地“占住”那个档案的位置，防止别人同时操作搞乱，这个“占住”的动作就需要获取BufferLock，如果非常多的人同时疯狂地访问不同的数据页，竞争这个锁就会成为问题，感觉就是，硬件配置很高（CPU多、IO快），但性能就是上不去，有种“内耗”的感觉。
• 等WAL写相关的锁（WALWriteLock）： 和上面的WALWrite相关，多个进程都想往那本“流水账”上写记录，但一次只能一个人写，所以需要锁来排队，高并发写入场景下,这里也可能拥堵。

第四类：和CPU相关，纯粹忙不过来（CPU Wait Events）

这不算“等待事件”，而是“非等待状态”。

• CPU忙（CPU）： 当你在监控中看不到上面那些等待事件，而活动状态显示为“CPU”时，这说明进程正在窗口前疯狂办事，CPU已经满负荷运转了，这时候的瓶颈就是CPU的计算能力本身，感觉就是，系统响应慢，但磁盘IO不高，锁竞争也不激烈，top命令一看CPU使用率100%，这说明你的查询可能太复杂,需要优化SQL或者升级CPU了。

总结一下怎么影响性能的感觉：

• IO等待多： 你的感觉是“磁盘灯闪个不停，查询慢得像蜗牛”，解决办法可能是加内存（让更多数据缓存在内存里）、换更快的硬盘（SSD）。
• 锁等待多： 你的感觉是“系统感觉卡卡的，有时候突然好一下又卡住”，并发越高越明显，解决办法是优化事务（尽快提交）、避免长事务、调整隔离级别、优化SQL减少锁持有时间。
• LWLocks竞争多： 你的感觉是“硬件没吃满，但性能就是不行”，比较难排查，可能需要调整PostgreSQL的内部参数（如shared_buffers, max_connections等）。
• CPU忙： 你的感觉是“系统整体负载高，CPU跑满了”，解决办法是优化消耗CPU的复杂查询、建立合适的索引、升级硬件。

下次当你觉得数据库“慢”的时候，别光猜，去看看等待事件，它就像车管所里的投诉记录本，清楚地告诉你：大家到底都在等什么，找准了等待的原因，才能对症下药,真正解决性能问题。