찾다
데이터 베이스MySQL 튜토리얼高水位线引起的查询变慢解决方法

高水位线引起的查询变慢解决方法

May 15, 2018 pm 04:12 PM
속도를 늦추다원인방법질문해결하다함께

众所周知,随着不断地进行表记录的DML操作,会不断提高表的高水位线(HWM),DELETE操作之后虽然表的数据删除了,但是并没有降低表的高水位,除非你使用TRUNCATE操作,进行表查询的时候,Oracle会扫表高水位以下的数据块,也就是说,扫描的时间并不会有所减少。所以DELETE删除数据以后并不会提高表的查询效率。

相关mysql视频教程推荐:《mysql教程

下面通过这个例子,用来解决高水位引起的查询变慢问题:

--例子中测试表占用表空间大小为:128M
SQL> SELECT a.bytes/1024/1024 || 'M' FROM user_segments a WHERE a.segment_name = 'TC_RES_PHY_EQP_PRO_MID_517';

A.BYTES/1024/1024||'M'
-----------------------------------------
128M

--查询一条记录成本为:4357,一致性读为:15730 耗时 0.53 秒
SQL> set autotrace  on
SQL> SELECT 1 FROM TC_RES_PHY_EQP_PRO_MID_517 a WHERE a.obj_id = 17202000000001;

         1
----------
         1


执行计划
----------------------------------------------------------
Plan hash value: 854298875

------------------------------------------------------------------------------------------------
| Id  | Operation         | Name                       | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |                            |   175 |  2275 |  4357   (2)| 00:00:53 |
|*  1 |  TABLE ACCESS FULL| TC_RES_PHY_EQP_PRO_MID_517 |   175 |  2275 |  4357   (2)| 00:00:53 |
------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("A"."OBJ_ID"=17202000000001)

Note
-----
   - dynamic sampling used for this statement (level=2)


统计信息
----------------------------------------------------------
          0  recursive calls
          0  db block gets
      15730  consistent gets
          0  physical reads
          0  redo size
        520  bytes sent via SQL*Net to client
        520  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

--现在删除大部分数据,只剩下一条测试数据:
SQL> DELETE FROM TC_RES_PHY_EQP_PRO_MID_517 a WHERE a.obj_id <> 17202000000001;

已删除1172857行。

--查询该段占用的表空间仍然为128M
SQL> set autotrace off
SQL> SELECT a.bytes/1024/1024 || &#39;M&#39; FROM user_segments a WHERE a.segment_name = &#39;TC_RES_PHY_EQP_PRO_MID_517&#39;;

A.BYTES/1024/1024||&#39;M&#39;
-----------------------------------------
128M
SQL> COMMIT;

提交完成。

SQL> SELECT a.bytes/1024/1024 || &#39;M&#39; FROM user_segments a WHERE a.segment_name = &#39;TC_RES_PHY_EQP_PRO_MID_517&#39;;

A.BYTES/1024/1024||&#39;M&#39;
-----------------------------------------
128M

--查询一条记录消耗的成本为:4316,一致性读为:15730 耗时 0.52 秒
SQL> set autotrace on
SQL> SELECT 1 FROM TC_RES_PHY_EQP_PRO_MID_517 a WHERE a.obj_id = 17202000000001;

         1
----------
         1


执行计划
----------------------------------------------------------
Plan hash value: 854298875

------------------------------------------------------------------------------------------------
| Id  | Operation         | Name                       | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |                            |     1 |    13 |  4316   (1)| 00:00:52 |
|*  1 |  TABLE ACCESS FULL| TC_RES_PHY_EQP_PRO_MID_517 |     1 |    13 |  4316   (1)| 00:00:52 |
------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("A"."OBJ_ID"=17202000000001)

Note
-----
   - dynamic sampling used for this statement (level=2)


统计信息
----------------------------------------------------------
          0  recursive calls
          0  db block gets
      15730  consistent gets
          0  physical reads
          0  redo size
        520  bytes sent via SQL*Net to client
        520  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

--一般情况下,表的rowid是不会变的,我们通过ALTER TABLE TABLE_NAME ENABLE ROW MOVEMENT;来打开行迁移
SQL> ALTER TABLE TC_RES_PHY_EQP_PRO_MID_517 ENABLE ROW MOVEMENT;

表已更改。

--整理碎片并回收空间
--此操作相比于ALTER TABLE MOVE:
--1.不会消耗更多的表空间
--2.可以在线执行,不会使索引失效
--3.可以使用参数CASCADE,同时收缩表上的索引
--4.ALTER TABLE MOVE之后表空间的位置肯定会发生变化,而SHRINK表空间的位置没有发生变化
SQL> ALTER TABLE TC_RES_PHY_EQP_PRO_MID_517 SHRINK SPACE;

表已更改。
--查询一条记录消耗的成本为:2,一致性读为:4 耗时 0.01 秒
SQL> SELECT 1 FROM TC_RES_PHY_EQP_PRO_MID_517 a WHERE a.obj_id = 17202000000001;

         1
----------
         1


