※ 引述《Lucemia (生の直感、死の予感)》之銘言： : ※ 引述《yachine (無聊的男人)》之銘言： : : 文件看起來是這樣 但是個人實際上使用似乎不然 : : 且感覺不大穩定 : 目前已經碰到很多奇形怪狀的問題.. : : 您的DB是建構在Widnows平台上嗎?因為您提到2GB的限制 : : 建議您改用Unix like 平台 : : Windows上面跑了太多沒有辦法控制的程式 : : 在大型資料庫的架構來說 不是很合適的 : 測試是在window下面測、主機是debain的系統。 : linux like的系統沒有檔案大小限制嗎? 都有大小的限制 我剛剛特地去爬了一下文 http://dev.mysql.com/doc/refman/5.0/en/full-table.html 可是這結果有點讓我意外 之前我在NTFS上面測試 極限的確被鎖在2GB 是版本的問題嗎? 因為我之前是用4.x板的 轉到Linux上就沒有觸到容量極限的問題 : : 這一點看不大懂 你要是沒有先建立好Table file怎麼進行操作呢? : : 基本上若您評估的結果需要用多個資料庫來儲存 就要先開好 : myisam 會自己開好table file .. 這點有點誤解了~我是指要先做Create database跟Create Table的動作 不是指實體檔案 因為原文你提到是否要先建立檔案 所以我才會這樣回答 : innodb的話是全部要自己設定嗎? 他好像也沒有按照table 來區分檔案 Innodb的檔案結構 的確是和Myisam不一樣 InnoDB是把所有東西都塞到一個檔如Table,index等 但Myisam則是獨立的檔案 不用自己開檔 這跟前面說的一樣誤解了 我是指資料庫的指令操作步驟 : : 我想你Update會慢的原因可能你的Index太多或太複雜 : : 在資料量大的環境中 建立良好的索引可以加速查詢 : : 但是卻會拖慢更新效能 : 目前有的table 大至上是兩種 : 資料: : id, dataname, datafield1,2,3,4,5 ... ,build_time : 其中id設primary, dataname 設unique, build_time 設index : (不確定需要進行order by的欄位是否應要設成index) : weighted mxm關係: : id, A_id, B_id, weight1,weight2 : id 設primary : (A_id, B_id) Unique : A_id index , B_id, index : weight1,2,3, 設index ... : 像這樣子的設定OK嗎? Index欄位設法依狀況而定 基本上就是妳常用的查詢條件來當Index 套一句現在流行的話 好的Index帶你上天堂 不好的Index讓妳住套房 我不了解你的資料結構和裡面裝載的資料還有你的運用 所以我不能評斷好不好 但還是那個原則 越多的Index查詢會更快(前提是要正確的設定Index) 但是會拖慢Update的效能 因為妳每Update一筆他就要更新Index一次 等於要寫很多個地方(看異動欄位而定) 若是你的資料不是及時查詢的 比方說 你今天輸入的資料明天以後才會進行查詢 你可以先不要上Index描述 等今天的資料都輸入完畢 再進行Create index工作 這樣可以減少重建索引的時間 但是就是注意我剛剛講的前提 1.資料不用馬上查詢 2.有大量的異動資料(Update,insert,delete) : 另外一個問題是 table的大小是否會影響效能， 檔案大小絕對會影響查詢效能 因為MySQL吃FileSystem吃很重 他的Cache hit率比起其他系統感覺都來得低 你可以用些查詢系統效能的工具 可以發現他在查詢大型檔案時 嚴重點可以把Filesystem拖到當掉(這點要看機器啦) 之前有提到我以前做的每天20G的做法 是每個小時就切一個Table出來 查單一Table還可以 要是比方我要查早上五點到晚上午五點的資料 那就很頭大了 目前我用預先查詢的方法 將使用者的習慣都做Batch在系統閒置的時候跑報表 使用者還是可以接受的 : 應該要致力於將每個欄位都設定到最小所需嗎? 當然若你的資料量那麼大 要把所有欄位都定到最嚴謹 能用Char就不要用VarChar 能用TinyInt就不要用INT 不要因為系統資源多 就任意定義欄位 每一筆紀錄少一個byte 在大型資料庫是很嚇人的 總有一天資源會被耗光 : 感謝您無私的經驗分享 m(_ _)m U r Welcome~ --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 59.115.155.126