作者alpe (薛丁格的猫)
看板PHP
标题Re: [请益] 资料库规划问题 (MySQL)
时间Wed Mar 14 23:19:09 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给出来
: → characterlu:我有请人帮我做作业吗?我只是说就算是作业就不能讨论? 03/14 16:02
你的问法也很差... 後来的态度很差... 被电只是刚好.
: → characterlu:莫名其妙有建设性的回答看不到半个,只看到某酸民一副 03/14 16:05
你有先想过你的问题吗?
: → characterlu:回应,不要回那种自私自利的话,没人要你帮忙 03/14 16:06
: → characterlu:如果你也不懂,那你讲那种话实在是伤你父母的心,没家教 03/14 16:07
乖... 你这样说人, 也想想自己...
: → characterlu:YANLI2对,理论上是,单纯想比较,多栏位到底要全塞在同 03/14 16:08
: → characterlu:资料表,还是要拆多资料表,比较笔数庞大时的处理效率 03/14 16:09
: 嘘 carlcarl:有求於人 态度还是好一点吧 03/14 16:11
: → chrisQQ:常搜寻/读取/修改 和很少修改的栏位分开 03/14 20:29
: → chrisQQ:建好 index，拉出来後丢 memcache 之类的 03/14 20:32
: → chrisQQ:discuz 之类的讨论区有按照尾数之类的分散在十个表 03/14 20:32
: → chrisQQ:但你搜寻就要搜10个表 03/14 20:33
这样要排序会很累... XD
Mysql 5 有 partation by xxx 可以帮忙作分散.
效能... 我没测过
: → characterlu:chrisQQ这方式很棒很聪明,不失为两全其美的好方法 03/14 20:33
: → characterlu:但是栏位分开会不会造成资料库管理的错乱? 03/14 20:34
: → chrisQQ:如果你喜欢捞出来的时候拼在一起，就 join 起来 03/14 20:35
: → chrisQQ:另外我刚刚测了一下，在 index 建好的情况下 03/14 20:36
: → chrisQQ:27,353,371 笔资料捞特定 sn 的时间 查询花费 0.0007 秒 03/14 20:36
: → chrisQQ: 特定一笔 sn 03/14 20:36
: → chrisQQ:不过通常 join 的速度不会比较快，这是在我们公司的case下 03/14 20:38
: → chrisQQ:测试的结果。当然没有完全正规化也是影响的因素。 03/14 20:38
--
Exactly. For that one fraction of a second, you were open to options
you had never considered. THAT is the exploration that awaits you:
not mapping stars and studying nebulae,but
charting the unknown possibilities of existence.
Star Trek S7E26 "All Good Thing"
--
※ 发信站: 批踢踢实业坊(ptt.cc)
◆ From: 61.31.105.62
1F：推 LaPass:推经验分享! 这书上学不到 03/14 23:55
2F：推 tkdmaf:问题！需求！答案。取决於学习的态度。我们不能要求别人。 03/15 00:30
3F：→ tkdmaf:但我们可以学习自律。错误并不可耻。可耻的是你不打算改正 03/15 00:30
4F：→ tkdmaf:很多时候，人家酸酸的回文不一定是为酸而酸。 03/15 00:31
5F：→ tkdmaf:或许大家只是想借用「酸」来剌激一下感觉。 03/15 00:32
6F：→ tkdmaf:希望这讨论的原发文者能够好好思考。 03/15 00:32
7F：→ tkdmaf:结论：有没有听过一句话？菜鸟就是活该被电。 03/15 00:33
应该说没动脑的菜鸟就是活该被电
8F：推 chrisQQ:其实我也很好奇 discuz 那个分 table 怎麽排序，没仔细看 03/15 14:06
9F：→ chrisQQ:但我觉得应该还是 index 在总表，内容分下去 content 之类 03/15 14:07
10F：→ chrisQQ:不然如原PO所说，select 和 order 都会想哭 XD 03/15 14:07
11F：→ alpe:temp table? 03/15 14:31
12F：→ chrisQQ:欸… 有可能，不过只是帮人家转论坛遇到的，没时间下去看 03/15 14:33
13F：→ chrisQQ:discuz 的 code :( 03/15 14:33
14F：推 characterlu:从效能解释的insert跟select很清楚,受教了 03/15 16:40
15F：→ characterlu:实在无解我一开始问问题那里有错?板上的人到底有没有 03/15 16:41
16F：→ characterlu:这麽讲究你问的问题是否为作业?後面态度口气我是不好 03/15 16:42
17F：→ characterlu:但不也是某人先回那种挑衅的文吗?现在大家一起讨论 03/15 16:43
18F：→ characterlu:问题,分享一些经验谈不是很好吗?相信这篇讨论文很多人 03/15 16:43
19F：→ characterlu:多少都有一起学习到东西,这也是讨论板存在的价值精神 03/15 16:43
如果新手问说:
1.如何看DB SQL效能...
我相信会很快有人回也没人会电你.
2.如果是问 A 的效能差, 但找资料快, 我想改成 B
应用上我该注意些什麽? 如何调校这种TABLE.
个人觉得我看到这种问题我会比较想回.
另外就用你的问法来造句 :
请帮忙比较 node.js 跟 php 的
电脑负载及执行速度?
会不会觉得没头没尾????? 另外这会也变成太发散的回答.
※ 编辑: alpe 来自: 61.31.105.62 (03/15 17:37)
20F：推 carlcarl:嗯嗯 非常同意alpe 03/15 17:44
21F：推 chrisQQ:同意上面的编辑，我觉得问问题技巧很重要， 03/15 17:46
22F：→ chrisQQ:主要是这种东西太实务，通常都是看实际状况调整， 03/15 17:46
23F：→ chrisQQ:人家的通用解在你的 case 上不一定是最好，没有前因後果 03/15 17:47
24F：→ chrisQQ:的丢出问题很像是大哉问的感觉… 有些实务经验的板友 03/15 17:48
25F：→ chrisQQ:可能就会觉得这问题不切实际，就… 很像作业的感觉。 03/15 17:49