前两天生产库上出现了一个不大不小的故障，关于MySQL的存储引擎问题。这个故障所涉及到的是MySQL4.1.20的版本MyISAM存储引擎，一张1千多万的表。故障现象：在做
前两天生产库上出现了一个不大不小的故障，关于mysql 的存储引擎问题。
这个故障所涉及到的是MySQL 4.1.20的版本MyISAM存储引擎，一张1千多万的表。
故障现象：
在做简单的SELECT查询的时候没有问题，但是做连接查询或者其他复杂查询的时候就报错了:具体的错误代码由于时间的问题被遗忘了。在系统日志中记录的错误如下图：
从错误信息中可以猜到了大概：存储引擎出了问题。
进到相应的数据库目录下，服务器空间，香港服务器，查看一下数据文件大小，有4G大小，这就不奇怪了.
MySQL 4版本的数据库创建的表默认最大文件大小就是4G 也就是说那个表满了，无法在插入数据了。其实版本4是支持超过4G数据文件大小的，需要在创建表的时候加上这么一句话： MAX_ROWS=1000000000 AVG_ROW_LENGTH=15000 。
执行myisamchk -dvv 表名字显示属性信息：
然后更改表的最大文件大小
alter table table_name MAX_ROWS=1000000000 AVG_ROW_LENGTH=15000;
图改改
在线修改图片文字
455 查看详情
执行这个修改时间比较长，大约在几个小时。
检查修改结果：
其中：Datafile length 4095052564 =4G
Max datafile length 281474976710654 就远远超过G这个单位了。
MySQL 版本5默认已经支持 Max datafile length 281474976710654 就不用在创建表的时候添加MAX_ROWS=1000000000 AVG_ROW_LENGTH=15000 参数了。
本文出自 “影子骑士” 博客，服务器空间，请务必保留此出处
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/528831.html
微信扫一扫 
支付宝扫一扫 
