前天14号下午紧邻下班的时候，突然收到告警，主机CPU被打满，使用率超过96%。
登录数据库后检查了下数据库当前正在运行的SQL情况如下：
这里发现，主zone两个节点的活跃回话数已经上线，1000+，这种情况主机CPU不打满才怪。
查询了当前的问题表的执行计划信息，发现如下计划，其中有一个计划是全表扫描
通过后台监控监本获取到的业务第一次计划突变的信息，发现T表执行为全表扫描
这里请注意下param_info列，如果有经验的dba，从这里可以判断业务传空值了
分析判断该业务为什么执行计划突变
–这里通过获取sql_audit里面的变量信息，发现全表扫描的业务都是中间值传的为NULL
–其实我理解，这里的值，应该是驱动自动给补齐了一个null，用来规避语法的解析错误，我们看标记的后两个值，业务可能就中间第二个变量没有传值。
反馈给业务传空导致的计划突变，业务手工测试执行很快，没有问题，如果细心，也一定能看到上图中执行计划虽然是全表扫描，但单次耗时仅仅4ms
这里我通过如下测试，解析说明为什么上面执行计划显示的是T表全表扫描，但实际耗时4ms
–先实际执行下SQL语句，并获取trace_id
–通过montor视图来查询真实的计划
–这里可以发现starts为0，说明ob在执行该SQL的时候，一次扫描都没有执行，仅仅是礼貌性的解析了下计划，发现传入空值，直接返回了空行，所以超级快。
那么为什么业务传空之后，会导致主机CPU异常，出现真正意义上的全表扫描呢？可能有如下两种原因：
1.可能在某些场景下，ob的处理逻辑和手工调用传空不一致，业务传空后，生成全表扫描计划后，确是执行了全表扫描动作
2.传空导致生成的计划为全表扫描，传空的SQL语句并未实际执行，只是解析了下，但是其他的非空语句复用了传空值生成的全表扫的计划。
上述分析思路非官方，野路子，仅供参考。
