长事务:超时与悬挂的处理

  A:START TRANSACTION WITH CONSISTENT SNAPSHOT,读到 v = 0;此刻 History list length = 38
  更新次数 → History list length:15000 → 188,  30000 → 338,  45000 → 488,  60000 → 638
  (History list length 数的是还没清理的 undo 日志单位——每个提交的事务一个——不是行版本的个数;这里每 100 次更新提交一次,所以每 15000 次更新涨 150 左右。真正按着不放的是 6 万个行版本)
  A 的快照读同一行:读到 0(快照里的旧值),单次耗时中位数 13.46 ms;新会话读同一行:读到 60000,单次耗时中位数 0.04 ms —— A 要顺着 6 万个版本的 undo 链往回找到它快照里的那一版
  A 提交之后,purge 线程把 undo 清掉:History list length 回到 1,用了 49.1 s
  A 提交后再读同一行(新快照):单次耗时中位数 0.05 ms

  B 先改了 id=2(成功),再改被 A 锁住的 id=1:等了 1005 ms 后报错 1205 Lock wait timeout exceeded; try restarting transac
  超时之后 B 这个事务还开着吗:innodb_trx 里有 1 条属于它的记录;它自己读 id=2 = 200(第一条 UPDATE 还在事务里,没有被回滚)—— 默认只回滚超时的那一条语句,不回滚整个事务
  如果应用只是捕获了异常、没有 ROLLBACK 就继续往下走并最终 COMMIT:这一半的修改就被提交了,库里 id=2 = 200 (本该和 id=1 的修改一起成功或一起失败)

  1.5 秒时 processlist 里在等元数据锁的会话:[('线程 256', 'Waiting for table metadata lock'), ('线程 257', 'Waiting for table metadata lock')]
  A 提交(事务结束)之后:ALTER 用了 2.03 s 才完成(其中 2 秒是在等 A),后来的普通 SELECT 用了 1.72 s(它本身是 0.1 ms 的查询,却在 ALTER 后面排了队)

  会话 X:BEGIN ISOLATION LEVEL REPEATABLE READ; SELECT ...(之后闲着);别的会话把 churn 表(5000 行)整体 UPDATE 了 5 次,然后 VACUUM:
    tuples: 0 removed, 30000 remain, 25000 are dead but not yet removable
    removable cutoff: 732, which was 5 XIDs old when operation ended
  pg_stat_activity 里 X 的状态: [('idle in transaction', True)]
  会话 X 被服务器断开之后再用它:AdminShutdown
  X 断开之后再 VACUUM:
    tuples: 25000 removed, 5000 remain, 0 are dead but not yet removable
    removable cutoff: 737, which was 0 XIDs old when operation ended
  设置了 idle_in_transaction_session_timeout = 700ms 的会话:事务里闲了 1.2 秒后再用它,得到 IdleInTransactionSessionTimeout: terminating connection due to idle-in-transaction timeout

  20 个事务:15 个提交成功,5 个被 watchdog 中断;watchdog 的记录(线程号、事务年龄 s、已修改行数):[(280, 1.59, 1), (276, 1.59, 1), (272, 1.59, 1), (265, 1.59, 1), (266, 1.59, 1)]
  库里 w 表有 15 行(都是提交成功的 15 个;被杀的事务,修改随连接断开一起回滚),全部是 fast 的:15 行
  只按“开了多久”杀事务会误伤合法的慢事务(比如批处理),所以 watchdog 的阈值、白名单和告警都要按业务定;杀之前最好先告警