通过案例学调优之--和 SHARED POOL 相关的主要 Latch-MySQL 튜토리얼-php.cn

집

데이터 베이스

MySQL 튜토리얼

通过案例学调优之--和 SHARED POOL 相关的主要 Latch

WBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWBOYWB

Jun 07, 2016 pm 04:46 PM

pool기본사례관련된통과하다

通过案例学调优之--和SHAREDPOOL相关的主要Latch3.1、和SHAREDPOOL相关的主要Latch有:Latch:sharedpoolLatch:librarycache我们知道Oracle通过SHAREDPOOL来实现SQ

的相关信息, 如:

, 也是通过将不同的

的相关

Library Cache LatchLibrary Cache SHRAE POOL 。接下来就开始进行硬解析过程,将执行解析后的执行计划等信息记录到 Library Cache ,一直到硬解析结束。(硬解析)

的话,根据上面的逻辑那说明数据库中存在大量的硬解析,这个时候就要查找那些

10:56:01 SCOTT@ prod >show parameter cursor NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ cursor_sharing string similar cursor_space_for_time boolean FALSE open_cursors integer 300 session_cached_cursors integer 50 1、session1：以scott建立测试表 11:44:26 SYS@ prod >conn scott/tiger Connected. 11:01:41 SCOTT@ prod >select * from v$mystat where rownum=1; SID STATISTIC# VALUE ---------- ---------- ---------- 1 0 0 10:56:09 SCOTT@ prod >create table test as select rownum as col1 ,rownum col2 from user_objects 10:58:38 2 ; Table created. 2、建立测试表直方图 10:58:51 SCOTT@ prod >exec dbms_stats.gather_table_stats(user,'TEST',method_opt=>'for columns col1 size 3'); PL/SQL procedure successfully completed. 10:59:36 SCOTT@ prod >select column_name,num_buckets,histogram from user_tab_col_statistics 11:00:43 2 where table_name='TEST'; COLUMN_NAME NUM_BUCKETS HISTOGRAM ------------------------------ ----------- --------------- COL1 3 HEIGHT BALANCED 11:01:35 sys@ prod >ALTER SYSTem flush shared_pool; System altered. 3、session 2:以scott建立另一个会话 11:03:44 SCOTT@ prod >select * from v$mystat where rownum=1; SID STATISTIC# VALUE ---------- ---------- ---------- 44 0 0 11:04:01 SCOTT@ prod >create table test1 as select rownum as col1 ,rownum col2 from user_objects; Table created. 11:04:36 SCOTT@ prod >exec dbms_stats.gather_table_stats(user,'TEST1',method_opt=>'for columns col1 size 3'); PL/SQL procedure successfully completed. 11:05:04 SCOTT@ prod >select column_name,num_buckets,histogram from user_tab_col_statistics 11:05:19 2 where table_name='TEST1'; COLUMN_NAME NUM_BUCKETS HISTOGRAM ------------------------------ ----------- --------------- COL1 3 HEIGHT BALANCED 11:05:30 sys@ prod >ALTER SYSTem flush shared_pool; System altered. 4、在session 1执行以下操作 11:02:42 SCOTT@ prod >begin 11:06:28 2 for i in 1..50000 loop 11:06:40 3 execute immediate 'select * from test where col1='||i; 11:07:08 4 end loop; 11:07:11 5 end; 11:07:13 6 / 在session 2执行同样地操作 11:07:57 SCOTT@ prod >begin 11:08:01 2 for i in 1..50000 loop 11:08:01 3 execute immediate 'select * from test1 where col1='||i; 11:08:01 4 end loop; 11:08:01 5 end; 11:08:02 6 / 5、查看session event 11:11:36 sys@ prod > select sid,event,p1,p1text,p2,p2text from v$session where sid in (1,44) SID EVENT P1 P1TEXT P2 P2TEXT ---------- ------------------------------ ---------- ------------------------------ ---------- ------------------------------ 1 latch: shared pool 537557404 address 293 number 44 latch: shared pool 537557404 address 293 number Elapsed: 00:00:00.00 11:11:38 sys@ prod >/ SID EVENT P1 P1TEXT P2 P2TEXT ---------- ------------------------------ ---------- ------------------------------ ---------- ------------------------------ 1 latch: shared pool 537557404 address 293 number 44 latch: row cache objects 828539960 address 270 number Elapsed: 00:00:00.00 11:11:39 sys@ prod >/ SID EVENT P1 P1TEXT P2 P2TEXT ---------- ------------------------------ ---------- ------------------------------ ---------- ------------------------------ 1 latch: shared pool 537557404 address 293 number 44 latch: shared pool 537557404 address 293 number Elapsed: 00:00:00.00 11:11:41 sys@ prod >/ SID EVENT P1 P1TEXT P2 P2TEXT ---------- ------------------------------ ---------- ------------------------------ ---------- ------------------------------ 1 latch: shared pool 537557404 address 293 number 44 latch: row cache objects 828007508 address 270 number Elapsed: 00:00:00.00 11:11:42 sys@ prod >/ SID EVENT P1 P1TEXT P2 P2TEXT ---------- ------------------------------ ---------- ------------------------------ ---------- ------------------------------ 1 latch: shared pool 537557404 address 293 number 44 latch: shared pool 537557404 address 293 number 11:12:32 sys@ prod >/ SID EVENT P1 P1TEXT P2 P2TEXT ---------- ------------------------------ ---------- ------------------------------ ---------- ------------------------------ 1 latch free 821793596 address 274 number 44 latch: shared pool 537557404 address 293 number sys@ prod >select sid,event,p1,p1text,p2,p2text from v$session where sid in (1,44) SID EVENT P1 P1TEXT P2 P2TEXT ---------- ------------------------------ ---------- ------------------------------ ---------- ------------------------------ 1 latch: shared pool 537557404 address 293 number 44 library cache: mutex X 1307903034 idn 65536 value 11:14:58 sys@ prod >select sid,event,p1,p1text,p2,p2text from v$session where sid in (1,44) SID EVENT P1 P1TEXT P2 P2TEXT ---------- ------------------------------ ---------- ------------------------------ ---------- ------------------------------ 1 library cache: mutex X 3413592168 idn 2883584 value 44 latch: row cache objects 828539960 address 270 number 11:15:18 sys@ prod >select sid,event,p1,p1text,p2,p2text from v$session where sid in (1,44) SID EVENT P1 P1TEXT P2 P2TEXT ---------- ------------------------------ ---------- ------------------------------ ---------- ------------------------------ 1 SQL*Net message from client 1650815232 driver id 1 #bytes 44 SQL*Net message from client 1650815232 driver id 1 #bytes 从上面的过程可以看到,大量的硬解析将导致严重的 library cache latch（mutex）和 shared pool latch竞争。 6、查看Library cache中sql情况 sys@ prod >select * 2 from (select sql_id,child_number,child_latch,executions,sql_text 3 from v$sql 4 where sql_text like '%select * from test1 where col1%' 5 and sql_text not like '%v$sql%' 6 and sql_text not like '%begin%' 7 order by child_number desc) 8* where rownum select sql_id,hash_value,address,version_count from v$sqlarea where sql_id='6tsrjxza4gvur'; SQL_ID HASH_VALUE ADDRESS VERSION_COUNT ------------- ---------- -------- ------------- 6tsrjxza4gvur 3561484119 2E8CF368 3885

