※ 引述《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