各位观众老爷，晚上好！今天咱们来聊聊MySQL编程里让人头疼，却又不得不面对的一个问题：死锁（Deadlock）。这玩意儿就像程序里的“恋爱脑”，双方互相等待，谁也不肯放手，最终一起“殉情”——程序卡死。
不过别怕，恋爱可以分手，死锁也能解决。今天我就教大家一套“重试大法”，让你的程序不再为爱痴狂，轻松摆脱死锁的困扰。
一、 啥是死锁？它为啥这么烦人？
要解决问题，首先得了解问题。咱们先来扒一扒死锁的底裤，看看它到底是个什么鬼。
简单来说，死锁就是两个或多个事务，因为互相持有对方需要的资源，又都想拿到对方手里的资源，结果谁也拿不到，就这么僵持住了。
举个例子，就像两个人同时想过一个只能容纳一个人的桥，甲走到桥中间，乙也走到桥中间，甲说：“你先退回去，让我过去。”乙说：“凭啥？你先退回去，让我过去。”结果谁也不肯退，两个人就卡在桥中间了。
在MySQL里，资源可以是行锁、表锁、甚至间隙锁。当事务A持有行锁1，想获取行锁2；同时事务B持有行锁2，想获取行锁1，这就可能导致死锁。
死锁为啥烦人？因为它会导致：
- 程序卡死： 事务一直等待，无法完成，用户体验极差。
- 数据不一致： 如果事务回滚，部分数据可能被修改，导致数据不一致。
- 数据库性能下降： 大量事务等待死锁解决，占用数据库资源，影响性能。
二、 死锁长啥样？MySQL怎么发现它？
MySQL不像人一样能一眼看出桥上卡了两个人。它需要通过一些机制来检测死锁。
MySQL主要通过两种方式来检测死锁：
-
等待图（Wait-For Graph）： MySQL会维护一个等待图，记录事务之间的等待关系。如果发现等待图形成环路，就说明发生了死锁。
举个例子：事务A等待事务B，事务B又等待事务A，这就形成了一个环。
-
超时机制（Lock Wait Timeout）： 如果事务等待锁的时间超过
innodb_lock_wait_timeout（默认50秒），MySQL会认为发生了死锁，并回滚其中一个事务。
那死锁具体在MySQL的日志里长啥样呢？ 咱们来举个例子。如果你打开了MySQL的错误日志（error log），你可能会看到类似这样的信息：
2024-10-27T20:00:00.000000+08:00 [ERROR] InnoDB: Deadlock detected!
2024-10-27T20:00:00.000000+08:00 [ERROR] InnoDB: *** (1) TRANSACTION:
TRANSACTION 2583, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 4 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 10, OS thread handle 140152026707712, query id 24 localhost root updating
UPDATE products SET quantity = quantity - 1 WHERE id = 1;
2024-10-27T20:00:00.000000+08:00 [ERROR] InnoDB: *** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 59 page no 485 n bits 72 index PRIMARY of table `ecommerce`.`products` trx id 2583 lock_mode X locks rec but not gap waiting
2024-10-27T20:00:00.000000+08:00 [ERROR] InnoDB: *** (2) TRANSACTION:
TRANSACTION 2584, ACTIVE 1 sec starting index read
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 9, OS thread handle 140152026707712, query id 25 localhost root updating
UPDATE products SET quantity = quantity - 1 WHERE id = 2;
2024-10-27T20:00:00.000000+08:00 [ERROR] InnoDB: *** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 59 page no 485 n bits 72 index PRIMARY of table `ecommerce`.`products` trx id 2584 lock_mode X locks rec but not gap
2024-10-27T20:00:00.000000+08:00 [ERROR] InnoDB: *** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 59 page no 485 n bits 72 index PRIMARY of table `ecommerce`.`products` trx id 2584 lock_mode X locks rec but not gap waiting
2024-10-27T20:00:00.000000+08:00 [ERROR] InnoDB: WE ROLL BACK TRANSACTION (1)这段日志告诉我们，有两个事务（TRANSACTION 2583和TRANSACTION 2584）发生了死锁。它们都在等待ecommerce.products表的主键上的行锁。MySQL选择了回滚TRANSACTION 2583。
三、 解决死锁的终极武器：重试机制
既然死锁无法避免，那咱们就得想办法优雅地处理它。重试机制就是一种常用的解决方案。
重试机制的基本思路是：
- 捕获死锁异常： 当程序执行SQL语句时，如果发生死锁，MySQL会抛出一个异常。我们需要捕获这个异常。
- 回滚事务： 捕获异常后，需要回滚当前事务，释放持有的锁。
- 等待一段时间： 为了避免再次发生死锁，需要等待一段时间。
- 重新执行事务： 等待结束后，重新执行事务。
用代码来表示，大概是这样：
import mysql.connector
import time
def execute_transaction(db_config, sql_statements, max_retries=3, retry_delay=1):
"""
执行事务，如果发生死锁，进行重试。
Args:
db_config (dict): 数据库配置信息，包括host, user, password, database等。
sql_statements (list): SQL语句列表。
max_retries (int): 最大重试次数。
retry_delay (int): 重试间隔时间（秒）。
Returns:
bool: True表示事务执行成功，False表示事务执行失败。
"""
for attempt in range(max_retries):
try:
# 连接数据库
conn = mysql.connector.connect(**db_config)
cursor = conn.cursor()
# 开启事务
conn.start_transaction()
# 执行SQL语句
for sql in sql_statements:
cursor.execute(sql)
# 提交事务
conn.commit()
print(f"事务执行成功，尝试次数：{attempt + 1}")
return True
except mysql.connector.Error as err:
# 捕获死锁异常
if err.errno == 1213: # 1213是MySQL死锁错误码
print(f"检测到死锁，正在重试... 第 {attempt + 1} 次尝试")
# 回滚事务
if conn.is_connected():
conn.rollback()
# 等待一段时间
time.sleep(retry_delay)
else:
# 其他异常，直接抛出
print(f"发生其他异常：{err}")
if conn.is_connected():
conn.rollback()
return False
finally:
# 关闭连接
if conn.is_connected():
cursor.close()
conn.close()
print(f"事务执行失败，达到最大重试次数：{max_retries}")
return False
# 示例用法
db_config = {
'host': 'localhost',
'user': 'root',
'password': 'your_password', # 替换成你的密码
'database': 'ecommerce'
}
sql_statements = [
"UPDATE products SET quantity = quantity - 1 WHERE id = 1",
"UPDATE products SET quantity = quantity - 1 WHERE id = 2"
]
success = execute_transaction(db_config, sql_statements)
if success:
print("事务最终执行成功")
else:
print("事务最终执行失败")
这段代码的核心在于：
mysql.connector.Error as err: 捕获MySQL的异常。err.errno == 1213: 判断是否是死锁错误（错误码1213）。conn.rollback(): 回滚事务，释放锁。time.sleep(retry_delay): 等待一段时间，避免立即重试导致再次死锁。execute_transaction(...): 递归调用自己，实现重试。max_retries: 设置最大重试次数，防止无限循环。
四、 重试机制的进阶用法：参数调优与日志记录
光有重试机制还不够，咱们还得对它进行一些优化，让它更好地为我们服务。
-
调整重试参数：
max_retries： 最大重试次数。这个值不能太小，否则可能无法解决死锁；也不能太大，否则会浪费资源。一般来说，3-5次就够了。retry_delay： 重试间隔时间。这个值也不能太小，否则可能仍然会发生死锁；也不能太大，否则会影响性能。一般来说，1-3秒就够了。
你可以根据实际情况调整这两个参数，找到一个平衡点。
可以用表格来总结一下：
参数 描述 建议值 注意事项 max_retries最大重试次数，当死锁发生时，事务最多尝试重新执行的次数。 3-5 设置过小可能无法解决死锁，设置过大可能浪费资源。 retry_delay重试间隔时间（秒），每次重试之间等待的时间。 1-3秒 设置过小可能仍然会发生死锁，设置过大可能影响性能。 -
记录重试日志：
为了方便排查问题，我们需要记录重试日志。日志里应该包含以下信息：
- 死锁发生的时间
- 发生死锁的SQL语句
- 重试次数
- 重试结果
你可以使用Python的
logging模块来记录日志。import logging # 配置日志 logging.basicConfig(filename='deadlock_retry.log', level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s') def execute_transaction(db_config, sql_statements, max_retries=3, retry_delay=1): """ 执行事务，如果发生死锁，进行重试。记录详细日志。 """ for attempt in range(max_retries): try: # 连接数据库 conn = mysql.connector.connect(**db_config) cursor = conn.cursor() # 开启事务 conn.start_transaction() # 执行SQL语句 for sql in sql_statements: cursor.execute(sql) # 提交事务 conn.commit() logging.info(f"事务执行成功，尝试次数：{attempt + 1}") print(f"事务执行成功，尝试次数：{attempt + 1}") return True except mysql.connector.Error as err: # 捕获死锁异常 if err.errno == 1213: # 1213是MySQL死锁错误码 logging.warning(f"检测到死锁，正在重试... 第 {attempt + 1} 次尝试, 错误信息：{err}") print(f"检测到死锁，正在重试... 第 {attempt + 1} 次尝试") # 回滚事务 if conn.is_connected(): conn.rollback() # 等待一段时间 time.sleep(retry_delay) else: # 其他异常，直接抛出 logging.error(f"发生其他异常：{err}") print(f"发生其他异常：{err}") if conn.is_connected(): conn.rollback() return False finally: # 关闭连接 if conn.is_connected(): cursor.close() conn.close() logging.error(f"事务执行失败，达到最大重试次数：{max_retries}") print(f"事务执行失败，达到最大重试次数：{max_retries}") return False这样，你就可以通过查看日志，了解死锁发生的情况，并进行相应的优化。
五、 如何预防死锁？防患于未然才是王道
虽然重试机制可以解决死锁问题，但最好的办法还是预防死锁的发生。
以下是一些预防死锁的常用技巧：
- 保持事务短小： 事务越长，占用锁的时间就越长，发生死锁的概率就越高。尽量将事务拆分成小的、独立的单元。
- 按照固定的顺序访问资源： 如果多个事务都需要访问多个资源，确保它们按照相同的顺序访问资源。这样可以避免形成环路等待。
- 使用较低的隔离级别： 较高的隔离级别虽然可以保证数据的一致性，但也会增加锁的竞争，提高死锁的概率。根据实际情况选择合适的隔离级别。
READ COMMITTED是一个比较好的选择，它既能保证一定的隔离性，又能减少锁的竞争。 - 尽量使用索引访问数据： 使用索引可以减少锁的范围，降低死锁的概率。
- 避免长事务： 尽量避免长时间运行的事务，特别是在高并发的环境下。
- 设置合理的锁等待超时时间：
innodb_lock_wait_timeout参数控制了事务等待锁的最长时间。设置一个合理的超时时间，可以避免事务长时间阻塞。 - 使用乐观锁： 乐观锁是一种避免锁竞争的技术。它假设数据在事务执行期间不会被其他事务修改。在提交事务时，检查数据是否被修改过。如果被修改过，则回滚事务。
举个例子，如果两个事务都需要更新products表和orders表，那么应该确保它们按照相同的顺序更新，比如先更新products表，再更新orders表。
六、 总结：重试大法好，但预防更重要
今天咱们学习了如何通过重试机制解决MySQL死锁问题。重试机制是一种简单有效的解决方案，但它并不是万能的。在实际应用中，我们应该尽量预防死锁的发生，同时结合重试机制，才能更好地保证程序的稳定性和性能。
记住，预防胜于治疗！希望今天的讲座能帮助你更好地应对MySQL死锁问题。
好了，今天的分享就到这里，感谢大家的观看！下次再见！