UseLocalOrGlobalIndex?
经常我们需要将大表根据分区键进行分区,当建立索引的时候,我们到底使用local 还是global 索引呢 先看看两种索引的特点: 本地索引特点: 1. 本地索引一定是分区索引,分区键等同于表的分区键,分区数等同于表的分区说,一句话,本地索引的分区机制和表的分
经常我们需要将大表根据分区键进行分区,当建立索引的时候,我们到底使用local 还是global 索引呢
先看看两种索引的特点:
本地索引特点: 1. 本地索引一定是分区索引,分区键等同于表的分区键,分区数等同于表的分区说,一句话,本地索引的分区机制和表的分区机制一样。 2. 如果本地索引的索引列以分区键开头,则称为前缀局部索引。 3. 如果本地索引的列不是以分区键开头,或者不包含分区键列,则称为非前缀索引。 4. 前缀和非前缀索引都可以支持索引分区消除,前提是查询的条件中包含索引分区键。 5. 本地索引只支持分区内的唯一性,无法支持表上的唯一性,因此如果要用本地索引去给表做唯一性约束,则约束中必须要包括分区键列。 6. 本地分区索引是对单个分区的,每个分区索引只指向一个表分区,全局索引则不然,一个分区索引能指向 n个表分区,同时,一个表分区,也可能指向 n个索引分区,对分区表中的某个分区做 truncate或者 move, shrink等,可能会影响到 n个全局索引分区,正因为这点,本地分区索引具有更高的可用性。 7. 位图索引只能为本地分区索引。 8. 本地索引多应用于数据仓库环境中。 全局索引特点: 1.全局索引的分区键和分区数和表的分区键和分区数可能都不相同,表和全局索引的分区机制不一样。 2.全局索引可以分区,也可以是不分区索引,全局索引必须是前缀索引,即全局索引的索引列必须是以索引分区键作为其前几列。 3.全局分区索引的索引条目可能指向若干个分区,因此,对于全局分区索引,即使只截断一个分区中的数据,都需要 rebulid若干个分区甚至是整个索引。 4.全局索引多应用于 oltp系统中。 5.全局分区索引只按范围或者散列 hash分区, hash分区是 10g以后才支持。 6.oracle9i以后对分区表做move 或者truncate 的时可以用update global indexes语句来同步更新全局分区索引,用消耗一定资源来换取高度的可用性。 7.表用 a列作分区,索引用 b做局部分区索引,若 where条件中用 b来查询,那么 oracle会扫描所有的表和索引的分区,成本会比分区更高,此时可以考虑用 b做全局分区索引。 通常开发人员喜欢建立local索引,因为在删除分区的时候不需要重建索引。但是有时候本地索引将会带来很大的性能影响:----------------------------------------------------------------------------------------------------------------------- | Id | Operation |Name | Starts | E-Rows | A-Rows |Buffers |Pstart| Pstop | ----------------------------------------------------------------------------------------------------------------------- | 0 |SELECT STATEMENT | | 1 | | 1493 | 2984 | | | | 1 | PARTITION RANGEALL | | 1 | 1493 | 1493 | 2984 | 1 | 1493 | | 2 | TABLE ACCESS BY LOCAL INDEX ROWID| PARTITIONED_TAB | 1493 | 1493 | 1493 | 2984 | 1 | 1493 | |* 3 | INDEX RANGE SCAN | LC_NON_PREFIXED_TYP_I | 1492 | 1493 | 1493 | 1492 | 1 | 1493 | ----------------------------------------------------------------------------------------------------------------------- Predicate Information (identifiedby operation id): --------------------------------------------------- 3 - access(MHO_TYP_ID=0) Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 2984 consistent gets 0 physical reads 0 redosize 28937 bytes sent via SQL*Netto client 372 bytes received via SQL*Netfrom client 4 SQL*Net roundtripsto/fromclient 0 sorts (memory) 0 sorts (disk) 1493 rows processed
SQL>select * from partitioned_tab wheremho_typ_id = 0 and mho_date = to_date('01122012','ddmmyyyy'); MHO_ID MHO_DATE M MHO_TYP_ID ---------- ----------------- - ---------- 1 20121201 00:00:00 Z 0 ------------------------------------------------------------------------------------------------------------------------- | Id | Operation |Name | Starts | E-Rows | A-Rows | Buffers | Pstart| Pstop | ------------------------------------------------------------------------------------------------------------------------- | 0 |SELECT STATEMENT | | 1 | | 1 | 2 | | | | 1 | PARTITION RANGE SINGLE | | 1 | 1 | 1 | 2 | 2 | 2 | |* 2 | TABLE ACCESS BY LOCAL INDEX ROWID| PARTITIONED_TAB | 1 | 1 | 1 | 2 | 2 | 2 | |* 3 | INDEX RANGE SCAN | LC_NON_PREFIXED_TYP_I | 1 | 1 | 1 | 1 | 2 | 2 | ------------------------------------------------------------------------------------------------------------------------- Predicate Information (identifiedby operation id): --------------------------------------------------- 2 - filter(MHO_DATE=TO_DATE(' 2012-12-01 00:00:00','syyyy-mm-dd hh24:mi:ss')) 3 - access(MHO_TYP_ID=0) 这次LC_NON_PREFIXED_TYP_I只执行了一次 那我们换成global index呢?
SQL>select * from partitioned_tab where mho_typ_id = 0; ------------------------------------------------------------------------------------------------------------------ | Id | Operation |Name | Starts | E-Rows | A-Rows |Buffers | Pstart| Pstop | ------------------------------------------------------------------------------------------------------------------ | 0 |SELECT STATEMENT | | 1 | | 1493 | 1496 | | | | 1 | TABLE ACCESS BY GLOBAL INDEX ROWID| PARTITIONED_TAB | 1 | 1493 | 1493 | 1496 | ROWID | ROWID | |* 2 | INDEX RANGE SCAN | GL_TYP_I | 1 | 1493 | 1493 | 4 | | | ------------------------------------------------------------------------------------------------------------------ Predicate Information (identifiedby operation id): --------------------------------------------------- 2 - access(MHO_TYP_ID=0) Statistics ---------------------------------------------------------- 1 recursive calls 0 db block gets 1496 consistent gets 1493 physical reads 0 redosize 28937 bytes sent via SQL*Netto client 372 bytes received via SQL*Netfrom client 4 SQL*Net roundtripsto/fromclient 0 sorts (memory) 0 sorts (disk) 1493 rows processed

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

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

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

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

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

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