WHERE条件未走索引时，UPDATE/DELETE会锁全表；因InnoDB在无法精确定位索引记录时会对所有聚簇索引记录及间隙加X锁，等效于锁表，尤其在REPEATABLE READ下必然发生。
WHERE条件没走索引时，UPDATE/DELETE会锁全表
InnoDB的行级排他锁（X锁）只在能精确定位到索引记录时生效。一旦WHERE条件无法命中索引，优化器就会退化为全表扫描——此时InnoDB会对**所有聚簇索引记录 + 所有间隙**加锁，等效于锁表。这不是“性能差”，而是明确的锁行为升级，尤其在REPEATABLE READ隔离级别下必然发生。
常见触发场景包括：
- remark列无索引，却执行UPDATE user_info SET user_name='keke' WHERE remark='keke1'
- 对索引列使用函数：WHERE UPPER(name) = 'JOHN'
- 类型隐式转换：WHERE mobile = 13800138000（mobile是VARCHAR）
- 参数选择性太低，优化器判定全表扫描成本更低（如WHERE status = 0且95%数据满足该条件）
用EXPLAIN确认是否真正走索引
别凭经验或表结构“觉得”走了索引。每次上线前必须对UPDATE/DELETE语句跑EXPLAIN，重点看三列：
-
type：必须是const、eq_ref、ref、range；若为ALL或index，即已全表扫描 -
key：显示实际使用的索引名，为空或PRIMARY但不符合预期，则可能索引失效 -
rows：预估扫描行数，若远大于目标行数（如查1行却扫10万行），大概率锁范围失控
示例：EXPLAIN UPDATE order SET status=1 WHERE order_no='O123456'; 若key为NULL，说明order_no未建索引或索引失效，必须先建UNIQUE INDEX idx_order_no(order_no)。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
避免锁表的实操底线
这些不是“建议”，是生产环境必须遵守的硬约束：
- 禁止任何UPDATE/DELETE语句不带WHERE条件——
UPDATE t SET c=1;直接锁全表 - WHERE字段必须有有效索引，且不能对它做函数、运算、类型转换
- 批量更新必须按主键范围切分，例如
UPDATE t SET status=1 WHERE id BETWEEN 10000 AND 19999;；LIMIT在UPDATE中不减少锁范围 - 高并发写场景优先设为
READ COMMITTED隔离级别——它禁用间隙锁，锁更轻、死锁更少，且互联网业务通常可接受“不可重复读”
最易被忽略的一点：即使加了索引，如果查询条件区分度极低（如WHERE gender = 'M'），优化器仍可能放弃索引。此时应结合业务逻辑改用覆盖索引或拆分条件，而不是硬扛。
