救命，SQL執行突然變慢了，請大家好

這個數量級的全面更新肯定會很慢。

第一。 其次，您的記錄不必位於同一分割槽中。 我不明白為什麼這麼多人建議你建立乙個索引，你建立的索引越多，你的更新就會越慢，因為你在更新索引的同時更新記錄。

第三。 要知道，更新慢的瓶頸是**。 不管是讀寫太多，還是記憶力不夠，還是速度不夠快，那就開對了藥。

以下是兩種簡單的方法來執行可能有效的操作：

首先，將 100w 行的表垂直拆分為兩行，並用外來鍵關係連線它們，乙個包含小且經常更改的資料，例如 id、外來鍵、狀態值、時間等，另乙個包含大量且不經常更改的資料，例如非常長的字串、xml、文字等。

這樣，這個小表在更新過程中的操作可以大大節省記憶體和 CPU 開銷，並減少磁碟操作。

缺點是查詢速度較慢。

第二：將100w行橫切成多個表，例如將每個月的記錄打包在乙個表中，這樣每個表中的記錄數可能只有幾萬條，查詢和更新會快很多。

缺點是查詢和更新不如原來容易編寫。

如果是 SQL Server，則有預讀等機制來提高 SQL Server 的查詢效率，這意味著在生成執行計畫時，物理表會同步讀入系統的快取中，這樣可以減少 IO。 但是，如果系統執行時間長，快取占用的量就越大，這也會影響系統的效能。 當然，這只是其中一種可能性，具體情況需要根據具體情況進行分析。

開啟資料連線也需要時間。

問題描述 oracle資料庫中某錶的資料已經超過1億，並且該錶建立了獨立的索引，由於業務需要，每天需要兩次向該表中插入10000條記錄，由於資料量大，每次插入需要乙個多小時， 這嚴重影響了效率，所以修改了系統的演算法，只儲存本表當天的新記錄，截斷該錶後，第二天對本表執行更新操作時，非常耗時，而且當表中的資料超過1億條時， 這個 SQL 語句在第二個表中需要時間 當資料有 10000 條時，這個 SQL 語句需要幾個小時，在諮詢 DBA 後得出結論，索引需要重新構建，這個操作秒級完成，但問題還是出現在第三天，DBA

對於這個問題，DBA沒有給出渣段理論的解釋，推測主要原因是Oracle的複雜查詢優化演算法。

最終備份 DBA 給出的解決方案。

truncate table

drop index

insert data

create index

yze table table_name pute statistics;重新模仿梁圖的新生成屬性。

lishixinzhi/article/program/oracle/201311/16938

這是個大問題，可以寫一本厚厚的書。 建議閱讀有關 DBA 和資料庫優化的書籍。

是因為內存在你使用過程中沒有及時釋放嗎？

那是因為資料太大，無法讀寫，而你的機器本身的效能不足，所以如有必要，優化資料庫，可以構建欄位和索引。

重新啟動機器是最好的解決方案。