Debugging a MySQL Client 5. Remove (or move away) any old log files from the MySQL data directory if you need more space. 6. Start  mysqld  with the binary log enabled. If you want to find a statement that crashes  mysqld , you should start the server with the general query log enabled as well. See Section 5.4.3, “The General Query Log” , and Section 5.4.4, “The Binary Log” . 7. When you have gotten a crashed table, stop the  mysqld  server. 8. Restore the backup. 9. Restart the  mysqld  server  without  the binary log enabled. 10. Re-execute the statements with  mysqlbinlog binary-log-file | mysql . The binary log is saved in the MySQL database directory with the name  hostname-bin. NNNNNN . 11. If the tables are corrupted again or you can get  mysqld  to die with the above command, you have found a reproducible bug. FTP the tables and the binary log to our bugs database using the instructions given in Section 1.6, “How to Report Bugs or Problems” . If you are a support customer, you can use the MySQL Customer Support Center (https://www.mysql.com/support/) to alert the MySQL team about the problem and have it fixed as soon as possible. 1159 As of MySQL 8.0.17, to enable detection of lock-acquisition deadlocks and enforcement that runtime execution is free of them, MySQL supports LOCK_ORDER tooling. This enables a lock-order dependency graph to be defined as part of server design, and server runtime checking to ensure that lock acquisition is acyclic and that execution paths comply with the graph. The MySQL server is a multithreaded application that uses numerous internal locking and lock-related primitives, such as mutexes, rwlocks (including prlocks and sxlocks), conditions, and files. Within the server, the set of lock-related objects changes with implementation of new features and code refactoring for performance improvements. As with any multithreaded application that uses locking primitives, there is always a risk of encountering a deadlock during execution when multiple locks are held at once. For MySQL, the effect of a deadlock is catastrophic, causing a complete loss of service. If your client crashes at some ’legal’ looking code, you should check that your  mysql.h  include file matches your MySQL library file. A very common mistake is to use an old  mysql.h  file from an old MySQL installation with new MySQL library. This provides useful information in case you mail a bug report. See Section 1.6, “How to Report Bugs or Problems” . If you have problems with your own client code, you should attempt to connect to the server and run your query using a client that is known to work. Do this by running  mysql  in debugging mode (assuming that you have compiled MySQL with debugging on): This causes clients to generate a trace file in  /tmp/client.trace . Before running a client, you should set the  MYSQL_DEBUG  environment variable: To be able to debug a MySQL client with the integrated debug package, you should configure MySQL with -DWITH_DEBUG=1 . See Section 2.9.7, “MySQL Source-Configuration Options” . 5.9.3 The LOCK_ORDER Tool 5.9.2 Debugging a MySQL Client shell>  MYSQL_DEBUG=d:t:O,/tmp/client.trace shell>  export MYSQL_DEBUG shell>  mysql --debug=d:t:O,/tmp/client.trace