不知道有沒有人遇過或想過這個問題 如果有一個線上交易系統，平均每天都會產生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)