感謝你不吝回答^^~ 話說我目前以不更改結構的方式維護我的資料庫… 因為發現加了幾個索引之後… 我的站速度真的有變比較快^^~ 但看到這篇文章…突然又想到… 其實好像也不用每一個id都建一個資料表^^~ 直接依某字母開頭的id分別放在二十六個資料表好像也可以^^~ 裡面的資料再記錄各個id就ok了 不過我和上一篇回覆的作者e大聊過 初步整理出： 建欄位索引…就相當於將對資料庫依欄位建資料夾分門別類 不會查詢到該欄位內容相差太多的資料錄 那麼有了建欄位索引這個方法… 還有必要使用「將資料分放在二十六個資料表」這個方法嗎？ 還是說當資料很多的時候… 索引的速度還是不夠快呢？ -- 哈~這是我最近在忙的網站：http://FriendTest.twbbs.org/?id=grassboy : 我個人建議將資料分開儲存，使得單一 table 內的資料筆數， : 能夠在可預見的未來內，維持一合理且容易操作維護的大小。 : 資料庫的正規化是種在設計時就應考量的作法， : 將高存取率的資料抽離，存在單一 table 中，也許能使你從某些快取因素獲利。 : 回到如何分割資料的情況來看，若是在你最常 select 的 table 中 : (最常見應該是使用者的帳號密碼對照表) 有一種足夠混亂，但又夠穩定的資料 : 那麼透過 hash function 產生 key, 再將資料分配至適當的 table 之中即可。 : 以一堆使用者來說，出生月份或身份證字號的某幾位數 (前兩位以外) : 對文章來說，發表時間 timestamp 的末幾位數，都是很好的方向。 : 至於應分配到多少 bucket 當中，則視需要 (資料成長，以及大小) 而定。 : (然而像你狀況 B 的 10k buckets, 似乎也太多囉) : 如果你的資料庫建立得 "相當有水準" : 使用者在登入時，只會被檢查 "ID / Password" 的這個表格 : (而我們都知道, ID / Password 都不是很亂的資料) : 那麼加上第三欄，指定其資料所在的表格名稱，那也是種可行的方式。 : 我最近有點懶，沒空去嘗試這些不同方法在主機上實測的結果， : 所以希望這些空談能對你有所幫助了 ^^;; --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.200.170 ※ 編輯: grassboy2 來自: 140.115.200.170 (02/09 05:54)