※ 引述《flakchen (flak)》之銘言： : ※ 引述《jameswiki》之銘言： : : <前面吃光光了..太長了XD> : : (不要跟我說所有欄位都在同一table,你從來不用left join,那又要討論資料庫規劃 : : -->離題了XD) : 沒錯，面對這麼大的資料量作垂直或水平分割（Partition）是基本手段 : 也比較多，但這也使資料表規劃技巧更形重要 : : 我引述下面網址的文章 : : http://blog.miniasp.com/post/2008/01/08/The-Gospel-of-the-GUID.aspx flakchen大,Soga,了解了,所以像您這種資料庫,一個table上億筆, 根本無法用left join, 我想應是少數案例吧,如果是常態,每個人的DB table中都上億筆, 就請微軟癈了left join指令就好了! (或說:資料庫的left join,full join根本不應存在,因為一用就影響效能甚距) 因此,您資料庫的狀況,的確是PK鍵值愈小愈好,別用太長位元~, 話說回來,PK鍵到底要用guid型態還是int型態,最終還是取決於資料庫的規模, 若像您這種上億筆, 必需要斤斤計較一點點小效能,東省西省 以提升系統效能來說,的確不合用guid型態,不然鐵定掛了 mobile SQL行動裝置受限於資源,應也不適合用Guid..XD 但一般開發DB,用guid型態來做.一個table資料量不到百萬筆, 只是拿掉一點點效能的影響,使用Guid還是有點好處的:P 看來是各有好壞了..就看資料庫規模來決定適不適合, 小弟在規劃一年有超過百萬筆可能的Table時,就會先割了, 類似這種狀況,由程式以每年的啟始,自動去產生新的Table, 以年份分開來儲存,EX: 96_db ->96年, 97_db ->97年(這些都是history Db) 作業用DB則叫 now_db (舉例..),now_db上保留前6個月-1年的資料 超過時間的..就搬到96_DB,97_Db的歷史table中 但是小弟所遇到這類型的table,大都是放歷史資料, 只是存檔,很少會有跨年度查詢的需求,所以分開放是OK的 ,作業用DB中有存放過去6個月-1年的資料,所以也不用常跨DB查詢 平日一個now_db就是有今日起到去年今日的資料,可供作業使用, 臨時一個跨過去年今日的跨年度的查詢需求, 也只是跑一個union來處理就OK 有人DB用了10年,單一TABLE資料量也不會超過500萬筆, 搞不好用了不到10年,又要升級新版的DB系統了.. 屆時又有更好的硬體,更好的軟體支援.. 但像您這種case,一個table就上億筆,最多只能做inner join, 軟硬體再進步個5年,對您的效能加分還有限, 也就只能放棄Guid當PK鍵了! 希望F大您的table不是放BOM表資料,不然展料時, 1億筆資料真會讓人哭出來的...:P 感覺您的資料,有可能比較像銀行ATM存提款的交易記錄之類的, 才有可能破億吧? ※ 編輯: jameswiki 來自: 220.142.205.153 (03/19 12:17)