※ 引述《grassboy2 (活力花俏草儿Grassboy大렩》之铭言： : 嗯嗯…下面的动作哪个比较伤主机资源啊？ : 状况A : PHP在连进资料库(资料库里面只有3份资料表)後… : 执行select指令 : 从其中一个资料表里面的 : 100000多笔资料挑一笔资料出来的时间 可以用 explain 了解资料库是如何执行 query 的。 (至少 mysql 可以 XD) 前面也有版友说了，适当的设定 Primary, Index 等 key 将有益於搜寻速度。 : 状况B : PHP连进资料库後(资料库里面有10000份资料表)… : 执行select指令 : 从其中一个资料表里面的 : 100笔资料挑一笔资料出来的时间… 以 MySQL 来说，每个 table 是存於独立的档案之中， 因此资料表的个数，对搜寻速度不会有太大影响。 然而一个 table 在 MySQL 里, 以 MyISAM 会占用三个档案 (*.MYD, *.MYI, *.frm) 所以... 可能会因为档案数变多，而造成新的问题。 : 又…瞬间负担和长时间负担有差别吗？ : 话说小弟目前有个资料库就是状况A的状况… : 想说趁寒假改写整个资料库^^~但又担心作白工^^" 我个人建议将资料分开储存，使得单一 table 内的资料笔数， 能够在可预见的未来内，维持一合理且容易操作维护的大小。 资料库的正规化是种在设计时就应考量的作法， 将高存取率的资料抽离，存在单一 table 中，也许能使你从某些快取因素获利。 回到如何分割资料的情况来看，若是在你最常 select 的 table 中 (最常见应该是使用者的帐号密码对照表) 有一种足够混乱，但又够稳定的资料 那麽透过 hash function 产生 key, 再将资料分配至适当的 table 之中即可。 以一堆使用者来说，出生月份或身份证字号的某几位数 (前两位以外) 对文章来说，发表时间 timestamp 的末几位数，都是很好的方向。 至於应分配到多少 bucket 当中，则视需要 (资料成长，以及大小) 而定。 (然而像你状况 B 的 10k buckets, 似乎也太多罗) 如果你的资料库建立得 "相当有水准" 使用者在登入时，只会被检查 "ID / Password" 的这个表格 (而我们都知道, ID / Password 都不是很乱的资料) 那麽加上第三栏，指定其资料所在的表格名称，那也是种可行的方式。 我最近有点懒，没空去尝试这些不同方法在主机上实测的结果， 所以希望这些空谈能对你有所帮助了 ^^;; -- 鬼压床怎麽办 骑上去啊 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 140.112.217.134