搜索
首页数据库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
与其他RDBM相比,MySQL如何处理并发?与其他RDBM相比,MySQL如何处理并发?Apr 29, 2025 am 12:44 AM

MySQLhandlesconcurrencyusingamixofrow-levelandtable-levellocking,primarilythroughInnoDB'srow-levellocking.ComparedtootherRDBMS,MySQL'sapproachisefficientformanyusecasesbutmayfacechallengeswithdeadlocksandlacksadvancedfeatureslikePostgreSQL'sSerializa

MySQL与其他关系数据库相比如何处理交易?MySQL与其他关系数据库相比如何处理交易?Apr 29, 2025 am 12:37 AM

mysqlHandLestActionSefectefectionalytheinnodbengine,supportingAcidPropertiessimilartopostgresqlesqlandoracle.1)mySqluessRepeTableReadAbleDasthEdefaultIsolationLelealevel,该canbeadjustEdToreDtoreDtoreadCommententCommententCommententCommententCommittedForHigh-TrafficsCenarios.2)

MySQL中有哪些数据类型?MySQL中有哪些数据类型?Apr 29, 2025 am 12:28 AM

MySQL的数据类型分为数值、日期和时间、字符串、二进制和空间类型。选择正确的类型可以优化数据库性能和数据存储。

在MySQL中编写有效的SQL查询的最佳实践是什么?在MySQL中编写有效的SQL查询的最佳实践是什么?Apr 29, 2025 am 12:24 AM

最佳实践包括:1)理解数据结构和MySQL处理方式,2)适当索引,3)避免SELECT*,4)使用合适的JOIN类型,5)谨慎使用子查询,6)使用EXPLAIN分析查询,7)考虑查询对服务器资源的影响,8)定期维护数据库。这些做法能使MySQL查询不仅快速,还具备可维护性、可扩展性和资源效率。

MySQL与PostgreSQL有何不同?MySQL与PostgreSQL有何不同?Apr 29, 2025 am 12:23 AM

MySQLisbetterforspeedandsimplicity,suitableforwebapplications;PostgreSQLexcelsincomplexdatascenarioswithrobustfeatures.MySQLisidealforquickprojectsandread-heavytasks,whilePostgreSQLispreferredforapplicationsrequiringstrictdataintegrityandadvancedSQLf

MySQL如何处理数据复制?MySQL如何处理数据复制?Apr 28, 2025 am 12:25 AM

MySQL通过异步、半同步和组复制三种模式处理数据复制。1)异步复制性能高但可能丢失数据。2)半同步复制提高数据安全性但增加延迟。3)组复制支持多主复制和故障转移,适用于高可用性需求。

您如何使用解释性语句分析查询性能?您如何使用解释性语句分析查询性能?Apr 28, 2025 am 12:24 AM

EXPLAIN语句可用于分析和提升SQL查询性能。1.执行EXPLAIN语句查看查询计划。2.分析输出结果,关注访问类型、索引使用情况和JOIN顺序。3.根据分析结果,创建或调整索引,优化JOIN操作,避免全表扫描,以提升查询效率。

您如何备份并还原MySQL数据库?您如何备份并还原MySQL数据库?Apr 28, 2025 am 12:23 AM

使用mysqldump进行逻辑备份和MySQLEnterpriseBackup进行热备份是备份MySQL数据库的有效方法。1.使用mysqldump备份数据库:mysqldump-uroot-pmydatabase>mydatabase_backup.sql。2.使用MySQLEnterpriseBackup进行热备份:mysqlbackup--user=root--password=password--backup-dir=/path/to/backupbackup。恢复时,使用相应的命

See all articles

热AI工具

Undresser.AI Undress

Undresser.AI Undress

人工智能驱动的应用程序,用于创建逼真的裸体照片

AI Clothes Remover

AI Clothes Remover

用于从照片中去除衣服的在线人工智能工具。

Undress AI Tool

Undress AI Tool

免费脱衣服图片

Clothoff.io

Clothoff.io

AI脱衣机

Video Face Swap

Video Face Swap

使用我们完全免费的人工智能换脸工具轻松在任何视频中换脸!

热工具

mPDF

mPDF

mPDF是一个PHP库,可以从UTF-8编码的HTML生成PDF文件。原作者Ian Back编写mPDF以从他的网站上“即时”输出PDF文件,并处理不同的语言。与原始脚本如HTML2FPDF相比,它的速度较慢,并且在使用Unicode字体时生成的文件较大,但支持CSS样式等,并进行了大量增强。支持几乎所有语言,包括RTL(阿拉伯语和希伯来语)和CJK(中日韩)。支持嵌套的块级元素(如P、DIV),

安全考试浏览器

安全考试浏览器

Safe Exam Browser是一个安全的浏览器环境,用于安全地进行在线考试。该软件将任何计算机变成一个安全的工作站。它控制对任何实用工具的访问,并防止学生使用未经授权的资源。

SublimeText3 Mac版

SublimeText3 Mac版

神级代码编辑软件(SublimeText3)

SecLists

SecLists

SecLists是最终安全测试人员的伙伴。它是一个包含各种类型列表的集合,这些列表在安全评估过程中经常使用,都在一个地方。SecLists通过方便地提供安全测试人员可能需要的所有列表,帮助提高安全测试的效率和生产力。列表类型包括用户名、密码、URL、模糊测试有效载荷、敏感数据模式、Web shell等等。测试人员只需将此存储库拉到新的测试机上,他就可以访问到所需的每种类型的列表。

适用于 Eclipse 的 SAP NetWeaver 服务器适配器

适用于 Eclipse 的 SAP NetWeaver 服务器适配器

将Eclipse与SAP NetWeaver应用服务器集成。