作者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