謝謝您的建議與指教
歹勢我沒說清楚，我是要處理新聞文章，十年分的文件大概6G
其中兩年的文件轉換成資料庫後，資料筆數分別是八百萬和一千兩百萬筆

1.，文件檔大概有幾百個，每個都幾十MB~112MB，如果用程式讀取文字檔是沒問題的，一次讀一點就好
而我所謂的"開啟"是用筆記本，效率很差...後來發現用ultraedit開比較快
之所以要開啟文件檔，是因為要看文件格式長怎麼樣以便剖析，才知道怎麼寫轉換程式

2.3.4 這幾天會著手轉換資料庫工作

5.如我前面所說，環境的問題和我老闆個人的習慣問題，所以才會有這種弔詭的做法

至於index的問題
在做資料轉換時，就把某個文字出現在哪一年哪一篇文章的哪一句
所有出現過的資訊都記錄下來
然後另外開個資料庫存放index table
而比數只會增加不會減少，user只會改資料的屬性不會刪除

剛開始效果還不錯，但筆數大概超過600萬筆時就變慢了
只是因為之前沒經驗現在嚐到苦頭了
沒考慮之後有可能要把大量資料拆成多個資料庫...所以要再改 :laugh:

[1] 記事本的開啟方式是一次讀入，小檔尚可大檔肯定掛，加上其設計本來就沒針對大檔案讀取作特殊處理，所以久是正常的，更何況你的檔案大小甚至有超過100MB；UltraEdit則是只讀取片段，捲頁時再讀取，你所翻捲到的頁面，一定比較快。

有機會自己寫個小程式嗎？
每個檔案只擷取前面一小段，例如100MB取100KB，我想你的文字檔格式應該也是一段一段重複性，看前面一小部份，後面的格式也是相同的；如果我的假設成立，這樣做會不會讓你的分析工作快些？

[2] 我不知道你的資料經過整理後，是要以什麼方式呈現，查詢/歸納/整理方式為何？
從你的字裡行間似乎是做新聞檢索？類似Google打Keyword後，列出你所要的各條新聞（內容/時間/出處...）？

方法與習慣不好該改就是得改；筷子都不會拿了，怎麼夾豆腐？
如果我沒猜錯你的需求，就算轉成MSDE/MSSQL，
HDD I/O效能還是會拖效能，更何況你老闆是拿隨身碟去access。 :jolin: :jolin: :jolin: :jolin: :jolin:

[3] 請查詢 "Primary Key" 以及 "Indexes" ，這兩者加了之後，對 Insert/Update/Delete 沒有幫助，但對 Query 幫助非常大請適當加上（多或少都不好）。

只是恐怕你的資料量...MSSQL也撐不住... :laugh:

或許規劃DB+分散式的架構會比較適合你。

有沒有考慮把部分或全部資料+程式丟到RAMDISK去跑
之前也做過這種把TXT檔資料擷取進ACCESS的工作
總資料量只不過1-200MB卻也是很慢
但丟進RAMDISK再處理後
效率差非常多 快很多

"開啟50mb~112mb的文字檔，CPU使用率飆很高，檔案開很久才開得起來"

光這一項花費很幾分鐘是正常的...
cpu 夠快ram 夠快會快一點沒錯...你還需計算開啟的軟體ex:ultraedit也要內部處理計算的時間.


p.s.:另外:版主沒說明他資料的類型,大家要小心也許這是垃圾郵件的清單

後續有提到是新聞文章之類的內容。

如果你要開 大容量的純文字檔,可以試看看國產軟體

漢書

http://www.stone.com.tw/stone/download/download.jsp

數十 MB 應該不是問題

如果只是單純開啟文件觀看，並不做編輯、存檔工作，何不試試 Total Commander 的
Viewer (按 F3)，速度非常快，它不會一次讀入文件全部內容，PageUP、PageDown
按到哪讀到哪，還有支援 Unicode。

會要用到資料庫
除了資料量龐大之外
就是有運算比對排序分析的需求
不用再建議單純的text reader了