MySQL - 全表扫描 会发生死锁?

MySQL全表扫描与死锁的关系分析：全表扫描本身不会直接导致死锁，但在特定场景下可能间接参与死锁形成。在InnoDB引擎中，不同隔离级别下全表扫描的加锁机制不同，而MyISAM引擎会加表级读锁。死锁发生的四个必要条件包括互斥访问、持有并等待等。全表扫描可能通过并发更新、索引扫描顺序不一致或锁升级冲突等场景间接引发死锁。为避免此类问题，建议优化查询、控制事务大小、统一访问顺序等。通过合理设计索引和访问路径，可有效预防死锁发生。

MySQL 全表扫描与死锁的关系

全表扫描本身不会直接导致死锁 ，但在特定场景下可能间接参与死锁的形成 。

以下是详细分析：

一、全表扫描的锁机制

1. InnoDB 引擎

• ​不加锁​ ：在 READ COMMITTED 或 READ UNCOMMITTED 隔离级别下，普通 SELECT 全表扫描​不加任何锁​

• ​加共享锁​ ：在 REPEATABLE READ 或 SERIALIZABLE 隔离级别下：

  SELECT * FROM table FOR SHARE; -- 显式加共享锁
  SELECT * FROM table LOCK IN SHARE MODE; -- 旧语法

  会逐行加共享锁（S锁）

2. MyISAM 引擎

• ​表级锁​ ：全表扫描会自动加​读锁​，阻塞所有写入操作

二、死锁发生的必要条件

死锁需要同时满足以下条件：

1. ​互斥访问​：资源不能共享
2. ​持有并等待​：进程持有资源同时请求新资源
3. ​不可剥夺​：资源只能自愿释放
4. ​循环等待​：多个进程形成等待环

三、全表扫描参与死锁的场景

场景1：全表扫描 + 并发更新（InnoDB）

-- 事务A
START TRANSACTION;
SELECT * FROM users WHERE age < 18 FOR UPDATE; -- 全表扫描加排他锁

-- 事务B
START TRANSACTION;
UPDATE users SET status=1 WHERE id=5; -- 请求单行锁

若事务A先锁定了id=5的行，事务B被阻塞；同时事务A后续扫描到其他行时可能被事务B已锁定的行阻塞，形成循环等待。

场景2：索引扫描顺序不一致

-- 事务A (使用索引)
UPDATE products SET stock=stock-1 WHERE category='electronics';

-- 事务B (全表扫描)
UPDATE products SET price=price*1.1 WHERE discount > 0.5;

两个事务加锁顺序不同（索引顺序 vs 物理顺序），可能导致交叉死锁。

场景3：锁升级冲突

-- 事务A
SELECT COUNT(*) FROM orders; -- 全表扫描（MyISAM表）

-- 事务B
INSERT INTO orders (...) VALUES (...); -- 等待读锁释放

在MyISAM中，长时间的全表扫描会阻塞所有写入操作，但不会直接导致死锁（因为没有循环等待）。

四、为什么全表扫描很少直接导致死锁？

1. ​扫描过程不加锁​：InnoDB 普通 SELECT 在低隔离级别不加锁

2. ​锁粒度控制​：InnoDB 是逐行加锁，而非一次性锁全表

3. ​死锁检测机制​ ：InnoDB 会自动检测并回滚其中一个事务

   SHOW ENGINE INNODB STATUS; -- 查看最近死锁信息

五、避免全表扫描死锁的最佳实践

1. ​​优化查询​​：

   -- 添加合适索引
   ALTER TABLE users ADD INDEX idx_age (age);

2. ​​控制事务大小​​：

   -- 分批处理
   DELETE FROM logs WHERE created_at < '2020-01-01' LIMIT 1000;

3. ​​统一访问顺序​​：

   // 程序代码中固定操作顺序
   $tables = ['customers', 'orders'];
   sort($tables); // 确保所有事务按相同顺序访问表

4. ​​降低隔离级别​​：

   SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

5. ​​设置锁等待超时​​：

   SET innodb_lock_wait_timeout = 30; -- 单位：秒

六、诊断工具

1. 查看当前锁：

   SELECT * FROM performance_schema.data_locks;

2. 死锁日志：

   SHOW ENGINE INNODB STATUS\G

3. 监控长时间扫描：

   SELECT * FROM sys.session WHERE sql_text LIKE '%SELECT%';

-- 死锁日志

SHOW ENGINE INNODB STATUS\G

结论

全表扫描​​本身不会直接导致死锁​​，但在以下情况可能参与死锁链：

• 显式加锁（FOR UPDATE/LOCK IN SHARE MODE）
• 与更新操作混合执行
• 不同事务使用不同的访问路径

通过合理设计索引、控制事务大小和统一访问顺序，可有效避免此类死锁。