第二次优化：业务，先获取rw_bh
得意不能忘形，否则就是被打脸
在上封邮件中，我大肆批判了IDX_TM_RC_PN_BID_BCTYPE_TN_I这个索引，大有“庆父不死，鲁难未已”的决心，而且，还在别人面前显摆：一看就知道是这个索引的问题。
也就在我这有点飘飘然的时候，第三天，又收到了监控邮件，又是这个SQL，这次虽然未超时，但是超过了30秒，已经触发了优化红线。想起上封邮件中说的“不使用IDX_TM_RC_PN_BID_BCTYPE_TN_I索引，可以将性能提升到10秒左右”，虽然当时正值深圳历史最低气温，脸上仍然是唰唰的红彤彤热乎乎。
望着窗外的寒风冷雨，尽量让燥热的自己冷却下来。既然经验被无情的打败，那只能耐着性子从零开始，重新审视这个SQL及其执行计划。上面提到过，这是一个头轻脚重型的SQL，按道理，这个SQL的执行计划应该不复杂，但是重新审视这个执行计划，却扭扭捏捏72行，这说明在where条件中存在着大量的子查询。果不其然，在执行计划中显示了一个比较大的filter，而在这个filter里面出现了两个引人注意的地方：
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/693533/viewspace-1983398/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
