众所周知,随着不断地进行表记录的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 || 'M' FROM user_segments a WHERE a.segment_name = 'TC_RES_PHY_EQP_PRO_MID_517'; A.BYTES/1024/1024||'M' ----------------------------------------- 128M SQL> COMMIT; 提交完成。 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 --查询一条记录消耗的成本为: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 || 'M' FROM user_segments a WHERE a.segment_name = 'TC_RES_PHY_EQP_PRO_MID_517'; A.BYTES/1024/1024||'M' ----------------------------------------- 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.

MySQL使用的是GPL許可證。 1)GPL許可證允許自由使用、修改和分發MySQL,但修改後的分發需遵循GPL。 2)商業許可證可避免公開修改,適合需要保密的商業應用。

選擇InnoDB而不是MyISAM的情況包括:1)需要事務支持,2)高並發環境,3)需要高數據一致性;反之,選擇MyISAM的情況包括:1)主要是讀操作,2)不需要事務支持。 InnoDB適合需要高數據一致性和事務處理的應用,如電商平台,而MyISAM適合讀密集型且無需事務的應用,如博客系統。

在MySQL中,外鍵的作用是建立表與表之間的關係,確保數據的一致性和完整性。外鍵通過引用完整性檢查和級聯操作維護數據的有效性,使用時需注意性能優化和避免常見錯誤。

MySQL中有四種主要的索引類型:B-Tree索引、哈希索引、全文索引和空間索引。 1.B-Tree索引適用於範圍查詢、排序和分組,適合在employees表的name列上創建。 2.哈希索引適用於等值查詢,適合在MEMORY存儲引擎的hash_table表的id列上創建。 3.全文索引用於文本搜索,適合在articles表的content列上創建。 4.空間索引用於地理空間查詢,適合在locations表的geom列上創建。

toCreateAnIndexinMysql,usethecReateIndexStatement.1)forasingLecolumn,使用“ createIndexIdx_lastNameEnemployees(lastName); 2)foracompositeIndex,使用“ createIndexIndexIndexIndexIndexDx_nameOmplayees(lastName,firstName,firstName);” 3)forauniqe instex,creationexexexexex,

MySQL和SQLite的主要區別在於設計理念和使用場景:1.MySQL適用於大型應用和企業級解決方案,支持高性能和高並發;2.SQLite適合移動應用和桌面軟件,輕量級且易於嵌入。

MySQL中的索引是數據庫表中一列或多列的有序結構,用於加速數據檢索。 1)索引通過減少掃描數據量提升查詢速度。 2)B-Tree索引利用平衡樹結構,適合範圍查詢和排序。 3)創建索引使用CREATEINDEX語句,如CREATEINDEXidx_customer_idONorders(customer_id)。 4)複合索引可優化多列查詢,如CREATEINDEXidx_customer_orderONorders(customer_id,order_date)。 5)使用EXPLAIN分析查詢計劃,避

在MySQL中使用事務可以確保數據一致性。 1)通過STARTTRANSACTION開始事務,執行SQL操作後用COMMIT提交或ROLLBACK回滾。 2)使用SAVEPOINT可以設置保存點,允許部分回滾。 3)性能優化建議包括縮短事務時間、避免大規模查詢和合理使用隔離級別。


熱AI工具

Undresser.AI Undress
人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

Video Face Swap
使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱門文章

熱工具

WebStorm Mac版
好用的JavaScript開發工具

Safe Exam Browser
Safe Exam Browser是一個安全的瀏覽器環境,安全地進行線上考試。該軟體將任何電腦變成一個安全的工作站。它控制對任何實用工具的訪問,並防止學生使用未經授權的資源。

SublimeText3 Linux新版
SublimeText3 Linux最新版

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

SublimeText3 Mac版
神級程式碼編輯軟體(SublimeText3)