所以我对调整 InnoDB 还很陌生。我正在慢慢地将表（在必要时）从 MyIsam 更改为 InnoDB。我在 innodb 中有大约 100MB，所以我将innodb_buffer_pool_size变量增加到 128MB：
mysql> show variables like 'innodb_buffer%';
+-------------------------+-----------+
| Variable_name | Value |
+-------------------------+-----------+
| innodb_buffer_pool_size | 134217728 |
+-------------------------+-----------+
1 row in set (0.00 sec)
当我去更改innodb_log_file_size值时（例如mysql 的 innodb 配置页面上的my.cnf注释将日志文件大小更改为缓冲区大小的 25%。所以现在我的 my.cnf 看起来像这样：
# innodb
innodb_buffer_pool_size = 128M
innodb_log_file_size = 32M
当我重新启动服务器时，出现此错误：
110216 9:48:41 InnoDB：初始化缓冲池，大小 = 128.0M
110216 9:48:41 InnoDB：缓冲池初始化完成
InnoDB：错误：日志文件 ./ib_logfile0 的大小不同 0 5242880 字节
InnoDB：比指定的.cnf 文件 0 33554432 字节！
110216 9:48:41 [错误] …
昨天我遇到了一个新问题，我的一个 MySQL 5.5 从数据库在 AWS 的 EC2 上运行。数据库是从另一个从站的快照创建的。数据是正确的，但至少对于一个表，二级索引返回的结果不完整。通过父 id 查询子表返回 498 行，而它应该返回 504。通过主键查询丢失的 6 行工作，并且返回了正确的父 id，所以问题出在二级索引上。
这个问题对我来说非常重要，因为据推测，即使从站上的所有数据都与主站匹配，我仍然会从在从站上运行的某些查询中得到不正确的结果。
我的蛮力解决方案是像这样重建整个表：
alter table my_table engine = innodb;
这解决了这个特定表的问题，但我还有以下问题：
1) How can I determine if other tables have similar index corruption?
2) What's the most efficient way to fix the corrupt indexes?
我在网上找到了一些很好的资源来查找和修复 InnoDB 数据损坏，但没有找到任何与 InnoDB 索引损坏相关的资源。
我查看了 MySQL 错误日志并没有找到确凿的证据。我确实发现了一些令人不安的 InnoDB 错误。我假设这是一个单独的问题，但它可能是相关的：
130109 9:46:41 InnoDB: unable to find a record to delete-mark
InnoDB: tuple DATA TUPLE: 2 fields;
0: len 4; hex 04af1f21; asc …我想增加innodb_log_file_size性能以获得更好的性能。我将它从默认值增加到 256 MB。像往常一样，我收到错误消息InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes。所以我将这些文件移动到不同的位置并重新启动了 MySQL 服务器。有效。在关闭 MySQL 之前，我还制作了服务器innodb_fast_shutdown = 0。
但是我有一个疑问，在 MySQL 关闭后，我们是否可以期望 mysql 处于一致状态，并且其中的所有数据ib_logfile0 and ib_logfile1都已写入数据文件。这样我就可以删除这些文件，或者我也应该做其他事情。
如果答案是 MySQL 将处于一致状态，那么为什么这些文件即使在正常关闭并以innodb_fast_shutdown = 0.
我遵循的步骤：
- 设置全局 innodb_fast_shutdown = 0
- /etc/init.d/mysqld 停止
- rm -f /var/lib/mysql/ib_logfile0
- rm -f /var/lib/mysql/ib_logfile1
- /etc/init.d/mysqld 启动
上面的步骤可以吗？如果是，那么干净关闭并启动后如何来日志文件包含一些数据。理想情况下它应该是空的。