SQL代码执行ALTER TABLE后挂起，如何分析原因及逐行排查？

• 表存在未提交事务：其他会话对subscription_kits表执行的SELECT/UPDATE/DELETE等操作未提交，ALTER TABLE需要等待这些事务释放锁才能继续。
• 表数据量过大：部分数据库（如旧版本PostgreSQL）在大表上添加列时需要重写整张表，耗时极长会表现为“挂起”。
• 锁竞争：其他会话持有该表的排他锁或共享锁，ALTER TABLE所需的锁无法获取，进入等待队列。
• 数据库资源不足：CPU、内存、IO被其他任务占满，ALTER操作无法分配到足够资源执行。

另外你的UPDATE语句存在潜在问题：

• WHERE子句的type = 'redeemed'未指定表，若subscription_kits也有type列会导致逻辑错误；即使没有，也应该明确写c_e.type = 'redeemed'保证可读性。
• 缺少subscription_kits与customer_events的关联条件，这会让subscription_kits的每一行匹配所有符合type='redeemed'的customer_events行，最终更新结果随机，且数据量大时会导致操作极慢甚至假死。

• 先单独执行ALTER语句：

  alter table subscription_kits add column first_subscription_kit_redemption DATE;
  

  如果这一步挂起，直接查数据库锁状态：
  • PostgreSQL：SELECT * FROM pg_locks WHERE relation = 'subscription_kits'::regclass;
  • MySQL：SHOW ENGINE INNODB STATUS;
    查看是否有其他会话持有锁阻塞了ALTER操作。
• 若ALTER执行成功，再单独处理UPDATE：
  1. 先补全语句的逻辑漏洞，比如添加关联条件（示例，需根据实际业务调整）：

     update subscription_kits sk
     SET sk.first_subscription_kit_redemption = c_e.updated_at
     FROM customer_events c_e
     WHERE c_e.type = 'redeemed' AND sk.id = c_e.subscription_kit_id;
     

  2. 先执行对应的SELECT语句验证结果范围：

     SELECT sk.id, c_e.updated_at FROM subscription_kits sk
     JOIN customer_events c_e ON sk.id = c_e.subscription_kit_id
     WHERE c_e.type = 'redeemed';
     

     确认返回行数是否符合预期，避免全表更新。
  3. 执行UPDATE时监控数据库资源（CPU、磁盘IO、连接数），排查是否是资源瓶颈导致的慢操作。

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