Re: [DB ] InnoDB一問
※ 引述《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
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 6 之 7 篇)：