如何解决程序时快时慢的业界性能难题--技术人生系列第二十九期-我和数据中心的故事

一个常见的经典问题，也是一个难缠的业界难题，基于oracle的程序时快时慢，很多资深的DBA面临这个问题也是束手无策，没有一个最优的解决方案。如果你的数据库正经历各种性能问题，不妨联系中亦科技试一试，看我们如何解决你的数据库忧虑。

                                        ----中亦科技老猫（陈宏义）

问题来了

倾斜就“歪”呗

简单说，使用绑定变量情况下，如果关键条件上数据分布严重倾斜，生成执行计划时，绑定变量窥视到一个数据量非常小的值，cardinality为1，此时执行速度一般会很快，当用这个执行计划执行到拥有300万行数据的值的时候，性能就严重下降。这就是“歪”。之所以“歪”是因为使用绑定变量的话，避免了重复解析，只有第一次生成执行计划时的代入值是能偷窥到的，也就是说只有一个执行计划。而这个案例里，数据分布不均，STATUS='INVALID'时走索引合适，STATUS=‘VALID’时走全表合适。这时总有一个执行计划是不好的，这就是经典的时快时慢的性能难题。

这里解释下cardinality，如果按照前面的例子：一个学校，男女比例严重失调，男生有99990人，女生有10人，那么，查看所有女生的cardinality为：100000*(10/100000)，所有男生的 cardinality为100000*(99990/10000)

第三步过滤条件为"T1"."STATUS"=:B1的E-ROWS（评估行数）和A-ROWS（实际行数）相差非常大，直接导致CBO选择使用nested loop进行连接。那为什么会出现这种现象呢？原因很简单，生成执行计划的绑定变量B1的值是'INVALID'，这个列上的数据分布倾斜非常严重。STATUS的值为'INVALID'只有16行，而值为VALID的数据占了绝大多数1132K。所以，我们一般建议开发人员在这样的条件上，不要使用绑定变量。

解决方案

菊花保卫战

SQL Plan Baseline配置

accept：

SQL_PLAN_gd8s9vjf5z9t89e2752cc这个plan，这样我们就接爱了两个plan了，就是说在每次SQL执行时，CBO会recost一下，决定用哪一个plan来执行当前的SQL。

测试验证

老猫说：

在GCS时每天都有大量复杂的，涉及到bug的问题处理，仿佛人生的主题就只是处理难题。来中亦安图以后，这个团队的风气和GCS如出一辙，喜欢去跟一些难点问题死磕。这是我们这个DBA团队的最优良的传统。如果你的系统有问题，可以让我们尝试“死磕”一下。

总结

这是个很简单案例，我想说的是，我们作DBA的总是要结合现场情况，在把问题分析最细粒度的情况下，利用Oracle强大的功能，为客户提供最便利的、最省成本的解决方案。 我们不创造技术，我们只是技术的搬运工。

如果你的数据库还在面临这一类让你头疼的问题，不妨让我们尝试可以关注我们的公众号，联系我们试一试。