0
這是我的選擇查詢。Oracle選擇查詢花費很長時間
select count(m.uniq_no) cnt
from web_cst_mst m
inner join WEB_CST_INV i on M.UNIQ_NO=I.UNIQ_NO
where I.INV_NO='inv01'
and I.INV_DT=to_date('2015-01-12','YYYY-MM-DD')
and M.sel_tin='19320703277'
;
我已經創建了一個(uniq_no,sel_tin)
指數web_cst_mst
表和(uniq_no,inv_no,inv_dt)
爲web_cst_inv
表的索引。
該查詢需要大約250ms才能執行。之前它曾經需要500毫秒,當我有修剪功能賣方tin(trim(M.sel_tin))
。我刪除了修剪,它是原來的時間的一半,所以我想如果我可以刪除to_date功能,那麼它可能需要較少的時間,但我在這裏面臨的問題是我發送日期字符串格式,因爲我不能發送c#
日期變量在(10-JAN-14)
這種格式中,因爲c#
日期變量也保持時間。我試過下面的代碼只是爲了發送日期部分,以便我可以刪除oracle中的to_date函數,但它不工作。並且oracle中的日期以(dd-MMM-yy ex:10-JAN-14)
格式存儲。所以無論我只需要發送日期部分還是必須在查詢中有to_date函數。
我想只發送日期時間變量的日期部分以提高此查詢的性能。但我無法做到這一點。
任何建議/有助於提高性能。謝謝。
DateTime inv_date = DateTime.ParseExact(inv_dt, "dd-MMM-yy", CultureInfo.InvariantCulture).Date;
*您應該*使用參數化查詢和傳遞的字符串而不是實際的日期時間值,以避免轉換錯誤。例如,你提到的格式('10-JAN-14')保證失敗*並*引入Y2K錯誤。儘管如此,這*不會對性能有所幫助。 'to_date'應用於可用於搜索索引的單個字符串。另一方面,'Trim'必須應用於* all *行,以防止使用索引。 –
你看過sql執行計劃嗎? –