硬币都有两个面，而解决问题的时候总是有条件限制的

DBA群体往往都很固执，硬币有条甚至有些人会有执念。解决件限执念有时候是问题好东西，比如在探究问题的候总根本的时候，不过有时候会产生一些副作用。硬币有条最典型的解决件限就是对某件事或者问题产生偏见，从而无法正确的问题思考问题，在探讨一个数据库问题的候总原因和解决方案的时候尤其如此。我们总是硬币有条觉得自己找出的线索链条是正确的，自己提出的解决件限方案才是最好的解决方案。事实上，问题有些事情可能像一枚硬币一样，候总有两个面，硬币有条甚至有多个面，解决件限而我们熟知或者掌握的问题都只是其中的一部分，都是云南idc服务商片面的，局部的。因此在判断一件事情的时候，你可以坚持你的观点，但是不要急于否定别人的观点，因为有可能二者都是有道理的。

在某些观点方面，你可以有立场，可以站边，但是你不要轻易的去否定别人的观点。就像PG和MySQL数据库哪个更好的问题上，我总是和客户说选择哪种数据库，是要根据你自己的自身情况和应用场景的，但是如果你让我推荐的话，我更倾向于推荐PG，香港云服务器因为我对PG更熟悉一些，如果你用了PG，今后我可以更好的为你服务。这仅仅是从我个人的立场出发，并不是说我就认为PG远远好于MySQL。

在定位某个问题的原因的时候，我们往往无法定位到根因，无法从根本上解决问题。因此能够解决某个问题的方案可能有很多种，这些方案之间有可能不是严格意义上存在哪个更好的问题。在这种情况下，我们也会更加倾向于采用自己熟悉的或者自己认为比较合适的方案。DBA往往希望开发商通过修改SQL来解决问题，而开发人员认为数据库就应该能够让他们可以任意写SQL来实现业务逻辑。在大多数DBA看来，就是开发人员瞎写垃圾SQL导致了系统总出问题，而从研发人员的立场上看，这个问题的症结是数据库太垃圾了。网站模板

在了解了问题的多面性和解决路径的多样性之后，我们还要注意的一个问题是我们解决问题的环境中，总是有一些条件限制的。十多年前，我在《DBA优化日记》里介绍了一个优化项目的全过程。有朋友和我探讨这个案例，认为这是我编出来的一个故事，里面设定了很多预设条件，比如服务器不能扩容，SQL无法大规模修改等。实际上这是一个真的不能再真的案例了，当这本书出版后。书中的一些当事人纷纷和我联系，感谢我把这个故事讲了出来。因为在实际的工作中，我们总是会遇到各种各样的限制条件，因此我们在考虑问题的解决方案的时候，还需要根据限制条件去裁剪解决路径。

一个最典型的问题是，既然绝大多数数据库的问题都与SQL与SQL的负载有关，为什么不从SQL与应用入手，彻底解决数据库的问题呢？确实在30多年前，我们解决问题的方案就是这样的，通过研发人员对应用的优化，可以让资源有限的小型机与数据库跑得很棒。现在的一些互联网企业现在也是这么做的。不过要想做好这一点并不容易，30多年的程序员都是“精英”，而那时候我们的软件产业规模也不大，这些精英足以支撑这个行业。而随着信息化的发展，软件产业的规模已经扩大了万倍了，我们现在无法保证软件开发人员都是能写算法来解决复杂问题的“精英”，那么我们就只能容忍应用系统存在不合理的架构，不合理的设计，存在大量比较烂的SQL了。

这种情况下，就需要数据库系统能够补上应用比较烂的短板。实际上这几十年数据库厂商的目标也是尽可能让应用开发变得更加简单，让应用开发者仅仅关注与业务逻辑。而DBA就是数据库与应用开发者之间的桥梁，他们通过优化数据库本身的配置，或者在数据库中采用数据库的手段去优化SQL，让数据库能够充分的利用底层的系统资源，跑得更加流畅。

举个例子，为什么SQL都可以通过开发修改，还需要在数据库中提供hint,outlines，sql profile ,sql baseline等优化手段呢？实际上这些SQL优化技术的实现模式不同，应用场景也各有不同。Hint是在应明确了某种访问路径是最优的情况下固化SQL执行计划的方法，可以最有效的解决SQL执行计划错误的问题。不过当临时发现系统存在SQL执行计划错误的时候，修改应用可能至少需要几个小时，而业务系统需要立即恢复的时候，我们就可以使用outlines，在不修改应用的前提下强制指定SQL的访问路径。

似乎hint/outlines已经能够解决静态和动态两方面的问题了，二者组合应该够用了吧。事实上还不够，因为有些时候某条SQL在代入不同参数的时候，有两种截然不同的最佳访问路径，那么使用hint/outlines来固化为某种访问方式就不合适了，因为无论如何，都会出现一种错误的执行计划。这个时候，就需要使用sql profile来解决这个问题了，你可以通过sql profile来让SQL PLAN生成得更加合理，而不是简单的指定某种执行计划。

实际上，前阵子有个数据库厂商的研发人员与我探讨过这个问题，他们的产品已经支持了hint和outlines，正在纠结是不是要支持类似Oracle SQL PROFILE的功能，他们觉得有了前者SQL PROFILE似乎用处不是很大了。

实际上又回到了本文开头我们探讨的那个问题了，在实际的应用场景中，解决某些问题的时候，总是会受到某种限制，因此用户需要有更多的方案选择，才能在实际工作中用最小的代价来解决问题。有些时候，解决问题的方法土了一点，可能在某些DBA眼里缺乏技术高度，不过也没关系，好用就行，能解决问题就行。

最新评论