我最近使用MyISAM将一堆MYI，MYD和FRM文件从一个MySQL 5.0.95服务器rsync到另一个服务器。由于忘记了热修复，事实证明原始数据库配置为默认表为utf8，新数据库设置为latin1。当我们打开新数据库时，它可以工作，但不久之后，几个查询导致它连续多次发生段错误。我怀疑它与charset差异有关，但是我不太清楚堆栈跟踪是否足以找到问题的根源。下面是解码的堆栈跟踪，然后是mysql.log。
堆栈追踪：
0x819b416 handle_segfault + 806
0xb76246a1 _end + -1358137335
0x8193936 Protocol::store_string_aux(char const*, unsigned int, charset_info_st*, charset_info_st*) + 166
0x8193a2b Protocol_simple::store(Field*) + 139
0x818f671 select_send::send_data(List<Item>&) + 161
0x81e5735 init_read_record_seq(st_join_table*) + 373
0x81e8629 join_read_always_key_or_null(st_join_table*) + 2153
0x81ecbc7 sub_select(JOIN*, st_join_table*, bool) + 135
0x81ef127 JOIN::rollup_write_data(unsigned int, st_table*) + 2487
0x81ff6ed JOIN::exec() + 1341
0x81fc72b _Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select + 219
0x82015a6 handle_select(THD*, st_lex*, select_result*, unsigned long) + 326
0x81b1240 mysql_execute_command(THD*) + 7728
0x81b6140 mysql_parse(THD*, char const*, unsigned int, char const**) + 640
0x81b88d0 dispatch_command(enum_server_command, THD*, char*, unsigned int) + 3408
0x81b9f30 handle_one_connection + 2624
0xb785f10f _end + -1355799945
0xb767c74e _end + -1357776714
mysql.log：
160623 17:39:52 - mysqld got signal 11 ;
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=209715200
read_buffer_size=262144
max_used_connections=4
max_connections=1500
threads_connected=4
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 3660800 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd=0x86799f8
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...
Cannot determine thread, fp=0xa648d168, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x819b416
0xb75d56a1
0x8193936
0x8193a2b
0x818f671
0x81e5735
0x81e8629
0x81ecbc7
0x81ef127
0x81ff6ed
0x81fc72b
0x82015a6
0x81b1240
0x81b6140
0x81b88d0
0x81b9f30
0xb781010f
0xb762d74e
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x875aaf0 = SELECT * FROM Data_197_21268_1 ORDER BY ID LIMIT 1
thd->thread_id=8
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.
提前感谢您提供的任何帮助。另外，我知道我必须升级MySQL，这是在起作用。