今天线上有个服务出现了大量的慢SQL 导致IOPS大幅抖动
执行计划SQL:
SELECT DISTINCT stc.USER_IDFROM t_signin_teacher_info stcWHERE stc.SID = 'oi3v3kHNMHoNqxXW9Qa'AND stc.TYPE = 1AND stc.CREATE_TIME >= '2018-12-04 00:00:00'AND stc.CREATE_TIME < '2018-12-04 24:00:00'
从执行计划上看 优化器选择的索引 并不是我们想要的. 最优的应该是索引: idx_sid_ctime
为什么会这样?
查看优化器的执行过程上图OPTIMIZER_TRACE 可以看到优化器针对"idx_ctime_optype"和"idx_sid_ctime"两个索引的分析结果 其'cost'是一样的 所以选择了较前的"idx_ctime_optype".
但是很奇怪 为什么`SID` + `CREATE_TIME`索引耗时会和单个`CREATE_TIME`一样长呢?
故而 留意到优化器在进行索引筛选时 `CREATE_TIME`字段的条件只有一半: "2018-12-03 00:00:00 <= CREATE_TIME"(下界)
"CREATE_TIME < '2018-12-03 24:00:00'"(上界)消失了怀疑是日期格式有问题.
因此 将"CREATE_TIME < '2018-12-03 24:00:00'"改为:"CREATE_TIME < '2018-12-04 00:00:00'"
查看执行计划和OPTIMIZER_TRACE正常了
优化后的至此 已经可以很明确 这个慢SQL的原因是传入的日期'2018-12-04 24:00:00'不合法 而被查询优化器自动忽略了
网友评论