上个周五(3月28日)，北京阴雨绵绵的那天，接到用户的服务请求协助，中国建设银行的数据中心出了点问题。跨越大半个城市，从东到西，赶到用户现场。
了解了一下用户情况，是一段用于月结的UPDATE SQL出现了性能问题，本来40分钟左右的执行时间，现在突然延长到了4个小时左右。使得原本能够按时完成的任务现在看起来遥遥无期（因为有很多批处理要执行）。
而建行月底的财报要靠这个SQL，所以问题看起来很紧急，后果可能很严重。
仔细检查用户的SQL、执行计划以及系统的Statspack报告及当前等待事件，发现系统大多数的等待消耗在
db file sequential read 等待事件之上，而检查这个事件发现读取在不同的索引文件之间来回跳转。
此时系统资源消耗很低，128G内存，64颗CPU，IO负载同样极低。
执行计划中，SQL在一个7亿记录和2亿记录的表之间进行HASH JOIN SEMI，执行计划并没有问题，问题在于I/O无法充分利用，系统资源无法充分利用。
通过进一步判断，强烈建议用户重建一个15G的索引，第二天早上收到用户的报告，系统一切恢复了正常。
-The End-
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
