09 · 运维与发布 · 高峰时的库
报表拖住锁的时候，月台还在等收货
数据库运维看备份、慢查询、主从延迟和锁，保证高峰时收货不会被一条报表拖死。表怎么设计、约束怎么加，是数据库工程师的事。
数据库运维守的是生产库的白天和夜里
数据库工程师设计约束和迁移。数据库运维的特点是在生产上观察这些设计有没有在高峰受伤：慢查询、锁等待、主从延迟、磁盘、备份是否真的完成。他在早高峰前看昨夜的备份，高峰中不跑重报表。业务要的大查询放到从库或低峰，并且从库延迟超过阈值时，报表要标明不是实时，不能用来判断刚才那笔收货成功没有。
变更脚本由他在窗口执行，执行前有备份或可回退的语句。他拒绝「先在生产加个索引试试」。试的语句也要走发布。紧急索引如果确实要加，记入变更，并观察写入有没有变慢。收货变慢会让人连点。
账号和恢复
他和运维工程师一起做恢复演练，重点核对事务是否完整，而不是文件能不能解开。个人账号、最小权限、离职回收同样适用。应用使用的账号密码轮换时，他和 DevOps 一起改配置，不把新密码发在群里。
从库延迟被当成库存
有人把可售查询指到从库。延迟两分钟时，刚收的货还看不见，仓管以为货没到，又收了一次。其实主库已经有了。数据库运维把可售改回主库，报表留在从库并显示延迟。高峰时一条全表对账被他杀掉，改到夜间。当天没有因为报表锁住收货事务。
他把这次等待的语句留给开发，作为缺索引或坏查询的证据，而不是只在现场重启。数据库运维在高峰开始前确认没有未完成的统计任务，高峰结束后再看慢查询排名。排名第一如果是报表，他把它赶去从库；如果是收货，他交给开发，不在生产上先加一堆索引试试。试出来的索引可能让写入更慢，月台会先感觉到。主从切换演练每年至少一次，切换后应用要能指向新主，队列不能丢。只在文档里写可切换、从不切换，故障当天大家都会第一次见这套流程。他每天看一眼昨天最重的十条语句是否变了。排名稳定说明负载可控；突然出现一条全表扫描，多半是新功能或新报表上线。
发现之后他先挡住重试，不让业务连续点，再把语句和执行计划交给开发。连续点同一条重语句，会把数据库 CPU 打满，让无辜的写入一起超时。归档窗口按数据库工程师给出的迁移耗时来排，本岗不在生产上改约束设计。只备在线库、不备历史库，旧单审计会断。他把慢查询和当班业务峰值放在一张图里。叠在一起才知道那条语句是在写入最密的时候变慢。从库延迟超过报表标注范围，报表先降级，不再标成实时数据。表怎么加约束、请求号如何唯一，仍是数据库工程师的设计，本岗只保证高峰时这些设计还能活着。连接数打满时，先限报表会话，不先杀收货会话。备份窗口如果撞上日结，把备份挪到日结结束后半小时，不在生产上把日结改成无锁。归档窗口跟迁移耗时排，不跟感觉排。