作者：老王

升级法则第一条：最好不要升级。除非必要，否则任何改变现状的升级操作都有可能给你带来不必要的烦恼。

MySQL4升级到5，本来打算直接使用mysql_upgrade之类的工具升级数据文件，不过考虑从4到5变化太大，便决定使用mysqldump导出数据文件：

先在旧的MySQL4上导出数据：

/path/to/mysql4/bin/mysqldump --all-databases > backup.sql

再在新的MySQL5上导入数据：

/path/to/mysql5/bin/mysql < backup.sql

在导入SQL文件的时候遇到了Unknown command错误，网上查询，发现这个问题可能是由下列原因引起：

第一：可能是default-character-set设置错误。
第二：可能是max_allowed_packet设置过小。

不过这些配置我都已经在客户端配置文件$HOME/.my.cnf里设置过了，所以不可能是这些问题，最后发现竟然是因为在导入导出数据时使用了不同版本的工具所致，换成/path/to/mysql4/bin/mysq导入，不再出现Unknown command错误，兼容性做得不好啊，以后遇到类似问题要注意了。

第三：可能是因为导入导出数据时使用的工具版本不一致所致。

所有的原因中，第三点尤其容易被忽视，如果你遇到了类似的问题，不妨对照这三点一一排查。

=============================

记录几个不相干的MySQL知识点：

MyISAM表激活DELAY_KEY_WRITE后，不会将索引的改变数据立刻写入磁盘，而是放到内存的键缓冲区，只会在清理缓冲区或者关闭表时，才会 将索引块转存到磁盘上，对于数据经常改变，使用频繁的表，这样的方式提高了性能，但是如果系统崩溃，索引损坏概率极大，必须要修复，可以使用 myisamchk手动修复或自动修复（myisam_recover_options），修复选项最好兼顾安全和速度，如：BACKUP, FORCE。

MyISAM可以创建多个命名的key_buffer_size，如：key_buffer_foo.key_buffer_size = 1G
可以把表table_bar的索引保存到key_buffer_foo中：mysql> CACHE INDEX table_bar IN key_buffer_foo;
还可以预加载：mysql> LOAD INDEX INTO CACHE table_bar;

BLOG、TEXT字段排序方式和其他类型不同，会回按照字符串的完整长度排序，而只是按照max_sort_length规定的前几个字节排序，另外这 样的方式必然会产生临时表，而且由于涉及BLOB，TEXT类型，还会是MyISAM类型的临时表，这是应该使用ORDER BY SUBSTRING(column, length)，这样就会使用Memory类型的临时表，同时注意max_heap_size或者tmp_table_size，否则还是MyISAM类 型的临时表。

Memory不支持TEXT或者BLOB字段类型，只支持固定大小的行，会自动把VARCHAR类型当做CHAR类型来处理。Memory引擎缺省是 Hash索引，所以如果在Memory缺省设置下想执行ORDER BY之类的查询，基本属于自讨苦吃，如果一定要这样，记得修改索引类型为B-Tree。

MySQL在处理保存中间数据的临时表时，会在内部使用Memory引擎，但如果数据量非常大 （max_heap_size，tmp_table_size）或者含有TEXT或BLOB字段类型，MySQL会将其转换成MyISAM表，存储在磁盘 上，此时可以考虑把临时表放到基于内存的文件系统中（比如tmpfs）。

VARCHAR(5)和VARCHAR(200)保存“hello”占用的磁盘空间其实是一样的，但是较大的列会占用更多的内存，因为MySQL通常会分 配固定大小的内存块来保存值。这对排序或使用基于内存的临时表尤其不好。