130711 23:03:40 InnoDB: Error: page 23 log sequence number 3336825872455
InnoDB: is in the future! Current system log sequence number 235089.
InnoDB: Your database may be corrupt or you may have copied the InnoDB
InnoDB: tablespace but not the InnoDB log files.
我以前从未见过或遇到过这个错误。客户端没有备份，因此他们需要完成恢复。
我以前做过 MySAIM 恢复，但从未做过 InnoDB。是否有任何关于如何正确执行此操作的提示？
从我读过的内容来看，我需要增加一个单独的计数器（“日志序列号”），该计数器存储在 ib_logfile0 和 ib_logfile1 的标题中的某处或类似的正确位置？
唯一正确的解决方案是重新安装并从备份恢复。你说你没有备份，但这里的重点是强制 InnoDB 恢复背后的想法是你可以让服务器足够稳定，以便你可以进行备份。然后用它来恢复全新的设置。
显然，在执行任何操作之前，请先复制所有文件。
除非有我没有收到的备忘录，否则你不想尝试增加日志序列号来安抚 InnoDB，因为即使你设法做到了，你仍然会得到一台在未知位置出现数据损坏的服务器——修复 LSN，您真正完成的就是让 InnoDB 不知道损坏。强制使用 LSN 几乎是一件傻事。
你有没有尝试过任何东西...
http://dev.mysql.com/doc/refman/5.0/en/forcing-innodb-recovery.html
不同的级别（1 到 6）会累积禁用 InnoDB 的部分功能，其想法是，如果禁用足够的功能，您可能能够成功mysqldump或至少SELECT ... INTO OUTFILE从表中获得成功。
我们的想法是使用允许您成功转储数据的最低数字，但如果像我认为的那样在启动时发生此错误，您可能只想继续并从 6 开始。如果服务器启动，然后尝试从表中进行选择。它可能会再次崩溃，如果确实如此，则暂时注销该表并移至下一个表。
一旦您从未损坏的表中检索到数据，您就可以返回到不起作用的表，并尝试使用SELECT ... LIMIT ... OFFSET.
看看我对这个类似问题的回答，了解一些额外的想法。
您可能还想将 Percona 的InnoDB 数据恢复工具视为潜在资源，尽管我（祈祷）从未遇到过没有备份或运行复制从属设备的情况，所以我从来不需要它。