Sometime, a single SQL query may be the cause of all the server’s problems. MySQL has built-in functionality to capture slow query log or identify queries that are not optimal and take a long time to finish, which allows you to log all slow running queries which took over defined number of seconds to execute by MySQL database engine to a file. Slow query log is not activated or on by default MySQL installation, thus it is one of the less-used logs.
To enable slow query log, simply add the following line to MySQL configuration file (my.cnf or my.ini), and then restart the MySQL server:
log-slow-queries
Or,
log-slow-queries = [path to the log file]
Replace [path to the log file] with actual path to the slow query log file you want the MySQL to write the log to, which is the optional value.
Or you can start mysqld with with the –log-slow-queries[=file_name] option to enable the slow query log. In both syntax, if no log file name is specified, the default name is host_name-slow.log, stored in the MySQL data file directory. If a filename is given, but not as an absolute pathname, the server writes the file in the data directory too.
After enabling slow query log, MySQL will create, capture and log to the log file with all SQL statements that took more than long_query_time seconds to execute, which is by default set to 10 seconds. The time to acquire the initial table locks is not counted as execution time. mysqld writes a statement to the slow query log after it has been executed and after all locks have been released, so log order might be different from execution order.
You can then examine all the slow SQL queries in the log file, and then take the necessary steps to optimize the SQL statements. The slow query log will tell you about what was time the query completed, how long the query took to run, how long it took to secure its locks, how many rows were sent back as a result, how many rows were examined to determine the result, which database was used, and the actual query itself. But bear in mind that a SQL query contained in the log may have already optimum, but executed slowly due to the system resources been used up by the actual slow statement that need to be fine tuned.