【问题标题】:case sensitivity affects SQL parsing in oracle DB区分大小写会影响 oracle DB 中的 SQL 解析
【发布时间】:2019-11-16 10:55:38
【问题描述】:

我知道

select * from employees;

select * from Employees;

将生成 2 个不同的 SQLid 和哈希值,但最终使用相同的哈希计划值。 所以是软解析还是硬解析? 如果计划哈希值相同,两个语句将使用相同的执行计划吗?

【问题讨论】:

    标签: sql oracle performance parsing query-optimization


    【解决方案1】:

    它们是不同的游标,所以是的,第二个游标需要完整的解析和优化。

    优化器将分别评估每一个,但由于它们实际上是相同的查询(相同的表、一些连接、过滤器等),因此它将产生相同的执行计划,除非在解析第一个和第二个查询之间发生变化。

    请注意,这是 PL/SQL 的一个优势,因为编译器会在内部去除所有格式和大小写差异,这意味着如果在 PL/SQL 中使用它们,它们将变成相同的光标。

    【讨论】:

    • “它将产生相同的执行计划” - 这意味着硬解析?在共享池中,我们将有 2 个具有相同 hash_plan_number 的执行计划。?如果不是,那么第二个语句应该被软解析?
    • 是的,硬解析。计划与光标一起存储。据我所知,如果不同的游标碰巧使用相同的计划,则没有缓存优势。
    【解决方案2】:

    是的,这两个语句将得到不同的sql_id。但是,正如您在 the following demo 中看到的那样,两个语句的 plan_hash_value 保持不变。

    由于plan_hash_value 唯一标识了硬解析和相关的执行计划,这表明优化器确实发现两个查询相同,并检索共享池中的现有计划而不是第二次硬解析。

    create table employees(id int);
    
    select * from employees;
    
    | ID |
    | -: |
    
    select sql_id, hash_value, plan_hash_value
    from v$sql 
    where sql_text like 'select * from %mployees';
    
    SQL_ID        | HASH_VALUE | PLAN_HASH_VALUE
    :------------ | ---------: | --------------:
    f34thrbt8rjt5 | 4069246757 |      1445457117
    
    
    select * from Employees;
    
    | ID |
    | -: |
    
    select sql_id, hash_value, plan_hash_value
    from v$sql 
    where sql_text like 'select * from %mployees';
    
    SQL_ID        | HASH_VALUE | PLAN_HASH_VALUE
    :------------ | ---------: | --------------:
    f34thrbt8rjt5 | 4069246757 |      1445457117
    bvgw7mnuubskb |  900063819 |      1445457117
    

    Here 是相关阅读。

    【讨论】:

    • cursor sharing 在游标共享中:语句的文本被散列。如果共享池中当前不存在 SQL 语句,则数据库执行硬解析。这将结束共享池检查。在上面的演示中,它应该进行硬解析吗?这两个语句也会有不同的父游标?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2018-03-11
    • 1970-01-01
    • 2018-04-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多