現有問題：
1， 所有記錄在一張表上。沒有分類
2， 開發時，由于沒有考慮這么大量的數據。查詢語句放在程序中執行，造成速度過慢
3， 根據關系型數據庫的插入過程原理，每插入一次，建一次索引查詢，那么，將占用大量的內存與CPU資源，速度也將大大降低。在表中有100條記錄的情況下插入與在10000條記錄的情況下插入，速度與效率是完全不一樣的！
4， 插入與查詢是在同一張表里。并發處理數可能峰值有1000多。
5， 根據關系型數據庫的查詢原理，如果有人要查詢記錄表，將會是這樣的一個數學表達式

一條記錄 <=1K

總共100,000條記錄，每天2萬的增長速度

如果不知條件，任意查詢，那將會是這樣：
（1K * 100,000）/1024 = 10M

1個人是10M。如果是200個人同時查，那將會是這樣：
200*10M = 2000M （約2G）

這樣大的數據被數據庫中取出來。并下載到本機查看，本來就是很龐大的。
6， 各輸入網點的網速很多還是“貓”上網，速度肯定跟不上。
7，服務器中還存放著其它的數據等等。
7， 服務器帶寬只是專線8M，就算服務器的CPU能計算得過來，數據也送不出去，就被擠塞了！




由于上述問題，出現的情況如下：
1， 網站服務器硬盤物理燒毀一塊。
2， 網站帶寬被完全占用，基本難以訪問。
3， 網站頁面速度極其慢，數據傳輸效率低。
4， 有些個輸入單位由于網速無法響應他的操作，送出的數據包無法返回，已無法完成記錄輸入。



解決辦法（思路）:
1， 服務器更新。（硬件上）
2， 網絡帶寬增加。（硬件上）
3， 把查詢放在數據庫中進行，使用存儲過程，但在百兆網速下，存儲過程的應用基本與程序查詢沒什么明顯區別。（軟件上）。
4， 插入記錄時，使用緩沖表，每10分鐘，將緩沖表向主記錄表倒一次數據。這樣可以緩解主記錄表的壓力。讓主記錄表專門應對查詢動作（軟件上）
5， 查詢時，使用文本讀出記錄，因為基于系統底層的指計移動，查詢效率將會提高100倍。但是需要FileObjectSystem組件支持。安全性要考慮。（軟件上）




如果不采取措施，會引起的問題：

數據庫不堪重負，硬盤會再次燒毀。
服務器CPU一直處在100%滿負荷下運行。
程序系統完全崩潰。
數據無法即時插入，無法即時反應。
無法統計與追蹤。

各網站無法正常運行。