result. (This is not true if you are running with the delay_key_write  system variable enabled, in which case data files are written but not index files.) This means that data file contents are safe even if mysqld crashes, because the operating system ensures that the unflushed data is written to disk. You can force MySQL to flush everything to disk after every SQL statement by starting mysqld  with the --flush  option. 

The preceding means that normally you should not get corrupted tables unless one of the following happens: 

•The MySQL server or the server host was killed in the middle of an update. 

•You have found a bug in mysqld  that caused it to die in the middle of an update. 

•Some external program is manipulating data files or index files at the same time as mysqld  without locking the table properly. 

•You are running many mysqld  servers using the same data directory on a system that does not support good file system locks (normally handled by the lockd  lock manager), or you are running multiple servers with external locking disabled. 

•You have a crashed data file or index file that contains very corrupt data that confused mysqld . 

•You have found a bug in the data storage code. This isn’t likely, but it is at least possible. In this case, you can try to change the storage engine to another engine by using ALTER TABLE  on a repaired copy of the table. 

Because it is very difficult to know why something is crashing, first try to check whether things that work for others result in an unexpected exit for you. Try the following things: 

•Stop the mysqld  server with mysqladmin shutdown , run myisamchk --silent --force */ *.MYI  from the data directory to check all MyISAM  tables, and restart mysqld . This ensures that you are running from a clean state. See Chapter 5, MySQL Server Administration . 

•Start mysqld  with the general query log enabled (see Section 5.4.3, “The General Query Log” ). Then try to determine from the information written to the log whether some specific query kills the server. About 95% of all bugs are related to a particular query. Normally, this is one of the last queries in the log file just before the server restarts. See Section 5.4.3, “The General Query Log” . If you can repeatedly kill MySQL with a specific query, even when you have checked all tables just before issuing it, then you have isolated the bug and should submit a bug report for it. See Section 1.6, “How to Report Bugs or Problems” . 

•Try to make a test case that we can use to repeat the problem. See Section 5.9, “Debugging MySQL” . 

•Try the fork_big.pl  script. (It is located in the tests  directory of source distributions.) 

•Configuring MySQL for debugging makes it much easier to gather information about possible errors if something goes wrong. Reconfigure MySQL with the -DWITH_DEBUG=1  option to CMake  and then recompile. See Section 5.9, “Debugging MySQL” . 

•Make sure that you have applied the latest patches for your operating system. 

•Use the --skip-external-locking  option to mysqld . On some systems, the lockd  lock manager does not work properly; the --skip-external-locking  option tells mysqld  not to use external locking. (This means that you cannot run two mysqld  servers on the same data directory and that you must be careful if you use myisamchk . Nevertheless, it may be instructive to try the option as a test.) 

•If mysqld  appears to be running but not responding, try mysqladmin -u root processlist . Sometimes mysqld  is not hung even though it seems unresponsive. The problem may be that all connections are in use, or there may be some internal lock problem. mysqladmin -u root 

