mysql 硬解析 软解析_3.硬解析，软解析，软软解析

v$sql ->存子游标信息(每个子游标对应一次硬解析)，关键信息是执行环境和执行计划

v$sqlarea ->存父游标信息,对应sql语句的文本

在v$sql中一个sql_id会存在多条语句，实际上v$sql中sql_id和child_number共同确定一个唯一的sql,原因是一个sql_id对应多个子游标。不同schema下相同sql,sql_id相同，单查询的对象不是同一用户

由于统计信息或者变量窥视，导致执行计划变化

游标的概念:指内存中可执行的sql对象，即SQL已经生成了执行计划。

父子游标都是可以共享的，称为共享游标，sql执行之前还要在会话的私有内存里生成1个会话游标，用于保存执行过程信息，这个在不同会话间是不能共享的，会话游标对应的视图v$open_cursor

硬解析：共享池中找不到游标，需要重新生成执行计划，即子游标(也可能包括父游标)

软解析：共享池中匹配到了子游标，但是需要生成会话游标

软软解析：会话游标和共享游标都不需要重新生成

v$sql的字段

child_number：sql子游标号，每个sql_id从0开始

LOADS：产生子游标的次数，即硬解析次数，该值不一定跟v$sql的子游标数量一致，因为子游标可能被回收，清除

EXECUTIONS：执行次数，表示sql执行了几次

PARSE_CALLS：执行解析的次数，包括硬解析和软解析

PLAN_HASH_VALUE：执行计划的hash_value

案例：使用了绑定变量也可能产生硬解析

select * from scott.emp e where e.ename = 'abc'

select * from scott.emp e where e.ename = 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'

经测试，如果绑定变量长度差距太大，也可能触发硬解析，即使禁止变量窥视(_optim_peek_user_binds=false)也不行。

v$sql_shared_cursor，根据sql_id找到硬解析原因

CURSOR_SHARING

exact：默认，sql语句完全相同(执行环境都得相同，比如查询表的数据分布)，若有不同，则不会共享游标

force：强制绑定变量

similar：在oracle认为某条语句谓词条件可能会影响他的执行计划，才会被重新分析，否则重用sql