※ 引述《alpe (薛丁格的猫)》之铭言： : ※ 引述《characterlu (MineMine)》之铭言： : : 标题: [请益] 资料库规划问题 (MySQL) : : 时间: Tue Mar 13 23:48:04 2012 : : 资料库有两种规划方式 : : A: 有100个栏位 但资料有10万笔 : : B: 20个资料表，每个资料表5个栏位 资料有200万笔 : : 这两种方式，读取、写入、搜寻 : : 请帮忙比较这二种规划方式 : : 电脑负载及执行速度 : : 本身是新手，如果有问错的地方请多多包含 : : → eugene2528:这确实像课本问题 03/14 12:31 : 早上看到的时候也真的觉得好作业的问题 我也以为是作业文， 为什麽？怎麽看都是「未经思考」就丢出来的问题… : : → characterlu:先声明这并不是课本问题,是我实务上遇到的 03/14 13:07 : 在现在公司我目前经手的网站会员大概 7M+, 一个会员的资料过百个cols. : 1. 简单问一句, 你会很常一次就抓出 70 cols 吗? : 我猜不会... table 100 cols 光 programmer要看col就累了 : 2. 你会让 user 一次写 50 个栏位吗? : 我猜还是不会... 如果会... UI设计的人抓出去毙了 : 1 + 2 一般就可以让你打消 A 方案了. : 但... A会不会存在?? : 我可以肯定的回答 Yes, it's exist! 但通常用在统计 or 汇整. : 从效能看 : SELECT : 看你的怎样用. Index 建法 一般是 a >= b : 如果where条件都在一个table, : 其他table都是 join 资料, 那不会慢太多 : 你可以用 EXPLAIN 看看 SQL, 现在最佳化做的都不错. : INSERT : 1个 insert 的话 A >> B , 但 : 100 cols 1次 insert?? 这不常发生啊. : 多个 insert 下... B 可能会比较好, 看index 设计. : 负载,多叫几台机器来档. : 到一定的量之後, 都要用空间换取时间. 预先做好类似的table. : 这样才会快 : 我这边同个event的table可能有100个. 会员资料表也有近百个 : 有7个以上的会员搜寻用的table. : 在7M+ where10个条件下 order 3个col 页面还是可以2sec给出来 基本上你的问题简直是有描述跟没描述一样… 资料库实做是非常非常依需求判定的东西，并不是靠正规/反正规就可以解出来， 你至少要描述（厘清）自己的需求，旁人才有办法帮你想， 而且我觉得你的说明有问题… A: 有100个栏位 但资料有10万笔 B: 20个资料表，每个资料表5个栏位 资料有200万笔 ^^^ 这边应该是 20 个表加起来总和是 200 万吧？ -_- 资料表设计，栏位的数量绝对不是唯一考量， 还包括存取频率、存取方式（指 SQL）、栏位性质…等等， 这样说好了，在你的二分题目里，如果 1. 你的 100 栏位的资料表是因为这些资料真的都是榜在一起的， 每次都会需要一起存取，那你应该考虑的是当表养大之後要怎麽处理， 是真的有必要切栏位（增加 SQL 数），或着是切资料（手动转索引）也可以？ 2. 如果你的 100 栏位其实存取率高的只有那 40 个， 其余都是在某个特定情况才会用到，那这样榜在一起就显然不合理了， 简单来说，当你切割栏位只会在特定情况增加 SQL 存取数，那就有切割的价值， 不过除非你资料表的量大到百万外加高吞吐，100 栏位其实也还好。 一个重要的资料表的设计绝对有很多要考量的因素在里面，栏位不是唯一， 我前公司 50万+ 会员，资料表数 150+，其中有个站内讯息的表资料量破亿， 这个表栏位数不到 10 栏，但只要几个人同时各删 10 笔资料， 伺服器大概就要花上一两分钟来解，很恐怖吧？ 原本的设计者一开始也没想过资料会变这麽大，所以整个就是天然呆的设计… 提供几个资料库设计的小细节（在 MySQL 下）， ※ 栏位有分为固定长度和变动长度，两种栏位分开放是有某些好处， 因为变动长度的栏位资料在不断新增过程中是碎裂的， 所以会常需要跑最佳化来维持读取上的效能 ※ 延续上一点，虽然 char 是固定长度格式， 但只要你塞 text 之类的变动长度栏位，char 会自动转为 varchar ※ 如果你弄了很多栏位来放 flag / 只有 Yes,No 的 enum / 只有 0,1 的 char … 建议把相关的「设定栏位」合起来变 bit 运算，PHP 里宣告常数去判定， 相信我，你会习惯的 ※ 新增资料并不会磨损资料表的最佳化（大部分来说），删除和更新才会 ※ 索引只下必要的就好，大量无谓的索引只会令资料在异动时异常辛苦 ※ … 一下想不出来还有什麽了（搔头） --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.219.113.121 ※ 编辑: gpmm 来自: 61.219.113.121 (03/15 02:20)