执行计划
----------------------------------------------------------
Plan hash value: 854298875

------------------------------------------------------------------------------------------------
| Id  | Operation         | Name                       | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |                            |     1 |    13 |     2   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| TC_RES_PHY_EQP_PRO_MID_517 |     1 |    13 |     2   (0)| 00:00:01 |
------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("A"."OBJ_ID"=17202000000001)

Note
-----
   - dynamic sampling used for this statement (level=2)


统计信息
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          4  consistent gets
          0  physical reads
          0  redo size
        520  bytes sent via SQL*Net to client
        520  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
--此时占用表空间只有4M
SQL> SELECT a.bytes/1024/1024 || &#39;M&#39; FROM user_segments a WHERE a.segment_name = &#39;TC_RES_PHY_EQP_PRO_MID_517&#39;;

A.BYTES/1024/1024||&#39;M&#39;
-----------------------------------------
4M

当然ENABLE ROW MOVEMENT对系统性能也有影响,在TOM的博客中找到这个关于ROW MOVEMENT的问答:

You Asked
Hi Tom 
I have seen your posting on ENABLE ROW MOVEMENT which is available in 10g. It looks a 
very nice option since we can relocate and reorganize  the heap tables without any outage 
since it does not invalidate indexes. But is there any performance hit or any other 
disadvantages for using this. I would like to use this in our new application.
Rgds
Anil 
and we said...
Well, the tables have to be in an ASSM (Automatic Segment Space Managment) tablespace for 
this to work (so if they are not, you have to move them there first in order to do this 
over time).
It will necessarily consume processing resources on your machine while running (it will 
read the table, it will delete/insert the rows at the bottom of the table to move them 
up, it will generate redo, it will generate undo).
I would suggest benchmarking -- collect performance metrics about the table before and 
after performing the operation.  You would expect full scans to operate more efficiently 
after, you would expect index range scans to either be unchanged or "better" as you have 
more rows per block packed together (less data spread).  You would be looking for that to 
happen -- statspack or the tools available in dbconsole would be useful for measuring 
that (the amount of work performed by your queries over time)

也就是说,ENABLE ROW MOVEMENT也会有副作用,因为表打开行迁移之后,如果对数据进行UPDATE操作,那么系统会对数据进行DELETE操作

之后再进行INSERT操作,导致产生更多的redo和undo,并且rowid也会发生变化。
附行迁移和行连接的解释:

row chain:When a row is too large to fit into any block, row chaining occurs. In this case, the Oracle devide the row into smaller chunks. each chunk is stored in a block along
 with the necessary poiters to retrive and assemble the entire row.
row migration:when a row is to be updated and it cannot find the necessary free space in its block, the Oracle will move the entire row into a new block and leave a pointer from the orginal block to the new location. This process is called row migration.
성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
MySQL의 라이센스는 다른 데이터베이스 시스템과 어떻게 비교됩니까?MySQL의 라이센스는 다른 데이터베이스 시스템과 어떻게 비교됩니까?Apr 25, 2025 am 12:26 AM

MySQL은 GPL 라이센스를 사용합니다. 1) GPL 라이센스는 MySQL의 무료 사용, 수정 및 분포를 허용하지만 수정 된 분포는 GPL을 준수해야합니다. 2) 상업용 라이센스는 공개 수정을 피할 수 있으며 기밀이 필요한 상업용 응용 프로그램에 적합합니다.

MyISAM을 통해 언제 innodb를 선택 하시겠습니까?MyISAM을 통해 언제 innodb를 선택 하시겠습니까?Apr 25, 2025 am 12:22 AM

MyISAM 대신 InnoDB를 선택할 때의 상황에는 다음이 포함됩니다. 1) 거래 지원, 2) 높은 동시성 환경, 3) 높은 데이터 일관성; 반대로, MyISAM을 선택할 때의 상황에는 다음이 포함됩니다. 1) 주로 읽기 작업, 2) 거래 지원이 필요하지 않습니다. InnoDB는 전자 상거래 플랫폼과 같은 높은 데이터 일관성 및 트랜잭션 처리가 필요한 응용 프로그램에 적합하지만 MyISAM은 블로그 시스템과 같은 읽기 집약적 및 트랜잭션이없는 애플리케이션에 적합합니다.

MySQL에서 외국 키의 목적을 설명하십시오.MySQL에서 외국 키의 목적을 설명하십시오.Apr 25, 2025 am 12:17 AM

MySQL에서 외국 키의 기능은 테이블 간의 관계를 설정하고 데이터의 일관성과 무결성을 보장하는 것입니다. 외국 키는 참조 무결성 검사 및 계단식 작업을 통해 데이터의 효과를 유지합니다. 성능 최적화에주의를 기울이고 사용할 때 일반적인 오류를 피하십시오.

MySQL의 다른 유형의 인덱스는 무엇입니까?MySQL의 다른 유형의 인덱스는 무엇입니까?Apr 25, 2025 am 12:12 AM

