delete没走索引时innodb并未锁表，而是对全表扫描的每行加next-key锁，锁住几乎所有记录及间隙，等效锁表；根本原因是优化器退化为全表扫描，innodb不预判结果集大小，严格按执行计划逐行加锁。
DELETE没走索引时，InnoDB其实没锁表，而是锁了“几乎全表”
这不是MySQL故意锁整张表，而是InnoDB在全表扫描聚簇索引过程中，对**每行都加next-key lock（记录锁 + 间隙锁）**，最终效果等同于锁表——因为几十万行都被锁住，且间隙覆盖所有可能插入的位置，其他事务改任意一行都可能被阻塞。
关键点在于：优化器退化为全表扫描后，InnoDB不预判结果集大小，只按执行计划走。哪怕WHERE id = 123写错了字段名导致无索引，它也会扫完全部主键节点再判断。
-
EXPLAIN DELETE FROM t WHERE status = 'old'显示type=ALL、key=NULL、rows接近总行数 → 基本可断定会触发锁膨胀 - RR隔离级别下更危险：间隙锁会封锁
status='old'值可能出现的所有区间，进一步扩大阻塞面 - 即使只删1行，只要没索引，也会扫全表加锁
哪些常见写法会让索引“失效”，间接触发锁表
建了索引 ≠ 能用上。很多看似合理的WHERE条件，实际让索引完全失效，导致隐式全表扫描。
-
WHERE DATE(create_time) = '2024-01-01'：函数包裹字段，索引失效 -
WHERE user_id = '123'（user_id是INT）：隐式类型转换，索引失效 -
WHERE status != 'active'：非等值判断，通常无法有效利用B+树索引 - 复合索引
(a, b, c)，但查询是WHERE b = 1 AND c = 2：跳过最左前缀，索引失效
验证方式很简单：把DELETE语句改写成SELECT *，跑一次EXPLAIN。
为什么TRUNCATE不卡，而DELETE一跑就Waiting for table metadata lock
DELETE是DML，全程走事务机制：逐行加X锁、写undo log、维护MVCC链，锁持续到事务结束；TRUNCATE是DDL，只瞬时申请SCH_M表级锁，执行即隐式提交，不进事务队列，所以几乎不排队。
-
DELETE FROM t没加WHERE，仍要全表扫描聚簇索引，逐行加锁、打删除标记、写undo log -
TRUNCATE TABLE t失败时立刻报错（如ERROR 1099），绝不等待；成功则毫秒级完成 - 但注意：
TRUNCATE会重置AUTO_INCREMENT、不触发ON DELETE触发器、不检查外键约束——这些不是锁问题，而是语义差异
真正该查的不是“谁锁了表”，而是“谁没提交事务”
线上看到Waiting for table lock或Waiting for table metadata lock，90%以上不是SQL写得差，而是某个连接挂着未提交的事务，或者程序异常退出后连接没关干净。
- 查谁在 hold 锁：
SHOW PROCESSLIST;找状态为Locked或长时间Waiting for table metadata lock的线程 - 查哪张表被锁死：
SHOW OPEN TABLES WHERE In_use > 0; - 查活跃事务：
SELECT * FROM information_schema.INNODB_TRX ORDER BY trx_started LIMIT 5;看trx_started时间是否异常久 - 查元数据锁详情（MySQL 5.7+）：
SELECT * FROM performance_schema.metadata_locks WHERE LOCK_STATUS = 'GRANTED';
最容易被忽略的是：autocommit=0但忘记手动COMMIT，或者Python脚本里cursor.execute("DELETE ...")后没conn.commit()，连接异常退出也不close——锁就一直挂着，直到超时或连接断开。
