不知道有沒有人遇過或想過這個問題
如果有一個線上交易系統，平均每天都會產生30多萬筆交易資料，暫定大約50MB好了
如果就這樣放任不管讓資料都放在同一張交易資料表的話，那麼這張表將會增長得很快
一個月就會有將近1000萬筆交易資料，佔去硬碟空間約1.5G
長此以往，有可能會超出DBMS或OS的檔案系統限制嗎? (順便問一下 MySQL 的限制是?)
而且可想而知，對這個資料表進行搜尋時將會越來越慢、
資料表的維護、建立索引等工作也將越來越困難
當發生這種情形，又不可以將以前的交易資料捨棄，在面對日益增多的交易資料時，
DBA應該要採取哪種措施，來讓使用者可以正常進行交易資料的查詢、每日新資料的進入，
並維持DB不至於崩潰呢?
1.將一定時間以前(如六個月前)的資料全部備份到另一台離線主機上。
(缺點，查詢時只能查到一部份資料，且備份主機依然會有上述的問題，
而使用者還是有需要查詢以前的交易資料)
2.將固定時間範圍內的資料(如半年)分散放到多台主機DB，順便分散loading(有錢的作法)
需要搜尋時就用程式去判斷需要的資料是什麼月份，再去那個主機DB尋找。
(不過要在查詢時將不同DB資料合在一起，我還沒學會怎麼純下SQL而不需程式流程
輔助...有人會嗎?)
3.一個月建立一張新的交易資料表在備份主機，且每日備份資料，
需要搜尋時就用程式去判斷需要的資料是什麼月份，再去那個資料表尋找。
(同一個資料庫下比較好下SQL)
4.禁止使用者存取一定時間以前的資料。(超爛的方法，會被打死吧 XD)
5.其他我還沒想到的方法。
請高手分享一下資料庫的管理心得....謝謝。
--
答答的馬蹄聲
我不是歸人，也不是過客，
我.........................................是馬......>"<
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 118.171.6.201
※ 編輯: asklove 來自: 118.171.6.201 (03/07 02:03)