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