ORACLE夸大了硬解析的代价：
经常看到一些人做实验对比硬解析对性能的冲击有多么大。
可是别忘了，ORACLE的很多架构设计都是依据“应用要软解析”来设计的
比如共享池的存在，更确切的说是，library cache的存在就是为了缓存执行计划，避免硬解析
而其他的一些数据库比如POSTGRES，MYSQL可能压根上不需要一个这么池来缓存执行计划。
有了这个一个池，一个共享的池，必然会出现争用的问题，一旦大量的SQL要硬解析，争用必然出现
但是如果没有这个池，这么一个共享的池，这个争用将不再存在
我们来看看解析的代价，李维斯lewis把解析划分为了：解析和优化两个大阶段，我把第二个阶段再细分一个出来
解析的代价：
1）解析 分析语法、大量递归查询数据字典
2）优化，CBO算法得出一个最有效的执行计划，ORACLE的CBO算法比较复杂，这个步骤相对于其他数据库也要耗费多点的CPU
3）在共享池里存储执行计划，这个东东会引起大量争用
经常看到一些人做实验对比硬解析对性能的冲击有多么大。
可是别忘了，ORACLE的很多架构设计都是依据“应用要软解析”来设计的
比如共享池的存在，更确切的说是，library cache的存在就是为了缓存执行计划，避免硬解析
而其他的一些数据库比如POSTGRES，MYSQL可能压根上不需要一个这么池来缓存执行计划。
有了这个一个池，一个共享的池，必然会出现争用的问题，一旦大量的SQL要硬解析，争用必然出现
但是如果没有这个池，这么一个共享的池，这个争用将不再存在
我们来看看解析的代价，李维斯lewis把解析划分为了：解析和优化两个大阶段，我把第二个阶段再细分一个出来
解析的代价：
1）解析 分析语法、大量递归查询数据字典
2）优化，CBO算法得出一个最有效的执行计划，ORACLE的CBO算法比较复杂，这个步骤相对于其他数据库也要耗费多点的CPU
3）在共享池里存储执行计划，这个东东会引起大量争用
在一个比较小的数据库系统里，像POSTGRES,MYSQL 虽然可能大部分是硬解析，但是真的，没那么硬。其实步骤1他们一定有自己的缓存
我没听说过哪个数据库敢没有数据字典缓存的（可以没有SQL缓存），所以步骤一的代价并没有那么大
步骤二呢，大部分数据库的CBO算法极其简单，可能有些还停留在RBO阶段，所以这个步骤也没多大的代价
第三步，只有ORACLE这个东西有，这个步骤的代价很大，资源争用严重。
我没听说过哪个数据库敢没有数据字典缓存的（可以没有SQL缓存），所以步骤一的代价并没有那么大
步骤二呢，大部分数据库的CBO算法极其简单，可能有些还停留在RBO阶段，所以这个步骤也没多大的代价
第三步，只有ORACLE这个东西有，这个步骤的代价很大，资源争用严重。
经过上面分析，可以知道，步骤一、二，对很多数据库真的没多大的代价
而ORACLE这个数据库多了第三个步骤，其实这个步骤的代价是最大的我个人觉得。
所以硬解析在ORACLE里就显得非常严重，非常强调要避免硬解析。
而ORACLE这个数据库多了第三个步骤，其实这个步骤的代价是最大的我个人觉得。
所以硬解析在ORACLE里就显得非常严重，非常强调要避免硬解析。
6e093035jw1e4z8100kdhj20c80ryjur.jpg来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/22034023/viewspace-761920/ ，如需转载，请注明出处，否则将追究法律责任。
下一篇：
存储cache的响应时间
请登录后发表评论
登录
全部评论
