※ 引述《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)