我在启动MYSQL后,在命令行执行select * from user; user表只有ID,NAME2个字段,然后系统就windows就提示,MYSQLD.EXE遇到到错误,然后MYSQL就自动停止了。重新启动后,如果不执行这句SQL就没问题,只要执行就有同样的后果。我查看了错误日志,比较难看懂,错误日志如下:
091208 20:26:13 [Note] Plugin 'FEDERATED' is disabled.
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use Windows interlocked functions.
091208 20:26:13  InnoDB: highest supported file format is Barracuda.
091208 20:26:14 InnoDB Plugin 1.0.4 started; log sequence number 47932
091208 20:26:14 [Note] Event Scheduler: Loaded 0 events
091208 20:26:14 [Note] C:\Program Files\MySQL\MySQL Server 5.4\bin\mysqld: ready for connections.
Version: '5.4.3-beta-community'  socket: ''  port: 3306  MySQL Community Server (GPL)
InnoDB: Error: trying to access update undo rec field 4294967040 in index "GEN_CLUST_INDEX" of table "aa"."user"
InnoDB: but index has only 4 fields
InnoDB: Submit a detailed bug report to http://bugs.mysql.com
InnoDB: Run also CHECK TABLE "aa"."user"
InnoDB: n_fields = 14837, i = 13, ptr 03C95657
InnoDB: Error: trying to access update undo rec for table aa/user
InnoDB: but the table id in the undo record is wrong
InnoDB: Submit a detailed bug report to http://bugs.mysql.com
InnoDB: Run also CHECK TABLE aa/user
InnoDB: table aa/user, index GEN_CLUST_INDEX, n_uniq 1
InnoDB: undo rec address 03C955D8, type 13 cmpl_info 5
InnoDB: undo rec table id 0 0, index table id 0 13
InnoDB: dump of 150 bytes in undo rec:  len 150; hex 7a8d5db900000000ffffffffffffffff000000000000b9f50008000000000000bb3c000000000000000000000000000002800000014000000000000000340000000200000000011600000000013e0000000100000000009e00000000009e00000000ffffffff0000ffffffff0000000000000000001d00000000ffffffff0000ffffffff000000000001000000020026000000020026; asc z ]                              <                   @       4               >                                                                 &     &;
InnoDB: index record PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 6; hex 066161616262; asc  aaabb;;
 1: len 6; hex 620000000000; asc b     ;;
 2: len 7; hex 00000000000000; asc        ;;
 3: len 8; hex 0000000000000000; asc         ;;InnoDB: record version PHYSICAL RECORD: n_fields 4; compact format; info bits 0
 0: len 6; hex 066161616262; asc  aaabb;;
 1: len 6; hex 620000000000; asc b     ;;
 2: len 7; hex 00000000000000; asc        ;;
 3: len 8; hex 0000000000000000; asc         ;;InnoDB: Record trx id 620000000000, update rec trx id FFFFFFFF