성명

본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.

관련 기사

MySQL은 오픈 소스 관계형 데이터베이스 관리 시스템으로, 주로 데이터를 신속하고 안정적으로 저장하고 검색하는 데 사용됩니다. 작업 원칙에는 클라이언트 요청, 쿼리 해상도, 쿼리 실행 및 반환 결과가 포함됩니다. 사용의 예로는 테이블 작성, 데이터 삽입 및 쿼리 및 조인 작업과 같은 고급 기능이 포함됩니다. 일반적인 오류에는 SQL 구문, 데이터 유형 및 권한이 포함되며 최적화 제안에는 인덱스 사용, 최적화 된 쿼리 및 테이블 분할이 포함됩니다.

MySQL의 중요성 : 데이터 저장 및 관리Apr 12, 2025 am 12:18 AM

MySQL은 데이터 저장, 관리, 쿼리 및 보안에 적합한 오픈 소스 관계형 데이터베이스 관리 시스템입니다. 1. 다양한 운영 체제를 지원하며 웹 응용 프로그램 및 기타 필드에서 널리 사용됩니다. 2. 클라이언트-서버 아키텍처 및 다양한 스토리지 엔진을 통해 MySQL은 데이터를 효율적으로 처리합니다. 3. 기본 사용에는 데이터베이스 및 테이블 작성, 데이터 삽입, 쿼리 및 업데이트가 포함됩니다. 4. 고급 사용에는 복잡한 쿼리 및 저장 프로 시저가 포함됩니다. 5. 설명 진술을 통해 일반적인 오류를 디버깅 할 수 있습니다. 6. 성능 최적화에는 인덱스의 합리적인 사용 및 최적화 된 쿼리 문이 포함됩니다.

MySQL을 사용하는 이유는 무엇입니까? 혜택과 장점Apr 12, 2025 am 12:17 AM

