迁移确认
为什么如今添加带默认值的列可以很快完成？
- 如今磁盘足够快，重写整张表很快就能完成
- 从 PostgreSQL 11 起，默认值只需记录在元数据中
- 通过多个 CPU 核心并行处理
- 因为写入时会压缩数据页
尽管如此，为什么数据库迁移仍然危险？
- 变更操作本身耗时很长
- 会占用大量磁盘空间
- 等待锁时，后续所有查询也会排队
- 会导致复制延迟加大
发生上述排队情况时，数据库指标通常怎样？
- CPU 达到 100%
- 磁盘被占满
- 内存不足
- 看起来正常——单条查询的执行速度仍然很快
lock_timeout 与 statement_timeout 有什么区别？
- 两者实际上是相同的设置
- 前者的默认值更长
- 前者只作用于读取查询
- 前者限制等待锁的时间，后者限制语句执行时间
CREATE INDEX 会阻塞什么操作？
- 写入（INSERT/UPDATE/DELETE）
- 读取（SELECT）
- 读取和写入
- 什么都不会阻塞
CREATE INDEX CONCURRENTLY 有什么限制？
- 不能在事务中执行；失败时可能留下不可用的索引
- 没有特殊限制
- 生成的索引比普通方式创建的索引更大
- 索引的准确性会降低
如何找出失败的 CONCURRENTLY 操作留下的索引？
- 在服务器日志中搜索失败记录
- 用 EXPLAIN 检查索引是否被使用
- 在 pg_index 中查找 not indisvalid
- 重启服务器后它会自动清理
删除列时为什么要分阶段部署？
- 一次删除会耗费很长时间
- 仍在运行的旧代码可能读取该列并报错
- 会产生长时间的锁
- 会导致复制延迟