首先是程序报错：
ERROR 1135: Can't create a new thread (errno 12). If you are not out of available memory, you can consult the manual for a possible OS-dependent bug
查看日志：key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections =2340507 K
配置文件中 innodb_buffer_pool_size = 2G，在32位操作系统下 mysql 的内存超过了4GB，不崩溃才怪咧。。。
InnoDB: Fatal error: cannot allocate 196608 bytes of InnoDB: memory with malloc! Total allocated memory InnoDB: by InnoDB 2307421120 bytes. Operating system errno: 12 InnoDB: Cannot continue operation! InnoDB: Check if you should increase the swap file or InnoDB: ulimits of your operating system. InnoDB: On FreeBSD check you have compiled the OS with InnoDB: a big enough maximum process size. InnoDB: We now intentionally generate a seg fault so that InnoDB: on Linux we get a stack trace. 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=402653184 read_buffer_size=2093056 max_used_connections=167 max_connections=600 threads_connected=167 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2340507 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=(nil) 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=0x2d2aae98, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x8101ff5 0x996420 (nil) 0x82a0986 0x82648ac 0x81a2249 0x67949b 0x5f942e 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 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 0 120419 16:42:05 mysqld restarted 120419 16:42:05 InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 2391 788299922 InnoDB: Doing recovery: scanned up to log sequence number 2391 793542656 InnoDB: Doing recovery: scanned up to log sequence number 2391 798785536 InnoDB: Doing recovery: scanned up to log sequence number 2391 804028416 InnoDB: Doing recovery: scanned up to log sequence number 2391 809271296 InnoDB: Doing recovery: scanned up to log sequence number 2391 814514176 InnoDB: Doing recovery: scanned up to log sequence number 2391 819757056 InnoDB: Doing recovery: scanned up to log sequence number 2391 824999936 InnoDB: Doing recovery: scanned up to log sequence number 2391 830242816 InnoDB: Doing recovery: scanned up to log sequence number 2391 835485696 InnoDB: Doing recovery: scanned up to log sequence number 2391 840728576 InnoDB: Doing recovery: scanned up to log sequence number 2391 845971456 InnoDB: Doing recovery: scanned up to log sequence number 2391 851214336 InnoDB: Doing recovery: scanned up to log sequence number 2391 856457216 InnoDB: Doing recovery: scanned up to log sequence number 2391 861700096 InnoDB: Doing recovery: scanned up to log sequence number 2391 866942976 InnoDB: Doing recovery: scanned up to log sequence number 2391 872185856 InnoDB: Doing recovery: scanned up to log sequence number 2391 877428736 InnoDB: Doing recovery: scanned up to log sequence number 2391 882671616 InnoDB: Doing recovery: scanned up to log sequence number 2391 887914496 InnoDB: Doing recovery: scanned up to log sequence number 2391 893157376 InnoDB: Doing recovery: scanned up to log sequence number 2391 898400256 InnoDB: Doing recovery: scanned up to log sequence number 2391 903643136 InnoDB: Doing recovery: scanned up to log sequence number 2391 908886016 InnoDB: Doing recovery: scanned up to log sequence number 2391 914128896 InnoDB: Doing recovery: scanned up to log sequence number 2391 919371776 InnoDB: Doing recovery: scanned up to log sequence number 2391 924614656 InnoDB: Doing recovery: scanned up to log sequence number 2391 929389979 120419 16:42:08 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed InnoDB: Last MySQL binlog file position 0 248513413, file name /data/mysqlbinlog/mysql-bin.1554 120419 16:43:23 InnoDB: Flushing modified pages from the buffer pool... 120419 16:43:59 InnoDB: Started /usr/local/mysql/libexec/mysqld: ready for connections. Version: '4.0.26-log' socket: '/tmp/mysql.sock' port: 3306 Source distribution