2011-03-22 33 views
2

實際上,許多Oracle SQL調優專業人員會將 表中的行重新排序爲與主索引相同的物理 順序。如何在磁盤上以物理順序重新排序錶行?

來源:http://www.remote-dba.net/t_op_sql_index_access.htm

如何在磁盤上的物理順序一個重排序表中的行?這是「索引組織表」嗎?

+2

被引用的網站對其提供的數據量及其(有時)過時的技術的搜索結果非常高。甲骨文從二十世紀九十年代後期開始推出三大版本,自動涵蓋了前幾十年的大部分調優建議。 – 2011-03-22 00:28:59

回答

2

通常使用sql-loader來卸載和加載表。但是,請參閱Tom Kyte關於表格重載和不平衡索引的副作用的文章。

索引組織表是一把雙刃劍:是的,它將表數據放在與(主鍵)索引相同的塊中,從而避免了1個磁盤I/O。這也意味着,只要需要以任何其他順序訪問,要訪問該表的數據量就會增加。

物聯網的最佳用途是作爲查找表或驗證表,其中除關鍵值之外幾乎沒有附加信息。

3

通常你不會。

有可能與

CREATE TABLE ... AS SELECT .... ORDER BY

但隨後你進入刪除舊錶和重命名的業務新的補助金,限制等。

但是物聯網必須在主鍵上組織。如果您的意思是表格中大多數範圍掃描所用的索引,那麼這可能不是「主要」索引。

請考慮一個CUSTOMERS表,其中ID爲主鍵和客戶名稱。如果你正在尋找一個基於id的客戶,那麼集羣並沒有任何好處,因爲你並不是真正對ID高於或低於ID的客戶感興趣。如果您正在尋找名爲「Seinfeld」的客戶,那麼您可以進行範圍掃描,並且在所有的Seinfeld表格記錄中可能有一個好處。如果你打算在first_name上進行篩選,那麼你最好將它包括在索引中,這樣你就不需要訪問表記錄。

在'ORDER_LINES'表中,無論如何,您可能會在同一個塊中找到特定訂單的所有行,因爲它們可能是同時創建的。索引上的聚類因子會告訴你。

如果您對特定客戶的所有發票有很多查詢,CUSTOMER_INVOICES表可能會受益於集羣在客戶ID上。在這種情況下,您可以可能查看Single Table Hash Clusters作爲對列值進行數據集羣的方式。但是,這將是我的事情清單

+0

+1 - 你打了我幾分鐘。我只是討厭在我處於中間時丟棄一個答案。 – 2011-03-22 00:55:19

4

如果您正在執行主鍵索引的範圍掃描,只希望堆表中的數據與主鍵索引進行物理排序然後在表中進行單行查找。這往往是相對不常見的 - 例如,您通常不希望從ORDER表中獲取ORDER_ID 1-100的所有數據。如果您使用自然的多列主鍵,可能會更常見,但這有點不尋常。

如果您發現自己的表經常在主鍵上進行索引範圍掃描,並且希望優化該特定訪問路徑,那麼使用索引組織表或散列簇幾乎肯定會更好以便讓Oracle自動處理行的物理排序。當您只需指示Oracle維護訂單時,通過定期重組表格就可以爲自己制定維護難題,這沒什麼意義。當然,對這個訪問路徑進行優化會降低通過任何其他索引訪問表的效率,所以它遠沒有免費的選項。

即使在您對主鍵進行索引範圍掃描並且優化訪問路徑的權衡大於其他索引訪問方法的成本的情況下,表中行的物理順序也將具有對執行查詢的成本影響相對較小。絕大多數查詢和進程都有可能獲得更高級別的優化,而使用標準SQL調優技術的問題要少得多,而不是打擾表中行的順序。注意事項1:如果您碰巧試圖壓縮表格(而不是使用「高級壓縮」選項),表格中行的順序可能很重要,因爲更好的有序數據更容易壓縮。這是我唯一一次關心數據的物理順序。注意事項2:如果您確實有一張符合所有標準的表格,並且您在表格中對數據進行了物理排序,並且恰好使用RAC,則可以通過集中「有趣的」功能創建更多的互連流量,行變成更少的熱塊,這些熱塊必須不斷地在節點之間傳遞。這可以很容易地抵消從重組表格所得到的任何邊際收益​​。

+0

請原諒我的無知,但不是'返回ID爲1到100的所有訂單商品是非常普遍的事件? – allenwlee 2015-03-13 14:03:37

+0

@allenwlee - 不正常,不。您經常想要獲取特定客戶發出的所有訂單。您通常希望獲得在特定時間範圍內的所有訂單(與'order_id'邏輯上強相關,但不會在'order_id'上使用索引)。您通常不希望在一個任意'order_id'與另一個任意之間獲得訂單,而無需參考不同的驅動列。 – 2015-03-13 14:09:42

+0

明白了。如果你正在運行「所有」記錄的統計數據 - 在這種情況下,這是否適用?那麼重新排序會有意義嗎? – allenwlee 2015-03-13 14:47:53