搜尋
首頁資料庫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
如何查证JBL耳机的真假信息如何查证JBL耳机的真假信息Dec 29, 2023 pm 10:54 PM

jbl耳机是很多听音乐用户的首选,好评如潮,但是对于假货大家还是非常的害怕的,那么jbl耳机怎么查询真伪来避免这个问题呢?下面就看看怎么查询吧。jbl耳机怎么查询真伪:1、首先进入“中国商品信息验证中心”。2、然后输入查询码,即可查看是否正确从而判断是不是真货。3、也可以去通过耳机声音的清晰度来进行分辨。正牌的耳机声音是非常的清晰的,音质也不会出现改变。假牌的耳机声音会有很多的掺杂,音质也是特别的差。4、大家可以将自己的耳机声音开到最大,看看是不是很和谐,真耳机声音都是一样的。但是假耳机的声音开

买过比特币怎么查询,怎么看自己买没买过比特币买过比特币怎么查询,怎么看自己买没买过比特币Feb 04, 2024 am 08:09 AM

现在怎么买比特币的800字公众号文章随着比特币的价格飙升,越来越多的人开始关注比特币,也有越来越多的人想要投资比特币。但是,投资比特币也是有风险的,所以在投资之前,需要了解相关知识,并做好风险控制。那么现在怎么买比特币呢?首先,为了投资比特币,您需要准备一个比特币钱包。比特币钱包是一种软件,用于存储、发送和接收比特币资金。根据您的需求,有多种类型的比特币钱包可供选择,例如硬件钱包、软件钱包和网络钱包。每种钱包都有其独特的特点,您可以根据自己的需求选择适合自己的。其次,你需要选择一个可靠的比特币交

PHP如何查询Oracle数据库中的数据PHP如何查询Oracle数据库中的数据Jul 13, 2023 pm 07:34 PM

PHP如何查询Oracle数据库中的数据随着互联网时代的到来,网站和应用程序的开发越来越普遍。而数据库作为数据存储和管理的关键技术,也成为了开发者们必备的工具之一。其中,Oracle数据库作为一款功能强大、稳定可靠的关系型数据库管理系统,在企业级应用中得到了广泛应用。而在开发网站或应用程序时,如何使用PHP进行Oracle数据库的查询是一个非常重要的问题。在

PHP表单处理:表单数据查询与筛选PHP表单处理:表单数据查询与筛选Aug 07, 2023 pm 06:17 PM

PHP表单处理:表单数据查询与筛选引言在Web开发中,表单是一种重要的交互方式,用户可以通过表单向服务器提交数据并进行进一步的处理。本文将介绍如何使用PHP处理表单数据的查询与筛选功能。表单的设计与提交首先,我们需要设计一个包含查询与筛选功能的表单。常见的表单元素包括输入框、下拉列表、单选框、复选框等,根据具体需求进行设计。用户在提交表单时,会将数据以POS

查询从节点X开始,距离最多为D的子树中的最小权重查询从节点X开始,距离最多为D的子树中的最小权重Aug 25, 2023 am 11:25 AM

在进行计算机编程时,有时需要求出源自特定节点的子树的最小权重,条件是该子树不能包含距离指定节点超过D个单位的节点。这个问题出现在各个领域和应用中,包括图论、基于树的算法和网络优化。子树是较大树结构的子集,指定的节点作为子树的根节点。子树包含根节点的所有后代及其连接边。节点的权重是指分配给该节点的特定值,可以表示其重要性、重要性或其他相关指标。在这个问题中,目标是找到子树中所有节点中的最小权重,同时将子树限制在距离根节点最多D个单位的节点。在下面的文章中,我们将深入研究从子树中挖掘最小权重的复杂性

MySQL中如何进行数据的时序存储和查询?MySQL中如何进行数据的时序存储和查询?Jul 30, 2023 pm 03:09 PM

MySQL中如何进行数据的时序存储和查询?在许多应用场景中,对于数据的时序性要求是非常常见的,比如传感器数据的监测、日志记录等。MySQL作为一种常用的关系型数据库,也提供了一些方法来进行时序数据的存储和查询。一种常见的方法是使用时间戳字段来存储数据的时间信息。在MySQL中,可以使用TIMESTAMP或DATETIME类型的字段来存储时间。TIMESTAM

如何通过优化查询中的LIKE操作来提高MySQL性能如何通过优化查询中的LIKE操作来提高MySQL性能May 11, 2023 am 08:11 AM

MySQL是目前最流行的关系型数据库之一,但是在处理大量数据时,MySQL的性能可能会受到影响。其中,一种常见的性能瓶颈是查询中的LIKE操作。在MySQL中,LIKE操作是用来模糊匹配字符串的,它可以在查询数据表时用来查找包含指定字符或者模式的数据记录。但是,在大型数据表中,如果使用LIKE操作,它会对数据库的性能造成影响。为了解决这个问题,我们可

高德地图API文档解读:Java代码实现公交车在线运行状态查询高德地图API文档解读:Java代码实现公交车在线运行状态查询Jul 29, 2023 pm 10:45 PM

高德地图API文档解读:Java代码实现公交车在线运行状态查询导语:随着城市的发展,公共交通的重要性越来越凸显出来。人们对公交车的运行状态有着强烈的需求,例如实时到站时间、拥挤程度等信息。高德地图提供了强大的API以满足这方面的需求。本文将解读高德地图API文档,使用Java代码实现公交车在线运行状态查询,并提供代码示例。API概述高德地图API提供了丰富的

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脫衣器

AI Hentai Generator

AI Hentai Generator

免費產生 AI 無盡。

熱門文章

R.E.P.O.能量晶體解釋及其做什麼(黃色晶體)
2 週前By尊渡假赌尊渡假赌尊渡假赌
倉庫:如何復興隊友
4 週前By尊渡假赌尊渡假赌尊渡假赌
Hello Kitty Island冒險:如何獲得巨型種子
4 週前By尊渡假赌尊渡假赌尊渡假赌

熱工具

MantisBT

MantisBT

Mantis是一個易於部署的基於Web的缺陷追蹤工具,用於幫助產品缺陷追蹤。它需要PHP、MySQL和一個Web伺服器。請查看我們的演示和託管服務。

DVWA

DVWA

Damn Vulnerable Web App (DVWA) 是一個PHP/MySQL的Web應用程序,非常容易受到攻擊。它的主要目標是成為安全專業人員在合法環境中測試自己的技能和工具的輔助工具,幫助Web開發人員更好地理解保護網路應用程式的過程,並幫助教師/學生在課堂環境中教授/學習Web應用程式安全性。 DVWA的目標是透過簡單直接的介面練習一些最常見的Web漏洞,難度各不相同。請注意,該軟體中

SublimeText3 英文版

SublimeText3 英文版

推薦:為Win版本,支援程式碼提示!

SAP NetWeaver Server Adapter for Eclipse

SAP NetWeaver Server Adapter for Eclipse

將Eclipse與SAP NetWeaver應用伺服器整合。

Dreamweaver Mac版

Dreamweaver Mac版

視覺化網頁開發工具