我从学习数据库开始就知道，硬解析会有很大问题。我接触的数据库中貌似只有Oracle会涉及到这个。有的时候我自同等环境下（硬件配置和场景）测试下来Oracle会由于其他数据库的数据，我有时候就在想会不会这就是软解析和软软解析带来的效果？ 不过十几年工作下来，几乎没有遇到过硬解析带来的问题。但是试问苍天饶过谁。我这就遇到了。而且还刷新了我对绑定变量的一些新的认知。
发现一个系统，故障时段硬解析很高。对比了一下故障后的硬解析下降了1000倍。这是很惊人的。
发现问题时候有一些SQL的版本较高有90多个，虽然比起网上有些几百个的来说不算多，但是几十个也不少了。我们都知道不绑定变量是什么样子的（就是写入实际参数），我也知道绑定变量多了会怎么样（以前遇到过超过65535个数据库就宕机的）。但是其实我们一般都忽略绑定失败的情况。查询 V$SQL_SHARED_CURSOR，最后的reason里面记录了为什么失败。在这个reason之前有几十个字段每个都是一种原因。比如这种：
。
reason是这些的汇总。也就是说使用绑定变量不一样就是绑定变量了，还有几十种可能失败，失败了还是要硬解析的。
之前没怎么关注过这些，可能有人会觉得不专业。其实数据库博大精深，越学习越发现要学习的太多了，以前学习的还不够。其实很多时候我们都是知道什么是对的，怎么做对就好了。这样其实是简单的。现在不同，是要了解稀奇古怪的错（之所以有这些错，是因为没听正确的做法，就导致了各式各样的问题）。这次看到一个SQL在share_pool中占据了将近2G。 你说这有天理吗？
我一直说只有我想不到的，没有开发做不到的。
