Re: [請益] 資料庫規劃問題 (MySQL)
: 資料庫有兩種規劃方式
: 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
推
03/14 23:55, , 1F
03/14 23:55, 1F
推
03/15 00:30, , 2F
03/15 00:30, 2F
→
03/15 00:30, , 3F
03/15 00:30, 3F
→
03/15 00:31, , 4F
03/15 00:31, 4F
→
03/15 00:32, , 5F
03/15 00:32, 5F
→
03/15 00:32, , 6F
03/15 00:32, 6F
→
03/15 00:33, , 7F
03/15 00:33, 7F
應該說沒動腦的菜鳥就是活該被電
推
03/15 14:06, , 8F
03/15 14:06, 8F
→
03/15 14:07, , 9F
03/15 14:07, 9F
→
03/15 14:07, , 10F
03/15 14:07, 10F
→
03/15 14:31, , 11F
03/15 14:31, 11F
→
03/15 14:33, , 12F
03/15 14:33, 12F
→
03/15 14:33, , 13F
03/15 14:33, 13F
推
03/15 16:40, , 14F
03/15 16:40, 14F
→
03/15 16:41, , 15F
03/15 16:41, 15F
→
03/15 16:42, , 16F
03/15 16:42, 16F
→
03/15 16:43, , 17F
03/15 16:43, 17F
→
03/15 16:43, , 18F
03/15 16:43, 18F
→
03/15 16:43, , 19F
03/15 16:43, 19F
如果新手問說:
1.如何看DB SQL效能...
我相信會很快有人回也沒人會電你.
2.如果是問 A 的效能差, 但找資料快, 我想改成 B
應用上我該注意些什麼? 如何調校這種TABLE.
個人覺得我看到這種問題我會比較想回.
另外就用你的問法來造句 :
請幫忙比較 node.js 跟 php 的
電腦負載及執行速度?
會不會覺得沒頭沒尾????? 另外這會也變成太發散的回答.
※ 編輯: alpe 來自: 61.31.105.62 (03/15 17:37)
推
03/15 17:44, , 20F
03/15 17:44, 20F
推
03/15 17:46, , 21F
03/15 17:46, 21F
→
03/15 17:46, , 22F
03/15 17:46, 22F
→
03/15 17:47, , 23F
03/15 17:47, 23F
→
03/15 17:48, , 24F
03/15 17:48, 24F
→
03/15 17:49, , 25F
03/15 17:49, 25F
討論串 (同標題文章)
完整討論串 (本文為第 2 之 5 篇)：
4
57
PHP 近期熱門文章
PTT數位生活區 即時熱門文章
