Spike报告

作者：李莉

时间盒：9月18日、9月19日，共 2 天

问题：生产低峰给预订表加索引会锁多久

日期：0000-00-00

结论：低峰可做，预估锁表约 1 秒

一、结论

两天的时间盒结论是：行政协同平台生产预订表当前 1.8 万行，在 21:40 这种低峰加联合索引，锁等待约 1 秒，可以安排进 9月26日窗口。用预发灌到 80 万行模拟六地一年数据时，同一条语句用了 6 分 10 秒。因此生产现在能做，数据量上来之后要改用分批建索引。张伟按此结论批准低峰窗口。

二、验证问题

预订创建要按会议室、日期和开始分钟判断冲突。现有索引只有会议室编号。问题有三个：生产现有行数加索引会不会堵住 21:40 的正常预订；预发大表要多久；从库延迟会升到多少。时间盒不实现业务代码，只在数据库上验证语句。

三、做法

1. 9月18日在预发复制一份 1.8 万行的表，执行加索引，记录锁等待和 CPU。
2. 9月18日下午把副本灌到 80 万行再执行一次，中间不打断。
3. 9月19日在预发从库观察复制延迟，并在加索引期间用 2 QPS 模拟低峰预订。
4. 生产只做说明，不在时间盒内对生产执行语句。

四、结果

大表实验时李莉主动暂停了写入，所以那一行的预订结果写成暂停，不能当成生产低峰的证据。生产估算以小表和低峰回放为准。

五、建议

9月26日 21:40 在生产执行联合索引，陈静值守延迟。若从库延迟超过 5 秒，停止后续语句，已经建成的索引保留。80 万行的做法留到六地数据真正接近这个量级时再设计，不放进本月窗口。刘洋据此安排应用侧的上线说明，王芳在索引完成后抽 3 间会议室的冲突查询。李莉把两次预发的耗时和延迟写进变更单，供 9月26日当晚对照。时间盒实际投入李莉 2 天，刘洋旁听了 9月19日的低峰回放。