可能和InnoDB的性质有关。InnoDB是ACID的，这种ACID的数据库都对磁盘的IO性能要求很高，也要求更大的内存。很多数据库服务器往往都使用SCSI RAID，动辄4G、8G甚至16G内存——由于我对数据库的研究并不是很深，我隐约记得InnoDB有个会导致性能下降的双重写入问题，以及log的flush问题（向达人求证）。而公司租用的这台服务器，内存小，硬盘也只是SATA的，瓶颈是十分明显的。

当然，据很多测试表明，在高配的情况下，InnoDB有更大的优势——就好比谁会在这种机器上装Oracle呢？即使Oracle在这种机器上表现差，又有谁会质疑Oracle的强大呢？

所以我的结论是，如果数据库的硬件配置低，而应用又对事务等高级特性要求不是很高的话，可以依然采用MyISAM。

如果在Ruby中使用MySQL遇到

undefined method `each’ for #<mysql: >

考虑升级MySQL到最新版本
ruby的mysql-win 2.7.3似乎不能与mysql 5.0.24兼容（倒是可以和mysql5.0.20兼容）

这次有台Windows服务器拿到手中，需要装AMP，我一激进，装了Apache2.2.4 + Php5.2.1 + mysql-5.0.37。事后发现，网站程序用PHP4写的，和PHP5.2.1有点兼容性问题，于是乎换装PHP4，发现PHP4没有Apache2.2的模块，只好用CGI方式安装。接下来程序运行报错数据库无法连接，猜测是php4的mysql扩展不兼容mysql5。在网上找了半天，发现有老外自己编译了一个php4.4.6的补丁，下载覆盖了原来的dll文件，然后便成功了，特此备忘。

最近开发Python，数据库操作一直用的是SQLObject，但有个问题很让我头疼，就是MySQL的数据库的编码问题，主要是MySQL的。
起初我现在我在SQLite上测试开发，并没有出现问题。SQLObject的UnicodeCol工作很正常。而同时起初数据库中并没有任何非ASCII字符（也就是全英文），而后需求变化，增加了欧洲的一些内容，就涉及到latin1编码了，但奇怪的是，只要超出ascii范围（比如中文），即便通过Python将其转化为Unicode或者UTF-8编码的str（使用decode和encode方法），SQLObject在插入的时候就会出错。后来经过反复的检查，是MySQLdb的一个问题，SQLObject会通过获取数据库链接的character_set_name()，取得链接的字符集，然后对查询进行编码以符合这个字符集，但据调试，无论我用什么方法，比如链接的set_character_set()方法、执行“SET NAMES UTF8”这个语句，character_set_name()都总是返回“latin1”，这些可苦了我了，不知道这是不是算一个Bug。