要想说清楚硬解析和软解析的区别，就得先说一下 SQL 执行的大致流程：
语法检查：检查 SQL 语句的语法是否正确。
语义检查：检查 SQL 语句中引用的表、列、数据类型等是否存在于数据库中，以及用户是否有足够的权限访问它们。
共享池查询：检查共享池（Shared Pool）中的库缓存（Library Cache），看是否已经存在相同或相似的 SQL 语句的执行计划。如果存在，它可能会重用已有的执行计划，这个过程称为 SQL 语句的软解析。如果不存在，则需要进行硬解析。
很显然，软、硬解析就发生在第 3 步，所以关于硬解析和软解析最简单直白的区别就是：
硬解析：需要生成执行计划
软解析：不需要生成执行计划
接下来主要说说硬解析，硬解析大致包括下面几个过程：
对 SQL 语句进行语法检查，看是否有语法错误。比如 select/from/where 等的拼写错误，如果存在语法错误，则退出解析过程；
通过数据字典，检查 SQL 语句中涉及的对象和列是否存在。如果不存在，则退出解析过程。
检查 SQL 语句的用户是否对涉及到的对象是否有权限。如果没有则退出解析；
通过优化器创建一个最优的执行计划。这个过程会根据数据字典中的对象的统计信息，来计算多个执行计划的 cost，从而得到一个最优的执行计划。这一步涉及到大量的数据运算，从而会消耗大量的 CPU 资源；(library cache 最主要的目的就是通过软解析来减少这个步骤)；
将该游标所产生的执行计划、SQL 文本等装载进 library cache 中的 heap 中。
而软解析就是因为相同文本的 SQL 语句存在于 library cache 中，相对硬解析来说，会减少很多不必要的步骤，从而节省大量的资源耗费。
因为绑定变量可以将 SQL 语句中的常量变为变量，直接避免了 SQL 的多次硬解析，所以，想让数据库的硬解析减少的最有效办法之一就是：绑定变量。
以下内容摘自 Thomas Kyte 的《Oracle编程艺术 深入理解数据库体系结构》 1.3 开发数据库应用的正确方法：
硬解析会减少系统能支持的用户数，但程度如何可能不容易度量。这取决于多耗费了多少资源，但更重要的因素是库缓存所用的闩定（latching）机制。硬解析一个查询时，数据库会更长时间地占用一种低级串行化设备，这成为闩（latch）。这些闩能保护 Oracle 共享内存中的数据结构不会同时被两个进程修改（否则，Oracle 的数据结构会最终遭到破坏），而且如果有人正在修改某个数据结构，等待队列也越长。当大家都在试图抢占这种珍贵的闩资源时，你的『服务器』可能看上去非常空闲，但是数据库中的所有应用都运行得非常慢。造成这种现象的原因可能是有人占据着某种串行化设备，而其他等待串行化设备的人开始排队，因此你无法全速运行。数据库中只要有一个应用表现不佳，就会严重地影响所有其他应用的性能。如果只有一个小应用没有使用绑定变量，那么即使其他应用原本设计得很好，能适当地将已解析的 SQL 放在共享池中以备重用，但因为这个小应用的存在，过一段时间就会从共享池中把已存储的 SQL 的执行计划排挤出去。这就使得这些设计得当的应用也必须再次硬解析 SQL，真是一粒老鼠屎就能毁了一锅汤。
此时，再去回顾一下绑定变量的解释，是不是会更加清晰？
