以下的文章抓喲是對(duì)Oracle SQL執(zhí)行緩慢的原因的分析，如果Oracle數(shù)據(jù)庫(kù)中的某張表的相關(guān)數(shù)據(jù)已是2億多時(shí)，同時(shí)此表也創(chuàng)建了相關(guān)的4個(gè)獨(dú)立的相關(guān)索引。由于業(yè)務(wù)方面的需要，每天需分兩次向此表中插入300萬(wàn)條記錄。
由于數(shù)據(jù)量大，每次插入耗時(shí)3個(gè)小時(shí)以上，嚴(yán)重影響效率。
因此，修改了系統(tǒng)的算法，將此表中只存儲(chǔ)當(dāng)天新增記錄。將此表tbruncate后，第二天執(zhí)行對(duì)此表的update操作時(shí)，非常耗時(shí)。表中有2億多條數(shù)據(jù)的時(shí)候，此Oracle sql語(yǔ)句耗時(shí)59秒；表中有300萬(wàn)條數(shù)據(jù)的時(shí)候，此Oracle sql語(yǔ)句耗時(shí)幾個(gè)小時(shí)。
咨詢DBA后，得出結(jié)論，需重建索引。重建后，6秒完成此操作。但第三天問(wèn)題依然出現(xiàn)。DBA正在查找原因。難道每次truncate表，都需要重建索引？
對(duì)于這個(gè)問(wèn)題，DBA也沒(méi)有給出合理的解釋，推測(cè)主要原因是Oracle復(fù)雜的查詢優(yōu)化算法。
最終，DBA給出的解決方案：
truncate table .... drop index..... insert data ..... create index ... analyze table table_name compute statistics;
重新生成統(tǒng)計(jì)數(shù)據(jù)
調(diào)整后，整個(gè)操作耗時(shí)非常少。
以上的相關(guān)內(nèi)容就是對(duì)Oracle SQL執(zhí)行緩慢的分析的介紹，望你能有所收獲。