MySQL은 성능, 신뢰성, 사용 편의성 및 커뮤니티 지원을 위해 선택됩니다. 1.MYSQL은 효율적인 데이터 저장 및 검색 기능을 제공하여 여러 데이터 유형 및 고급 쿼리 작업을 지원합니다. 2. 고객-서버 아키텍처 및 다중 스토리지 엔진을 채택하여 트랜잭션 및 쿼리 최적화를 지원합니다. 3. 사용하기 쉽고 다양한 운영 체제 및 프로그래밍 언어를 지원합니다. 4. 강력한 지역 사회 지원을 받고 풍부한 자원과 솔루션을 제공합니다.

InnoDB 잠금 장치 (공유 잠금, 독점 잠금, 의도 잠금, 레코드 잠금, 갭 잠금, 차세대 자물쇠)를 설명하십시오.Apr 12, 2025 am 12:16 AM

InnoDB의 잠금 장치에는 공유 잠금 장치, 독점 잠금, 의도 잠금 장치, 레코드 잠금, 갭 잠금 및 다음 키 잠금 장치가 포함됩니다. 1. 공유 잠금을 사용하면 다른 트랜잭션을 읽지 않고 트랜잭션이 데이터를 읽을 수 있습니다. 2. 독점 잠금은 다른 트랜잭션이 데이터를 읽고 수정하는 것을 방지합니다. 3. 의도 잠금은 잠금 효율을 최적화합니다. 4. 레코드 잠금 잠금 인덱스 레코드. 5. 갭 잠금 잠금 장치 색인 기록 간격. 6. 다음 키 잠금은 데이터 일관성을 보장하기 위해 레코드 잠금과 갭 잠금의 조합입니다.

열악한 MySQL 쿼리 성능의 일반적인 원인은 무엇입니까?Apr 12, 2025 am 12:11 AM

MySQL 쿼리 성능이 좋지 않은 주된 이유는 인덱스 사용, 쿼리 최적화에 의한 잘못된 실행 계획 선택, 불합리한 테이블 디자인, 과도한 데이터 볼륨 및 잠금 경쟁이 포함됩니다. 1. 색인이 느리게 쿼리를 일으키지 않으며 인덱스를 추가하면 성능이 크게 향상 될 수 있습니다. 2. 설명 명령을 사용하여 쿼리 계획을 분석하고 Optimizer 오류를 찾으십시오. 3. 테이블 구조를 재구성하고 결합 조건을 최적화하면 테이블 설계 문제가 향상 될 수 있습니다. 4. 데이터 볼륨이 크면 분할 및 테이블 디비전 전략이 채택됩니다. 5. 높은 동시성 환경에서 거래 및 잠금 전략을 최적화하면 잠금 경쟁이 줄어들 수 있습니다.

Composite Index와 여러 단일 열 인덱스를 언제 사용해야합니까?Apr 11, 2025 am 12:06 AM

데이터베이스 최적화에서 쿼리 요구 사항에 따라 인덱싱 전략을 선택해야합니다. 1. 쿼리에 여러 열이 포함되고 조건 순서가 수정되면 복합 인덱스를 사용하십시오. 2. 쿼리에 여러 열이 포함되어 있지만 조건 순서가 고정되지 않은 경우 여러 단일 열 인덱스를 사용하십시오. 복합 인덱스는 다중 열 쿼리를 최적화하는 데 적합한 반면 단일 열 인덱스는 단일 열 쿼리에 적합합니다.

MySQL에서 느린 쿼리를 식별하고 최적화하는 방법은 무엇입니까? (느린 쿼리 로그, Performance_schema)Apr 10, 2025 am 09:36 AM

MySQL 느린 쿼리를 최적화하려면 SlowQueryLog 및 Performance_Schema를 사용해야합니다. 1. SlowQueryLog 및 Set Stresholds를 사용하여 느린 쿼리를 기록합니다. 2. Performance_schema를 사용하여 쿼리 실행 세부 정보를 분석하고 성능 병목 현상을 찾고 최적화하십시오.

MySQL 및 SQL : 개발자를위한 필수 기술Apr 10, 2025 am 09:30 AM

MySQL 및 SQL은 개발자에게 필수적인 기술입니다. 1.MySQL은 오픈 소스 관계형 데이터베이스 관리 시스템이며 SQL은 데이터베이스를 관리하고 작동하는 데 사용되는 표준 언어입니다. 2.MYSQL은 효율적인 데이터 저장 및 검색 기능을 통해 여러 스토리지 엔진을 지원하며 SQL은 간단한 문을 통해 복잡한 데이터 작업을 완료합니다. 3. 사용의 예에는 기본 쿼리 및 조건 별 필터링 및 정렬과 같은 고급 쿼리가 포함됩니다. 4. 일반적인 오류에는 구문 오류 및 성능 문제가 포함되며 SQL 문을 확인하고 설명 명령을 사용하여 최적화 할 수 있습니다. 5. 성능 최적화 기술에는 인덱스 사용, 전체 테이블 스캔 피하기, 조인 작업 최적화 및 코드 가독성 향상이 포함됩니다.

See all articles