众所周知,随着不断地进行表记录的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)商業ライセンスは、公的な変更を回避でき、機密性を必要とする商用アプリケーションに適しています。

Myisamの代わりにInnoDBを選択する場合の状況には、次のものが含まれます。1)トランザクションサポート、2)高い並行性環境、3)高いデータの一貫性。逆に、Myisamを選択する際の状況には、1)主に操作を読む、2)トランザクションサポートは必要ありません。 INNODBは、eコマースプラットフォームなどの高いデータの一貫性とトランザクション処理を必要とするアプリケーションに適していますが、Myisamはブログシステムなどの読み取り集約型およびトランザクションのないアプリケーションに適しています。

MySQLでは、外部キーの機能は、テーブル間の関係を確立し、データの一貫性と整合性を確保することです。外部キーは、参照整合性チェックとカスケード操作を通じてデータの有効性を維持します。パフォーマンスの最適化に注意し、それらを使用するときに一般的なエラーを避けてください。

MySQLには、B-Treeインデックス、ハッシュインデックス、フルテキストインデックス、空間インデックスの4つのメインインデックスタイプがあります。 1.B-Treeインデックスは、範囲クエリ、ソート、グループ化に適しており、従業員テーブルの名前列の作成に適しています。 2。HASHインデックスは、同等のクエリに適しており、メモリストレージエンジンのHASH_TABLEテーブルのID列の作成に適しています。 3。フルテキストインデックスは、記事テーブルのコンテンツ列の作成に適したテキスト検索に使用されます。 4.空間インデックスは、地理空間クエリに使用され、場所テーブルのGEOM列での作成に適しています。

tocreateanindexinmysql、usethecreateindexstatement.1)forasinglecolumn、 "createdexidx_lastnameonemployees(lastname);" 2)foracompositeindexを使用して、 "createindexidx_nameonemployees(lastname、firstname);" 3); "3)、" 3)を使用します

MySQLとSQLiteの主な違いは、設計コンセプトと使用法のシナリオです。1。MySQLは、大規模なアプリケーションとエンタープライズレベルのソリューションに適しており、高性能と高い並行性をサポートしています。 2。SQLiteは、モバイルアプリケーションとデスクトップソフトウェアに適しており、軽量で埋め込みやすいです。

MySQLのインデックスは、データの取得をスピードアップするために使用されるデータベーステーブル内の1つ以上の列の順序付けられた構造です。 1)インデックスは、スキャンされたデータの量を減らすことにより、クエリ速度を改善します。 2)B-Tree Indexは、バランスの取れたツリー構造を使用します。これは、範囲クエリとソートに適しています。 3)CreateIndexステートメントを使用して、createIndexidx_customer_idonorders(customer_id)などのインデックスを作成します。 4)Composite Indexesは、createIndexIDX_CUSTOMER_ORDERONORDERS(Customer_Id、Order_date)などのマルチコラムクエリを最適化できます。 5)説明を使用してクエリ計画を分析し、回避します

MySQLでトランザクションを使用すると、データの一貫性が保証されます。 1)StartTransactionを介してトランザクションを開始し、SQL操作を実行して、コミットまたはロールバックで送信します。 2)SavePointを使用してSave Pointを設定して、部分的なロールバックを許可します。 3)パフォーマンスの最適化の提案には、トランザクション時間の短縮、大規模なクエリの回避、分離レベルの使用が合理的に含まれます。


ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

Video Face Swap
完全無料の AI 顔交換ツールを使用して、あらゆるビデオの顔を簡単に交換できます。

人気の記事

ホットツール

Dreamweaver Mac版
ビジュアル Web 開発ツール

VSCode Windows 64 ビットのダウンロード
Microsoft によって発売された無料で強力な IDE エディター

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

Safe Exam Browser
Safe Exam Browser は、オンライン試験を安全に受験するための安全なブラウザ環境です。このソフトウェアは、あらゆるコンピュータを安全なワークステーションに変えます。あらゆるユーティリティへのアクセスを制御し、学生が無許可のリソースを使用するのを防ぎます。

ドリームウィーバー CS6
ビジュアル Web 開発ツール

ホットトピック









