我是小耶，干运营半路出家的野生DBA——写功课只是为了我踩过的坑，你们别再踩了！
一、先搞懂几个基本概念
在理解“为什么没有索引会锁全表”之前，需要知道这几个名词：
- 行锁（Row Lock）：只锁定某一行记录。其他行仍然可以并发读写，并发度高。
- 表锁（Table Lock）：锁定整张表。任何读写操作都要等待，并发度为0。
- 索引（Index）：InnoDB的行锁是基于索引实现的。更新时只有通过索引定位到具体行，才能只锁那一行。如果没有索引，InnoDB无法确定要锁哪些行，就只能锁全表。
- 锁升级（Lock Escalation）：从行锁升级为表锁。InnoDB本身不会自动升级，但当你更新时没有索引可用，实际效果就等同于全表锁。
刚工作那会儿，我写了一个批量更新脚本：把订单表中所有“待支付”状态更新为“已取消”。测试环境跑了没问题，一上生产，整个订单系统卡死了。登录数据库一看，所有的 SELECT 和 INSERT 都在等待。最后发现，status 字段没有索引，UPDATE 锁了整张表。从那以后，我牢牢记住了：UPDATE 和 DELETE 的 WHERE 条件字段，必须有索引。
二、为什么没有索引会锁全表？
InnoDB 的行锁实现原理：当执行 UPDATE ... WHERE status = '待支付' 时，InnoDB 需要在表中找到所有满足 status='待支付' 的行。如果 status 没有索引，数据库只能全表扫描。扫描过程中，为了防止其他事务同时修改这些行，InnoDB 会对每一行加行锁。但由于扫描的是整张表，实际上锁住了所有行，效果等同于表锁。
更准确的说法：InnoDB 不会真的把锁升级为表锁，而是逐行加锁，但因为扫描全表，最终锁了所有行。这比表锁更消耗资源（每行锁都有内存开销）。如果事务一直没有提交，锁会一直持有，造成大面积阻塞。
三、如何排查当前锁问题？
当业务卡顿，怀疑有锁等待时，执行：
SHOW ENGINE INNODB STATUS\G
找到 LATEST DETECTED DEADLOCK 部分看死锁信息。如果是锁等待（未死锁），用以下语句查看：
SELECT * FROM information_schema.INNODB_LOCKS; -- 当前持有的锁
SELECT * FROM information_schema.INNODB_LOCK_WAITS; -- 锁等待关系
也可以使用 sys.schema_table_lock_waits 视图（MySQL 5.7+）快速定位。
四、五个避免全表锁的实战方法
- WHERE 条件字段必须有索引
优先检查EXPLAIN的type列，如果是ALL，说明没有走索引，非常危险。 - 批量操作拆小，用 LIMIT 分批
-- 每次更新1000行，循环直到影响行数为0
UPDATE orders SET status='已完成' WHERE status='待支付' LIMIT 1000;
减少长事务，降低锁持有时间。
- 事务里不要做无关操作
避免在事务中等待外部接口、用户输入等，尽快COMMIT。 - 合理设置隔离级别
READ-COMMITTED可以减少间隙锁，降低锁冲突概率。 - 开启死锁监控
innodb_print_all_deadlocks = ON将所有死锁信息记录到错误日志，便于事后分析。
五、死锁发生后怎么办？
数据库会自动回滚其中一个事务。你需要在应用层捕获死锁异常（MySQL 错误码 1213），并重试 2-3 次。同时从根本上优化 SQL 和索引设计，减少锁冲突。
六、你学会这个知识能获得什么？
- 避免生产事故：知道为什么必须给
WHERE字段加索引，不再因为遗漏索引导致全表锁，引发系统崩溃。 - 缩短故障排查时间：学会用
SHOW ENGINE INNODB STATUS和锁相关视图快速定位锁问题，而不是瞎猜。 - 写出更优的更新SQL：理解锁机制后，你能写出分批更新、小事务、带索引条件的 SQL，提升系统并发能力。
- 在面试中展现深度：能解释行锁与索引的关系，以及无索引更新的锁行为，是中级DBA的关键能力指标。
总结：没有索引的 UPDATE 或 DELETE，不仅慢，还可能锁死整个表。加索引、拆批量、短事务，是保命三件套。
小耶在手，SQL不愁。
