如何改進這個SQL查詢？

我相信這是在Oracle上運行的SQL查詢：如何改進這個SQL查詢？

SELECT ID, DEVICE_TYPE, S3_KEY, TO_CHAR(CREATION_DATE, 'YYYY-MM-DD HH24:MI:SS') AS CREATION_DAT 
FROM KASE_DDL.ARCHIVED_LOG 
WHERE 
    CREATION_DATE >= TO_DATE('{DIST_YYYY/MM/DD HH24:MI:SS_UTC}', 'YYYY/MM/DD HH24:MI:SS') 
    AND CREATION_DATE <= TO_DATE('{DIET_YYYY/MM/DD HH24:MI:SS_UTC}', 'YYYY/MM/DD HH24:MI:SS')

它運行速度慢，我不知道如何可以把它改寫，以提高其效率。例如，如果在CREATION_DATE上建立了索引，此查詢是否可以使用索引？我記得讀過一些書，說如果圍繞某列進行計算，Oracle可能無法使用任何建立在其上的索引。我的查詢是否屬於這種情況？任何其他建議？謝謝。

更新：

在我的問題，CREATION_DATE有內置的索引我很好奇這個查詢是否能夠利用索引或不是數據庫。

來源

2012-12-18 Steve

你有'（CREATION_DATE）'索引嗎？ –

查詢不是顯然的問題。嘗試在creation_date上添加索引。 –

這裏沒有函數應用於'where'中的'CREATION_DATE'列，該函數位於另一邊。如果適當的話，沒有理由不採取索引（你真的可以試一試）。 – Mat

添加索引CREATION_DATE。

我還會在日期中使用BETWEEN運算符，但我喜歡這樣讀。

來源

2012-12-18 17:06:39

** [BETWEEN和魔鬼有什麼共同點？]（http://sqlblog.com/blogs/aaron_bertrand/archive/2011/10/19/what-do-between-and-the-devil-have- in-common.aspx）** –

@ypercube嗯，很明顯，在使用它之前要看看操作員是如何工作的。這就是我將文檔鏈接起來的原因。 –

當我確定數據類型是'DATE'時，我不介意使用'BETWEEN'。使用開閉時間間隔（使用'> ='，'<'）更容易，因爲它與所有日期時間數據類型一樣工作得很好。 –

爲了獲得額外的性能增益，您可以嘗試使用覆蓋索引。你的情況有

create index ndxCovering on KASE_DDL.ARCHIVED_LOG(CREATION_DATE, ID, DEVICE_TYPE, S3_KEY);

它允許在沒有數據頁的尋求只讀從索引頁的數據。

來源

2012-12-19 11:33:39 knagaev

您可以通過比較user_indexes表中的clustering_factor與表格的行數和塊數來檢查索引的可能有效性。聚類因子將在塊的數量和行數之間，分別表示理論最小值和最大值。

如果聚類因子更接近塊的數量（即它相對較小），那麼索引將更有可能被選擇，並且基於訪問索引從表中選擇塊將需要較少的工作由系統。

如果您對使用索引訪問表時看到的性能改進有任何懷疑，那麼總是值得一試。

來源

2012-12-19 11:38:21

如何改進這個SQL查詢？

回答

相關問題