Oracle 自适应游标共享--adaptive cursor sharing
在11g中,Oracle引入了一项新特征:adaptive cursor sharing 自适应游标共享。这项特征主要用来改进具有绑定变量的sql语句的执行
在11g中,Oracle引入了一项新特征:adaptive cursor sharing 自适应游标共享。这项特征主要用来改进具有绑定变量的sql语句的执行计划,也导致了具有绑定变量的sql语句可能会生成多个游标。在9i中,Oracle引入了变量窥测(bind peeking)技术,通过使用变量窥测在SQL语句第一次硬解析时,优化器可以判定where子句的选择性,从而改进生成执行计划的质量。但是使用变量窥测技术生成的执行计划在表数据分布不均衡的情况下,往往不具有通用性。(参见:)
自适应游标共享功能的引入,可以有效的解决这个问题。
首先看一下我们的测试环境:
SQL> desc acs_test_tab
名称 是否为空? 类型
----------------------------------------------------- -------- ------------------------------------
ID NOT NULL NUMBER
RECORD_TYPE NUMBER
DESCRIPTION VARCHAR2(50)
SQL> select count(*) from acs_test_tab;
COUNT(*)
----------
100000
SQL> select count(*) from acs_test_tab where record_type=2;
COUNT(*)
----------
50000
SQL> select count(distinct record_type) from acs_test_tab;
COUNT(DISTINCTRECORD_TYPE)
--------------------------
50001
表acs_test_Tab在列record_type上分布式是倾斜的。收集统计信息:
SQL> exec dbms_stats.gather_Table_Stats(user,'acs_test_Tab',cascade=>true,method_opt=>'for all columns size auto');
PL/SQL 过程已成功完成。
SQL> select column_name,histogram from user_tab_cols where table_name='ACS_TEST_TAB';
COLUMN_NAME HISTOGRAM
------------------------------ ---------------
ID NONE
RECORD_TYPE HEIGHT BALANCED
DESCRIPTION NONE
首先我们对record_type 为1 的列进行查询
SQL> select count(*) from acs_test_tab where record_type = 1;
COUNT(*)
----------
1
SQL> alter system flush shared_pool;
系统已更改。
SQL> var v number;
SQL> exec :v := 1
PL/SQL 过程已成功完成。
SQL> select sum(id) from acs_test_tab where record_type = :v;
SUM(ID)
----------
1
SQL> select * from table(dbms_xplan.display_cursor);
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID 3p66zbwtm19bs, child number 0
-------------------------------------
select sum(id) from acs_test_tab where record_type = :v
Plan hash value: 3987223107
-----------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 4 (100)| |
| 1 | SORT AGGREGATE | | 1 | 9 | | |
| 2 | TABLE ACCESS BY INDEX ROWID| ACS_TEST_TAB | 1 | 9 | 4 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | ACS_TEST_TAB_RECORD_TYPE_I | 1 | | 3 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access("RECORD_TYPE"=:V)
已选择20行。
SQL> select child_number,executions,buffer_gets,is_bind_sensitive,is_bind_aware
2 from v$sql
3 where sql_text like 'select sum(id)%';
CHILD_NUMBER EXECUTIONS BUFFER_GETS I I
------------ ---------- ----------- - -
0 1 218 Y N
下面我们在查询一下record_type为2的记录,
SQL> exec :v := 2
PL/SQL 过程已成功完成。
SQL> select sum(id) from acs_test_tab where record_type = :v;
SUM(ID)
----------
2500050000
SQL> select * from table(dbms_xplan.display_cursor);
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID 3p66zbwtm19bs, child number 0
-------------------------------------
select sum(id) from acs_test_tab where record_type = :v
Plan hash value: 3987223107
-----------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 4 (100)| |
| 1 | SORT AGGREGATE | | 1 | 9 | | |
| 2 | TABLE ACCESS BY INDEX ROWID| ACS_TEST_TAB | 1 | 9 | 4 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | ACS_TEST_TAB_RECORD_TYPE_I | 1 | | 3 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access("RECORD_TYPE"=:V)
已选择20行。
SQL> select child_number,executions,buffer_gets,is_bind_sensitive,is_bind_aware
2 from v$sql
3 where sql_text like 'select sum(id)%';
CHILD_NUMBER EXECUTIONS BUFFER_GETS I I
------------ ---------- ----------- - -
0 2 832 Y N
我们发现执行计划没有变化,但是统计信息却发生了比较大的跳跃。
再次执行上面的语句
SQL> select sum(id) from acs_test_tab where record_type = :v;
SUM(ID)
----------
2500050000
SQL> select * from table(dbms_xplan.display_cursor);

핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

AI Hentai Generator
AI Hentai를 무료로 생성하십시오.

인기 기사

뜨거운 도구

메모장++7.3.1
사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전
중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기
강력한 PHP 통합 개발 환경

드림위버 CS6
시각적 웹 개발 도구

SublimeText3 Mac 버전
신 수준의 코드 편집 소프트웨어(SublimeText3)

뜨거운 주제











InnoDB의 전체 텍스트 검색 기능은 매우 강력하여 데이터베이스 쿼리 효율성과 대량의 텍스트 데이터를 처리 할 수있는 능력을 크게 향상시킬 수 있습니다. 1) InnoDB는 기본 및 고급 검색 쿼리를 지원하는 역 색인화를 통해 전체 텍스트 검색을 구현합니다. 2) 매치 및 키워드를 사용하여 검색, 부울 모드 및 문구 검색을 지원합니다. 3) 최적화 방법에는 워드 세분화 기술 사용, 인덱스의 주기적 재건 및 캐시 크기 조정, 성능과 정확도를 향상시키는 것이 포함됩니다.

이 기사는 MySQL의 Alter Table 문을 사용하여 열 추가/드롭 테이블/열 변경 및 열 데이터 유형 변경을 포함하여 테이블을 수정하는 것에 대해 설명합니다.

전체 테이블 스캔은 MySQL에서 인덱스를 사용하는 것보다 빠를 수 있습니다. 특정 사례는 다음과 같습니다. 1) 데이터 볼륨은 작습니다. 2) 쿼리가 많은 양의 데이터를 반환 할 때; 3) 인덱스 열이 매우 선택적이지 않은 경우; 4) 복잡한 쿼리시. 쿼리 계획을 분석하고 인덱스 최적화, 과도한 인덱스를 피하고 정기적으로 테이블을 유지 관리하면 실제 응용 프로그램에서 최상의 선택을 할 수 있습니다.

예, MySQL은 Windows 7에 설치 될 수 있으며 Microsoft는 Windows 7 지원을 중단했지만 MySQL은 여전히 호환됩니다. 그러나 설치 프로세스 중에 다음 지점이 표시되어야합니다. Windows 용 MySQL 설치 프로그램을 다운로드하십시오. MySQL의 적절한 버전 (커뮤니티 또는 기업)을 선택하십시오. 설치 프로세스 중에 적절한 설치 디렉토리 및 문자를 선택하십시오. 루트 사용자 비밀번호를 설정하고 올바르게 유지하십시오. 테스트를 위해 데이터베이스에 연결하십시오. Windows 7의 호환성 및 보안 문제에 주목하고 지원되는 운영 체제로 업그레이드하는 것이 좋습니다.

기사는 인증서 생성 및 확인을 포함하여 MySQL에 대한 SSL/TLS 암호화 구성에 대해 설명합니다. 주요 문제는 자체 서명 인증서의 보안 영향을 사용하는 것입니다. [문자 수 : 159]

기사는 MySQL Workbench 및 Phpmyadmin과 같은 인기있는 MySQL GUI 도구에 대해 논의하여 초보자 및 고급 사용자를위한 기능과 적합성을 비교합니다. [159 자].

클러스터 인덱스와 비 클러스터 인덱스의 차이점은 1. 클러스터 된 인덱스는 인덱스 구조에 데이터 행을 저장하며, 이는 기본 키 및 범위별로 쿼리에 적합합니다. 2. 클러스터되지 않은 인덱스는 인덱스 키 값과 포인터를 데이터 행으로 저장하며 비 예산 키 열 쿼리에 적합합니다.

기사는 MySQL에서 파티셔닝, 샤딩, 인덱싱 및 쿼리 최적화를 포함하여 대규모 데이터 세트를 처리하기위한 전략에 대해 설명합니다.
