Re: [請益] 資料庫規劃問題 (MySQL)

[alpe (薛丁格的貓)]

: 資料庫有兩種規劃方式
: 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
推 LaPass:推經驗分享! 這書上學不到
推 tkdmaf:問題！需求！答案。取決於學習的態度。我們不能要求別人。
→ tkdmaf:但我們可以學習自律。錯誤並不可恥。可恥的是你不打算改正
→ tkdmaf:很多時候，人家酸酸的回文不一定是為酸而酸。
→ tkdmaf:或許大家只是想借用「酸」來剌激一下感覺。
→ tkdmaf:希望這討論的原發文者能夠好好思考。
→ tkdmaf:結論：有沒有聽過一句話？菜鳥就是活該被電。
應該說沒動腦的菜鳥就是活該被電

推 chrisQQ:其實我也很好奇 discuz 那個分 table 怎麼排序，沒仔細看
→ chrisQQ:但我覺得應該還是 index 在總表，內容分下去 content 之類
→ chrisQQ:不然如原PO所說，select 和 order 都會想哭 XD
→ alpe:temp table?
→ chrisQQ:欸… 有可能，不過只是幫人家轉論壇遇到的，沒時間下去看
→ chrisQQ:discuz 的 code :(
推 characterlu:從效能解釋的insert跟select很清楚,受教了
→ characterlu:實在無解我一開始問問題那裡有錯?板上的人到底有沒有
→ characterlu:這麼講究你問的問題是否為作業?後面態度口氣我是不好
→ characterlu:但不也是某人先回那種挑釁的文嗎?現在大家一起討論
→ characterlu:問題,分享一些經驗談不是很好嗎?相信這篇討論文很多人
→ characterlu:多少都有一起學習到東西,這也是討論板存在的價值精神
如果新手問說:

1.如何看DB SQL效能...
        我相信會很快有人回也沒人會電你.


2.如果是問 A 的效能差, 但找資料快, 我想改成 B
應用上我該注意些什麼?  如何調校這種TABLE.
        個人覺得我看到這種問題我會比較想回.



另外就用你的問法來造句 :

請幫忙比較 node.js 跟 php 的
電腦負載及執行速度?

會不會覺得沒頭沒尾????? 另外這會也變成太發散的回答.
※ 編輯: alpe            來自: 61.31.105.62         (03/15 17:37)
推 carlcarl:嗯嗯 非常同意alpe
推 chrisQQ:同意上面的編輯，我覺得問問題技巧很重要，
→ chrisQQ:主要是這種東西太實務，通常都是看實際狀況調整，
→ chrisQQ:人家的通用解在你的 case 上不一定是最好，沒有前因後果
→ chrisQQ:的丟出問題很像是大哉問的感覺… 有些實務經驗的板友
→ chrisQQ:可能就會覺得這問題不切實際，就… 很像作業的感覺。