mysql 无法启动 启动服务报错

Question

mysql服务无法启动
.err文件里面描述为
081229  9:10:22  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
081229  9:10:22  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 499266729.
InnoDB: Doing recovery: scanned up to log sequence number 0 499266729
InnoDB: Error: trying to access page number 455552 in space 0,
InnoDB: space name .\ibdata1,
InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0, len 16384, i/o type 10
081229  9:10:22InnoDB: Assertion failure in thread 3032 in file .\fil\fil0fil.c line 3869
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
InnoDB: about forcing recovery.
081229  9:10:22 [ERROR] D:\MySQL\MySQL Server 5.0\bin\mysqld-nt: Got signal 11. Aborting!081229  9:10:22 [ERROR] Aborting081229  9:10:22 [Note] D:\MySQL\MySQL Server 5.0\bin\mysqld-nt: Shutdown complete
请帮忙分析下 谢谢

Answer 1

根据提示，似乎是没有正常退出MYSQL造成InnoDB引擎表损坏

Answer 2

带LOG运行没有，有无备份、MYSQL版本

Answer 3

ib_logfile0是不是所说的log文件？
备份只有表结构的备份  没有最新数据的备份
版本是mysql-5.0.18-win32

Answer 4

在MYSQL中加入 
[mysqld]
innodb_force_recovery = 4强制修复InnoDB 试试

Answer 5

如果数据不重要的话，重新安装吧，
重新安装所花的时间要比修复来的快很多。
我没有经历过InnoDB表损坏的情况，没有修复过，这点就不能给出什么意见了，见谅。

Answer 6

在my.ini加入
# Size of each log file in a log group. You should set the combined size
# of log files to about 25%-100% of your buffer pool size to avoid
# unneeded buffer pool flush activity on log file overwrite. However,
# note that a larger logfile size will increase the time needed for the
# recovery process.
innodb_log_file_size=10M# Number of threads allowed inside the InnoDB kernel. The optimal value
# depends highly on the application, hardware as well as the OS
# scheduler properties. A too high value may lead to thread thrashing.
innodb_thread_concurrency=8innodb_force_recovery = 4max_allowed_packet=16M
貌似不行啊081229 10:51:44  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
081229 10:51:44  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 499266729.
InnoDB: Doing recovery: scanned up to log sequence number 0 499266729
InnoDB: Error: trying to access page number 455552 in space 0,
InnoDB: space name .\ibdata1,
InnoDB: which is outside the tablespace bounds.
InnoDB: Byte offset 0, len 16384, i/o type 10
081229 10:51:45InnoDB: Assertion failure in thread 3400 in file .\fil\fil0fil.c line 3869
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html
InnoDB: about forcing recovery.
081229 10:51:45 [ERROR] D:\MySQL\MySQL Server 5.0\bin\mysqld-nt: Got signal 11. Aborting!081229 10:51:45 [ERROR] Aborting081229 10:51:45 [Note] D:\MySQL\MySQL Server 5.0\bin\mysqld-nt: Shutdown complete

Answer 7

加入[mysqld]没有？实在不行，就只有重新安装了。

Answer 8

加入了 还是不行 是因为mysql不稳定还是我使用不善
其实数据无所谓 只是想知道原因 谢谢大家啦

Answer 9

从提示来看，应该是没有正常退出MYSQL造成的，使用MYSL一段时间，还是比较稳定的，
当然我的数据量不是很大，用InnoDB引擎。