我們有一個完全用C編寫的應用程序。對於代碼中的表訪問，如從表中獲取一些值，我們使用Pro * C。爲了提高應用程序的性能，我們還預取了一些表來獲取數據。我們採用一些輸入字段，並從表中獲取輸出字段。表訪問的性能
我們通常在表中有大約30000個條目，最多可以達到10萬次。
但是，如果表項增加至約10萬個條目，我覺得它危險地影響應用程序的性能。
我錯了地方？如果它真的影響性能，有沒有辦法保持應用程序的性能穩定？
是什麼，如果行的表增加到10萬個考慮應用程序處理表的方式，可能的解決方法？
如果不排序，你會得到的搜索時間成比例增加......如果你沒有任何代碼錯誤，在你的榜樣（30K VS 1M）表，你會得到更大的33X搜索時間。我假設你正在逐漸迭代（i ++樣式）表。
但是，如果某種程度上可以對錶格進行排序，那麼您可以大大縮短搜索時間。這是可能的，因爲搜索排序信息的索引器算法不會解析每個元素，直到它到達所尋找的元素：它使用輔助表（樹，散列等），通常搜索速度更快，然後它指出正確的搜索元素，或者至少對主表中的位置進行更仔細的估計。
當然，這會在有排序表的費用，或者當您插入或刪除元素，或當你執行搜索。
完全如果所有1000萬條目將被預加載到memory.it將來載入7GB的數據進入內存，我不認爲它的工作 – Vijay 2009-12-08 04:28:42
所以這是兩個不同的問題：內存和搜索時間。如果這是磁盤上的巨大數據（通過這種方式進行接縫，但糾正了我），那麼通過將其加載到內存（它將由操作系統獲取頁面歸檔），您無法獲得任何內容。也許你需要建立一個適合更快搜索的哈希表（取決於你的標準），並指向磁盤上的數據？ – jpinto3912 2009-12-08 15:59:05
也許你可以去'谷歌散列'，看看他們的實施？雖然它在C++
這可能是你有太多的高速緩存未命中，一旦你增加超過1MB或任何你的緩存大小爲。
如果您多次迭代表格或隨機訪問元素，您也可以擊中大量緩存未命中。
嗯，這真的取決於你與數據做什麼。如果你不得不把整個kit-and-kabootle加載到內存中，那麼合理的做法是使用大的批量大小，這樣需要發生的oracle往返次數很少。
如果你真的沒有內存資源，讓整個結果集被加載到內存中，然後大批量規模將仍然與Oracle的開銷幫助。將合理大小的記錄塊存入內存，處理它們，然後獲取下一個塊。
沒有關於您的實際運行時環境和業務目標的更多信息，這與任何人都可以獲得的具體信息有關。
你能告訴我們更多關於這個問題嗎？
什麼是實際問題？你的問題真的很難理解。否則，你的問題的答案是「無法辨別，除非你使用探查器」。 – Sebastian 2009-12-07 09:30:33
「十萬」爲100。000 in Indian English – MSalters 2009-12-07 10:09:29
您正在從數據庫複製1000萬行到應用程序內存？假設你需要單行查詢的數據，你確定你的代碼比Oracle的代碼快嗎？只是總是使用SQL語句。哦......性能至關重要？如果您的程序使用您的代碼需要0.03毫秒，使用Oracle代碼的人需要注意3毫秒（100倍以上）？ – pmg 2009-12-07 10:29:32