1：问题描述
上午9点，收到短信告警，某个业务系统的OB租户CPU使用率超过90%，登录OCP管理工具，发现是一个性能问题SQL导致，紧急对相关租户在线扩容，性能问题暂时得到缓解。
SQL文本如下：为了易于理解简化了SQL
2：问题分析
2.1：部署架构
● 生产OB架构采用3副本的分布式架构部署
2.2：查看SQL执行计划
通过执行计划可以看出，OB优化器选择了ctype字段对应的索引，而没有选择我们认为的cust_id字段索引，难道没有cust_id索引？
● 查看OB版本
● 查看表定义
● 查看ctype字段数据分布
通过表结构可以看出ctype和cust_id字段上都有索引，通过查看ctype的数据分布，发现只有几个不同值，其实是不太适合创建索引的。可是为什么OB非要走ctype字段的索引哪？是不是统计信息不准？手工执行统计信息收集。
2.3：收集统计信息
● 查看列统计信息
● 手工收集统计信息
● 再次查看执行计划
• 可以看出执行计划依然没有变化。
2.4：调换IN前后元素顺序
通过SQL文本发现ctype字段其传入的值基本上在表里不存在，只有最后1个值才有数据，难道是绑定变量窥视的问题？将传入的值的顺序调换下，看能否选择正确的索引。
调换ctype中传入的元素顺序，将2前移到第一位（ctype等于2的数据有32万）。可以看到选择了正确的cust_id字段索引。同时发现发现OB估算的记录数也相对来讲比较符合预期了。
2.5：OB 4.2版本情况如何
通过咨询OB工程师，确定OB 3.2版本上的优化器在索引估行方面存在缺陷，在OB 4版本后有了一定的改善。为此将相关测试数据导入到OB 4.2上进行了测试，发现OB 4.2的执行计划是正确的，没有像OB 3.2那样存在差异。
3：问题总结
总结一：删除不必要的索引。
例如：对于选择性不高的字段，不建议创建索引。此次问题，如果删除ctype字段上的索引，也不会出现这个问题，所以索引不是越多越好。
总结二：IN元素的顺序也能影响执行计划。
从这个案例上，可以看出影响OB执行计划的因素有很多，对于复杂的SQL，可能通过Hint固化执行计划会是一个不错的选择。
总结三：新版本的优化器更佳。
从这个案例我们也可以看出，OB优化器的迭代更新还是做了很多优化的，也让我们对OB的未来充满期待。
结论四：OB租户的扩容是实时生效的。
生产环境要给集群预留充足的资源，在遇到某个租户资源不足时能够快速的扩容，防止业务系统的故障。