MySQL에는 B-Tree Index, Hash Index, Full-Text Index 및 공간 인덱스의 네 가지 주요 인덱스 유형이 있습니다. 1.B- 트리 색인은 범위 쿼리, 정렬 및 그룹화에 적합하며 직원 테이블의 이름 열에서 생성에 적합합니다. 2. HASH 인덱스는 동등한 쿼리에 적합하며 메모리 저장 엔진의 HASH_Table 테이블의 ID 열에서 생성에 적합합니다. 3. 전체 텍스트 색인은 기사 테이블의 내용 열에서 생성에 적합한 텍스트 검색에 사용됩니다. 4. 공간 지수는 지리 공간 쿼리에 사용되며 위치 테이블의 Geom 열에서 생성에 적합합니다.

MySQL에서 인덱스를 어떻게 생성합니까?MySQL에서 인덱스를 어떻게 생성합니까?Apr 25, 2025 am 12:06 AM

toreateanindexinmysql, usethecreateindexstatement.1) forasinglecolumn, "createindexidx_lastnameonemployees (lastname);"2) foracompositeIndex를 사용하고 "createDexIdx_nameonemployees (forstName, FirstName);"3)을 사용하십시오

MySQL은 sqlite와 어떻게 다릅니 까?MySQL은 sqlite와 어떻게 다릅니 까?Apr 24, 2025 am 12:12 AM

MySQL과 Sqlite의 주요 차이점은 설계 개념 및 사용 시나리오입니다. 1. MySQL은 대규모 응용 프로그램 및 엔터프라이즈 수준의 솔루션에 적합하며 고성능 및 동시성을 지원합니다. 2. SQLITE는 모바일 애플리케이션 및 데스크탑 소프트웨어에 적합하며 가볍고 내부질이 쉽습니다.

MySQL의 색인이란 무엇이며 성능을 어떻게 향상 시키는가?MySQL의 색인이란 무엇이며 성능을 어떻게 향상 시키는가?Apr 24, 2025 am 12:09 AM

MySQL의 인덱스는 데이터 검색 속도를 높이는 데 사용되는 데이터베이스 테이블에서 하나 이상의 열의 주문 구조입니다. 1) 인덱스는 스캔 한 데이터의 양을 줄임으로써 쿼리 속도를 향상시킵니다. 2) B-Tree Index는 균형 잡힌 트리 구조를 사용하여 범위 쿼리 및 정렬에 적합합니다. 3) CreateIndex 문을 사용하여 CreateIndexIdx_customer_idonorders (customer_id)와 같은 인덱스를 작성하십시오. 4) Composite Indexes는 CreateIndexIdx_customer_orderOders (Customer_id, Order_Date)와 같은 다중 열 쿼리를 최적화 할 수 있습니다. 5) 설명을 사용하여 쿼리 계획을 분석하고 피하십시오

MySQL에서 트랜잭션을 사용하여 데이터 일관성을 보장하는 방법을 설명하십시오.MySQL에서 트랜잭션을 사용하여 데이터 일관성을 보장하는 방법을 설명하십시오.Apr 24, 2025 am 12:09 AM

MySQL에서 트랜잭션을 사용하면 데이터 일관성이 보장됩니다. 1) STARTTRANSACTION을 통해 트랜잭션을 시작한 다음 SQL 작업을 실행하고 커밋 또는 롤백으로 제출하십시오. 2) SavePoint를 사용하여 부분 롤백을 허용하는 저장 지점을 설정하십시오. 3) 성능 최적화 제안에는 트랜잭션 시간 단축, 대규모 쿼리 방지 및 격리 수준을 합리적으로 사용하는 것이 포함됩니다.

See all articles

핫 AI 도구

Undresser.AI Undress

Undresser.AI Undress

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

AI Clothes Remover

AI Clothes Remover

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

Undress AI Tool

Undress AI Tool

무료로 이미지를 벗다

Clothoff.io

Clothoff.io

AI 옷 제거제

Video Face Swap

Video Face Swap

완전히 무료인 AI 얼굴 교환 도구를 사용하여 모든 비디오의 얼굴을 쉽게 바꾸세요!

뜨거운 도구

WebStorm Mac 버전

WebStorm Mac 버전

유용한 JavaScript 개발 도구

드림위버 CS6

드림위버 CS6

시각적 웹 개발 도구

Eclipse용 SAP NetWeaver 서버 어댑터

Eclipse용 SAP NetWeaver 서버 어댑터

Eclipse를 SAP NetWeaver 애플리케이션 서버와 통합합니다.

에디트플러스 중국어 크랙 버전

에디트플러스 중국어 크랙 버전

작은 크기, 구문 강조, 코드 프롬프트 기능을 지원하지 않음

안전한 시험 브라우저

안전한 시험 브라우저

안전한 시험 브라우저는 온라인 시험을 안전하게 치르기 위한 보안 브라우저 환경입니다. 이 소프트웨어는 모든 컴퓨터를 안전한 워크스테이션으로 바꿔줍니다. 이는 모든 유틸리티에 대한 액세스를 제어하고 학생들이 승인되지 않은 리소스를 사용하는 것을 방지합니다.