Analyzing the MySQL Slow Query Log to Find Performance Bottlenecks
Jul 04, 2025 am 02:46 AM
Turn on MySQL slow query logs and analyze locationable performance issues. 1. Edit the configuration file or dynamically set slow_query_log and long_query_time; 2. The log contains key fields such as Query_time, Lock_time, Rows_examined to assist in judging efficiency bottlenecks; 3. Use mysqldumpslow or pt-query-digest tools to efficiently analyze logs; 4. Optimization suggestions include adding indexes, avoiding SELECT *, splitting complex queries, etc. For example, adding an index to user_id can significantly reduce the number of scanned rows and improve query efficiency.
MySQL's slow query log is an important tool for troubleshooting performance issues. If you find that the database response is slow, or some page loading time increases significantly, turning on and analyzing slow query logs can often quickly locate the problem.
Turn on slow query log
First, make sure that the slow query log is enabled and a suitable definition of "slow" is set. By default, this value is 1 second, but you can adjust it according to actual needs:
- Edit
my.cnformy.inifile:slow_query_log = 1 slow_query_log_file = /var/log/mysql/mysql-slow.log long_query_time = 0.5
It can also be dynamically set through SQL:
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 0.5;
Note: After modifying the parameters, you may need to reconnect or refresh the session to take effect.
Analyze slow query log content
Each line of the record in the log file contains execution time, lock time, return number of rows, scan number of rows, and actual execution of SQL statements. for example:
# Query_time: 2.34 Lock_time: 0.00 Rows_sent: 10 Rows_examined: 100000 SELECT * FROM orders WHERE user_id = 123;
Although the above SQL only returns 10 data, it scans 100,000 rows, indicating that it is likely that the index is missing or the query method is not efficient enough.
Several common key fields:
-
Query_time: The time taken in the entire query (seconds) -
Lock_time: the time to wait for the lock -
Rows_examined: Number of rows scanned -
Rows_sent: The number of rows sent to the client
If Rows_examined is much larger than Rows_sent , then you need to consider optimizing the index or query structure.
Recommended commonly used analysis tools
Manual log viewing is inefficient, and some tools can be used to help analyze:
mysqldumpslow : MySQL comes with command line tool, which can count and summarize slow queries.
mysqldumpslow -s at -t 10 /var/log/mysql/mysql-slow.log
The above command will sort by average time and list the top 10 slowest queries.
pt-query-digest : A tool in Percona Toolkit, which is more powerful and supports more complex aggregation and analysis.
pt-query-digest /var/log/mysql/mysql-slow.log > report.txt
These tools can help you find out which SQLs appear frequently and consume more resources, so as to prioritize optimization.
Common optimization suggestions
Once you find the slow queries, the next step is to optimize them. Here are some common practices:
- Index fields that are frequently queried, especially fields in
WHEREandJOINconditions - Avoid using
SELECT *and select only necessary fields - Use
EXPLAINto view the execution plan and confirm whether the index is hit - Reasonably split complex queries to avoid long-term use of resources in large queries
- Do table analysis regularly (
ANALYZE TABLE) to keep statistical information accurate
For example, the above mentioned SELECT * FROM orders WHERE user_id = 123; if no index is established on user_id , you can greatly improve performance by adding indexes:
ALTER TABLE orders ADD INDEX idx_user_id (user_id);
When this is executed again, the number of scanned rows may drop from tens of thousands to tens of dozens, which is very obvious.
Basically that's it. It is not particularly difficult to analyze slow query logs, but it is indeed easy to ignore some details, such as whether the index actually works, whether the execution plan has changed, etc. As long as you insist on regular inspections, you can promptly discover potential problems SQL to avoid performance deterioration.
The above is the detailed content of Analyzing the MySQL Slow Query Log to Find Performance Bottlenecks. For more information, please follow other related articles on the PHP Chinese website!
Hot AI Tools
Undress AI Tool
Undress images for free
Undresser.AI Undress
AI-powered app for creating realistic nude photos
AI Clothes Remover
Online AI tool for removing clothes from photos.
Clothoff.io
AI clothes remover
Video Face Swap
Swap faces in any video effortlessly with our completely free AI face swap tool!
Hot Article
Hot Tools
Notepad++7.3.1
Easy-to-use and free code editor
SublimeText3 Chinese version
Chinese version, very easy to use
Zend Studio 13.0.1
Powerful PHP integrated development environment
Dreamweaver CS6
Visual web development tools
SublimeText3 Mac version
God-level code editing software (SublimeText3)
Hot Topics
Resetting the root password for MySQL server
Jul 03, 2025 am 02:32 AM
To reset the root password of MySQL, please follow the following steps: 1. Stop the MySQL server, use sudosystemctlstopmysql or sudosystemctlstopmysqld; 2. Start MySQL in --skip-grant-tables mode, execute sudomysqld-skip-grant-tables&; 3. Log in to MySQL and execute the corresponding SQL command to modify the password according to the version, such as FLUSHPRIVILEGES;ALTERUSER'root'@'localhost'IDENTIFIEDBY'your_new
Performing logical backups using mysqldump in MySQL
Jul 06, 2025 am 02:55 AM
mysqldump is a common tool for performing logical backups of MySQL databases. It generates SQL files containing CREATE and INSERT statements to rebuild the database. 1. It does not back up the original file, but converts the database structure and content into portable SQL commands; 2. It is suitable for small databases or selective recovery, and is not suitable for fast recovery of TB-level data; 3. Common options include --single-transaction, --databases, --all-databases, --routines, etc.; 4. Use mysql command to import during recovery, and can turn off foreign key checks to improve speed; 5. It is recommended to test backup regularly, use compression, and automatic adjustment.
Handling NULL Values in MySQL Columns and Queries
Jul 05, 2025 am 02:46 AM
When handling NULL values ??in MySQL, please note: 1. When designing the table, the key fields are set to NOTNULL, and optional fields are allowed NULL; 2. ISNULL or ISNOTNULL must be used with = or !=; 3. IFNULL or COALESCE functions can be used to replace the display default values; 4. Be cautious when using NULL values ??directly when inserting or updating, and pay attention to the data source and ORM framework processing methods. NULL represents an unknown value and does not equal any value, including itself. Therefore, be careful when querying, counting, and connecting tables to avoid missing data or logical errors. Rational use of functions and constraints can effectively reduce interference caused by NULL.
Establishing secure remote connections to a MySQL server
Jul 04, 2025 am 01:44 AM
TosecurelyconnecttoaremoteMySQLserver,useSSHtunneling,configureMySQLforremoteaccess,setfirewallrules,andconsiderSSLencryption.First,establishanSSHtunnelwithssh-L3307:localhost:3306user@remote-server-Nandconnectviamysql-h127.0.0.1-P3307.Second,editMyS
Analyzing the MySQL Slow Query Log to Find Performance Bottlenecks
Jul 04, 2025 am 02:46 AM
Turn on MySQL slow query logs and analyze locationable performance issues. 1. Edit the configuration file or dynamically set slow_query_log and long_query_time; 2. The log contains key fields such as Query_time, Lock_time, Rows_examined to assist in judging efficiency bottlenecks; 3. Use mysqldumpslow or pt-query-digest tools to efficiently analyze logs; 4. Optimization suggestions include adding indexes, avoiding SELECT*, splitting complex queries, etc. For example, adding an index to user_id can significantly reduce the number of scanned rows and improve query efficiency.
Aggregating data with GROUP BY and HAVING clauses in MySQL
Jul 05, 2025 am 02:42 AM
GROUPBY is used to group data by field and perform aggregation operations, and HAVING is used to filter the results after grouping. For example, using GROUPBYcustomer_id can calculate the total consumption amount of each customer; using HAVING can filter out customers with a total consumption of more than 1,000. The non-aggregated fields after SELECT must appear in GROUPBY, and HAVING can be conditionally filtered using an alias or original expressions. Common techniques include counting the number of each group, grouping multiple fields, and filtering with multiple conditions.
Managing Transactions and Locking Behavior in MySQL
Jul 04, 2025 am 02:24 AM
MySQL transactions and lock mechanisms are key to concurrent control and performance tuning. 1. When using transactions, be sure to explicitly turn on and keep the transactions short to avoid resource occupation and undolog bloating due to long transactions; 2. Locking operations include shared locks and exclusive locks, SELECT...FORUPDATE plus X locks, SELECT...LOCKINSHAREMODE plus S locks, write operations automatically locks, and indexes should be used to reduce the lock granularity; 3. The isolation level is repetitively readable by default, suitable for most scenarios, and modifications should be cautious; 4. Deadlock inspection can analyze the details of the latest deadlock through the SHOWENGINEINNODBSTATUS command, and the optimization methods include unified execution order, increase indexes, and introduce queue systems.
Paginating Results with LIMIT and OFFSET in MySQL
Jul 05, 2025 am 02:41 AM
MySQL paging is commonly implemented using LIMIT and OFFSET, but its performance is poor under large data volume. 1. LIMIT controls the number of each page, OFFSET controls the starting position, and the syntax is LIMITNOFFSETM; 2. Performance problems are caused by excessive records and discarding OFFSET scans, resulting in low efficiency; 3. Optimization suggestions include using cursor paging, index acceleration, and lazy loading; 4. Cursor paging locates the starting point of the next page through the unique value of the last record of the previous page, avoiding OFFSET, which is suitable for "next page" operation, and is not suitable for random jumps.
