※ 引述《jameswiki》之銘言： : ※ 引述《flakchen (flak)》之銘言： : : 沒錯，面對這麼大的資料量作垂直或水平分割（Partition）是基本手段 : : 也比較多，但這也使資料表規劃技巧更形重要 : flakchen大,Soga,了解了,所以像您這種資料庫,一個table上億筆, : 根本無法用left join, : 我想應是少數案例吧,如果是常態,每個人的DB table中都上億筆, 這種超大資料庫的設計在國外叫作VLDB（Very Large Database） 在國內感覺比較少人提，但國內客戶與程式開發人員也就因此都有刻板印象： 認為MS-SQL是沒辦法作超大資料庫的存放的 事實上，MS-SQL在效能的確與Oracle有一段落差，但在SQL2000以後其實是可以承受 VLDB的，但在設計跟程式設計上就會多出一些東西要注意 像這個網頁就在討論這個問題，不過他這裡的Tip太簡單了，比較有用的還是得到 SQL Magazine去找 http://www.sql-server-performance.com/tips/vldb_p1.aspx : 就請微軟癈了left join指令就好了! : (或說:資料庫的left join,full join根本不應存在,因為一用就影響效能甚距) 如果是少筆的資料表互相JOIN，當然LEFT跟FULL還是可以用的，這在算數運算上 可以簡化程式碼，不必因噎廢食 : ,作業用DB中有存放過去6個月-1年的資料,所以也不用常跨DB查詢 : 平日一個now_db就是有今日起到去年今日的資料,可供作業使用, : 臨時一個跨過去年今日的跨年度的查詢需求, : 也只是跑一個union來處理就OK 這種在SQL 2005上就是用Partition Table來處理，很好用，但比較複雜 不過發生的機率不大，或是查詢容忍時間比較長就算了，因為這要Ent.版才有 : 感覺您的資料,有可能比較像銀行ATM存提款的交易記錄之類的, : 才有可能破億吧? 沒錯，的確是機器產生的記錄類資料，人工輸入的資料都是小Case，很少能累積這麼多 只是要說明，前面之所以有人會提到用Idenrity欄位作Clustered Index/PK 的原因是效能上的關係，當然這問題不是每個Case就會遇到，不過這種「老生常談」 的經驗法則通常都是因應最惡劣的情況所產生的 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 203.70.51.189