在关系型数据库中，一条普通的UPDATE或DELETE语句如果写法不当，就可能从预期的行级锁变成整张表的排他锁，直接拖垮系统的并发能力。核心原因之一，就是WHERE条件里用到的字段没有可用的索引，导致存储引擎不得不进行全表扫描，进而锁定远超实际修改范围的数据。
一、为什么无索引会导致锁升级
以MySQL的InnoDB引擎为例，它默认采用行级锁，但行锁的实现依赖于索引。当执行一条带有WHERE条件的DML语句时，InnoDB会通过索引查找符合条件的记录，并对命中行的索引项加锁。如果WHERE字段上没有索引，优化器无法快速定位数据，只能执行全表扫描，逐行检查是否满足过滤条件。
在全表扫描过程中，为了防止其他事务修改正在检查的行而导致数据不一致，InnoDB会对扫描过的每一行都加上锁，实际上等同于锁住了整张表。这种现象常被叫做“锁升级”，虽不是传统意义上的页锁转表锁，但效果类似，并发写入会被完全阻塞。下面的示例展示了无索引时的危险操作：
-- 假设users表在phone字段上没有任何索引 UPDATE users SET status = 1 WHERE phone = '13800000000'; -- 执行计划为ALL（全表扫描），将对users表几乎所有行加锁 EXPLAIN UPDATE users SET status = 1 WHERE phone = '13800000000';
二、如何确认WHERE条件是否用了索引
在动手建索引之前，应当先通过执行计划确认语句是否真的走了索引。以MySQL为例，使用EXPLAIN查看type列和key列：如果type为ALL且key为NULL，说明做了全表扫描；如果key显示了具体索引名且type为ref或range，说明使用了索引，锁的范围可控。
除了MySQL，Oracle和PostgreSQL也有类似的检查方式。Oracle中可通过DBMS_XPLAN查看执行计划，PostgreSQL使用EXPLAIN ANALYZE。无论哪种数据库，核心思路一致：确认优化器能否利用索引定位到少量目标行。如下是一个走索引的对比示例：
-- 先创建索引 CREATE INDEX idx_users_phone ON users(phone); -- 再次查看执行计划 EXPLAIN UPDATE users SET status = 1 WHERE phone = '13800000000'; -- 此时type应为ref，key为idx_users_phone，仅锁定匹配行
三、建立合适索引的注意事项
并不是随便建一个索引就能解决问题。首先要确保索引建立在WHERE条件中真正用于过滤的字段上，且字段顺序与组合索引的最左前缀原则匹配。如果WHERE中同时用了多个字段，建立联合索引往往比单列索引更有效。例如条件为WHERE dept_id = 1 AND create_time > '2023-01-01'，适合建联合索引(dept_id, create_time)。
其次，要避免在索引字段上使用函数或隐式类型转换，否则索引会失效。比如WHERE DATE(create_time) = '2023-01-01'会让时间字段索引不可用；又如字符串字段用数字比较也会触发转换。写DML时尽量保持字段“干净”。示例如下：
-- 错误写法：索引失效 UPDATE orders SET flag = 1 WHERE DATE(pay_time) = '2023-01-01'; -- 正确写法：范围查询保留索引 UPDATE orders SET flag = 1 WHERE pay_time >= '2023-01-01 00:00:00' AND pay_time < '2023-01-02 00:00:00';
四、其他辅助手段与总结
除了建索引，还可以通过降低事务粒度、分批处理大量数据来减少锁冲突。例如用主键范围切分DELETE操作，每次只删一万行，缩短持锁时间。但在绝大多数场景下，确保WHERE条件字段有索引是最直接、最根本的避免表锁升级的方法。
实践中建议将“DML语句必须走索引”纳入代码评审清单，结合慢查询日志与锁等待监控，及时发现全表扫描风险。只要过滤字段有合适索引、写法规范，数据库就能精准锁行，保障系统的高并发稳定运行。