Other cases of SQL errors are general guidelines.

In part 3, you are familiar with the methods of debugging applications in cases where the request plays only an indirect role in the problem.

I would like to draw your attention to the fact that we have considered only the most common cases, while the MySQL server has many parameters, each of which can influence the behavior of the application. Analyze the parameters you apply. One of the tricks: run the same query using the MySQL server running with the –no-defaults option and see if the result is different. If the result is different, analyze the effect of the parameter again and correct the problem.

Reception №24: check requests on the server running with the option --no-defaults and compare the result.

Below is a list of techniques discussed in this part.

Reception number 15: check the value of max_allowed_packet and the size of the transmitted data if the server generates an error for a syntactically correct request.

Reception №16: check the value of wait_timeout and other timeout-s if you encounter the error "MySQL server has gone away"

Reception №17: check the connect_timeout value in case of the error “Lost connection to MySQL server at 'reading authorization packet'”

Reception number 18: always use the error log

Reception number 19: use the general query log if the error log does not contain information about the causes of the server crash.

Admission number 20: always check whether you have enough RAM for the allocated buffers.

Reception number 21: set the value of max_connections as you can serve.

Admission # 22: use the monitoring tools of your operating system to establish what consumes an excessive amount of resources, which leads to the MySQL server crash.

Reception # 23: Use the option log_warnings = 2 to track if you have rejected connections.

Reception №24: check requests on the server running with the option --no-defaults and compare the result.