InnoDB: Roll ptr in rec 0 0, in update rec 4294967040 0
InnoDB: Purge system view:
Normal read view
Read view low limit trx n:o 0 23297
Read view up limit trx id 5B01
Read view low limit trx id 5B01
Read view individually stored trx ids:
InnoDB: Purge trx n:o 0, undo n:o 0
InnoDB: Purge next stored 0, page_no 0, offset 0,
InnoDB: Purge hdr_page_no 0, hdr_offset 0
InnoDB: unknown error code 11
091208 20:26:52  InnoDB: Assertion failure in thread 688 in file .\row\row0mysql.c line 581
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/refman/5.1/en/forcing-recovery.html
InnoDB: about forcing recovery.
091208 20:26:52 - mysqld got exception 0xc0000005 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.key_buffer_size=10485760
read_buffer_size=65536
max_used_connections=1
max_threads=100
threads_connected=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 42871 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.thd: 0xf0a550
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
InnoDB: Thread 1364 stopped in file .\os\os0sync.c line 546
InnoDB: Thread 1932 stopped in file .\os\os0sync.c line 245
005B80E7    mysqld.exe!row_mysql_handle_errors()[row0mysql.c:581]
005C38A6    mysqld.exe!row_search_for_mysql()[row0sel.c:4462]
005FD19B    mysqld.exe!os_fast_mutex_lock()[os0sync.c:663]
005AF187    mysqld.exe!srv_conc_enter_innodb()[srv0srv.c:1079]
005A933C    mysqld.exe!ha_innobase::rnd_next()[ha_innodb.cc:5444]
004E2F56    mysqld.exe!rr_sequential()[records.cc:381]
00516948    mysqld.exe!sub_select()[sql_select.cc:11140]
00526A23    mysqld.exe!do_select()[sql_select.cc:10890]
00527AFB    mysqld.exe!JOIN::exec()[sql_select.cc:2208]
00527D32    mysqld.exe!mysql_select()[sql_select.cc:2399]
0052806B    mysqld.exe!handle_select()[sql_select.cc:270]
00455A44    mysqld.exe!execute_sqlcom_select()[sql_parse.cc:5085]
004568C0    mysqld.exe!mysql_execute_command()[sql_parse.cc:2247]
7C9300B8    ntdll.dll!RtlFreeHeap()
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 03C931A0=select * from user
thd->thread_id=1
thd->killed=NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

解决方案 »

  1.   

    我发现只要执行这个表的查询MYSQL就报这个错误,MYSQL就死掉,但是对这个表可以insert操作。没问题。
      

  2.   

    check table user;
    repair table user;先检查修复一下。有点象是BUG。
      

  3.   

    repair table user; 这个命令用不了,这个命令对innodb没用。 我估计确实是BUG,可能是版本不稳定,我测试版本是5.4.3.
      

  4.   

    MYSQL什么版本、表什么引擎、
    show create table `user`
    select * from `user`
      

  5.   

    5.4.3. 本身就是bata 测试版。
    目前正式发布的是 5.1.41
      

  6.   

    其实这个问题我是测试某个MYSQL命令时出现的,不涉及到数据恢复等问题,所以解决不了也没关系,直接把表删除就可以了。
      

  7.   

    用root用户修改一下操作权限就没有问题了
    出现这个是由于加了死锁造成 的
      

  8.   

    死锁 的 时候 经常出现这个 。很头疼 。我的版本 5。1。49 在线其他 机器 都是准确的 索引名字。 唯独这个 版本出现 index "GEN_CLUST_INDEX" of(1) WAITING FOR THIS LOCK TO BE GRANTED:
    RECORD LOCKS space id 0 page no 311608 n bits 336 index `GEN_CLUST_INDEX` of table `db`.`Ehistory` trx id 0 791965586 lock_mode X locks rec but not gap waiting
    Record lock, heap no 128 PHYSICAL RECORD: n_fields 10; compact format; info bits 0
     0: len 6; hex 00000c937a43; asc     zC;; 1: len 6; hex 00002f346f88; asc   /4o ;; 2: len 7; hex 000003c0830b99; asc        ;; 3: len 8; hex 000000000b1efd8e; asc         ;; 4: len 8; hex 000000000000d9df; asc         ;; 5: len 1; hex 83; asc  ;; 6: len 8; hex 0000000001eadd7c; asc        |;; 7: len 1; hex 44; asc D;; 8: len 1; hex 59; asc Y;; 9: len 1; hex 59; asc Y;;*** (2) TRANSACTION:
    TRANSACTION 0 791965576, ACTIVE 0 sec, process no 7209, OS thread id 1097619776 fetching rows, thread declared inside InnoDB 118
    mysql tables in use 1, locked 1
    126 lock struct(s), heap size 30704, 552 row lock(s), undo log entries 275
    MySQL thread id 140525, query id 1398512707 10.0.1.103 betbrain Updating
    update E