Resolving deadlocks in MySQL applications
Jul 03, 2025 am 02:13 AMMySQL deadlock is caused by multiple transactions being cross-waited for resources, and can be reduced by unified access order, shortening transaction time, and rational use of indexes. For example, when transaction A and transaction B hold different resources respectively and request each other's resources, a deadlock will be formed; through the SHOW ENGINE INNODB STATUS command, you can view detailed deadlock logs, analyze transaction SQL, lock types and related rows; during development, the access order should be unified to avoid orders first and then users or the other side; shorten the transaction execution time and reduce lock occupation; ensure that the WHERE condition hits the index to reduce the lock range; batch updates are sorted by primary key; the application layer captures 1213 error codes and retrys the transaction; occasional deadlocks are normal, and frequent occurrences require the design of combining logs and business optimization.
MySQL deadlock is a common problem in concurrent systems, especially in scenarios where high concurrent write operations are high. When a deadlock is encountered, MySQL usually automatically detects and rolls back one of the transactions to break the deadlock, but frequent deadlocks can affect performance and user experience. The key is to understand the causes and avoid them at the design and coding stages.

Common causes of deadlocks
Deadlocks in MySQL usually occur when multiple transactions are waiting for resources held by each other. The most typical case is that two transactions each hold part of the resources and try to acquire the resources that the other party has locked, thus entering a state of waiting for each other.

For example:
- Transaction A updated the id=1 row of table users;
- At the same time, transaction B updates the id=100 row of table orders;
- Then transaction A wants to update orders.id=100, while transaction B wants to update users.id=1;
- At this time, MySQL will report a deadlock error and select a transaction to roll back.
Other reasons include:

- Inconsistent access order (such as accessing orders first and then users vs first and then orders);
- Gap Lock or Next-Key Lock is used, resulting in overlapping lock ranges;
- There is no suitable index, resulting in more rows locked or even the entire table.
How to view deadlock logs
When a deadlock occurs, you can view detailed deadlock information through the SHOW ENGINE INNODB STATUS
command. This command outputs a lot of content, but the focus is on the LATEST DETECTED DEADLOCK part.
The sample output snippet is as follows:
LATEST DETECTED DEADLOCK ---------------------------- ...Transaction A waits for lock... ...Transaction B is holding a lock...
By analyzing this information, you can clearly see:
- Which transactions are involved in the deadlock;
- Which SQL do they execute separately;
- Type of lock (record lock, gap lock, etc.);
- The index and specific data rows involved.
It is recommended to save this information for subsequent optimization of code logic or database structure.
Practical Tips to Reduce Deadlocks
To reduce deadlocks, the key is to allow transactions to access resources in the same order as possible, avoiding cross-waiting. Here are some practices that can be used in actual development:
-
?Unified access order
All transactions access tables and rows in a fixed order. For example, always update the users table first and then the orders table, rather than the other way around.
-
?Short transaction time
Minimize the number of operations in a transaction and avoid complex calculations or calling external interfaces in a transaction. The shorter the better.
-
?Rational use of indexes
If the WHERE condition does not hit the index, it may cause full table scans and thus excessive locking. Check the slow query log to make sure that fields involved in updates have appropriate indexes.
-
? Pay attention to the order when batch updates
When processing batch updates, it is best to sort by primary key before executing, so that all transactions access data in the same order to reduce the probability of conflict.
-
?Catch deadlock and try again
At the application layer, the deadlock error (such as 1213 error code) is captured and the transaction is automatically retryed. Although deadlocks cannot be avoided, they can improve the user experience.
Last point: Deadlock is not a big problem, frequent
It is normal to occasionally occur deadlocks, and MySQL will automatically handle them. But if it happens frequently every day or even every hour, it should be taken seriously. Only by starting with logs and combining business logic, gradually optimizing transaction processes and database design can we fundamentally reduce the impact of deadlocks.
Basically that's it.
The above is the detailed content of Resolving deadlocks in MySQL applications. 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

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.

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.

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.

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.

To view the size of the MySQL database and table, you can query the information_schema directly or use the command line tool. 1. Check the entire database size: Execute the SQL statement SELECTtable_schemaAS'Database',SUM(data_length index_length)/1024/1024AS'Size(MB)'FROMinformation_schema.tablesGROUPBYtable_schema; you can get the total size of all databases, or add WHERE conditions to limit the specific database; 2. Check the single table size: use SELECTta

To set up asynchronous master-slave replication for MySQL, follow these steps: 1. Prepare the master server, enable binary logs and set a unique server-id, create a replication user and record the current log location; 2. Use mysqldump to back up the master library data and import it to the slave server; 3. Configure the server-id and relay-log of the slave server, use the CHANGEMASTER command to connect to the master library and start the replication thread; 4. Check for common problems, such as network, permissions, data consistency and self-increase conflicts, and monitor replication delays. Follow the steps above to ensure that the configuration is completed correctly.

MySQL supports transaction processing, and uses the InnoDB storage engine to ensure data consistency and integrity. 1. Transactions are a set of SQL operations, either all succeed or all fail to roll back; 2. ACID attributes include atomicity, consistency, isolation and persistence; 3. The statements that manually control transactions are STARTTRANSACTION, COMMIT and ROLLBACK; 4. The four isolation levels include read not committed, read submitted, repeatable read and serialization; 5. Use transactions correctly to avoid long-term operation, turn off automatic commits, and reasonably handle locks and exceptions. Through these mechanisms, MySQL can achieve high reliability and concurrent control.

Character set and sorting rules issues are common when cross-platform migration or multi-person development, resulting in garbled code or inconsistent query. There are three core solutions: First, check and unify the character set of database, table, and fields to utf8mb4, view through SHOWCREATEDATABASE/TABLE, and modify it with ALTER statement; second, specify the utf8mb4 character set when the client connects, and set it in connection parameters or execute SETNAMES; third, select the sorting rules reasonably, and recommend using utf8mb4_unicode_ci to ensure the accuracy of comparison and sorting, and specify or modify it through ALTER when building the library and table.
