删除操作与索引的基本关系
删除语句的执行路径概览
在 MySQL 中，删除数据的执行路径通常包含两阶段：定位目标行与执行实际删除。若 WHERE 条件可以被现有索引覆盖，执行计划倾向于通过索引来定位候选行，从而避免扫描整张表。若条件无法被索引支持，系统可能走全表扫描，带来更高的 I/O 和锁开销。理解这一点对于优化删除性能至关重要。
对 InnoDB 存储引擎而言，删除一个行通常需要先定位到该行在聚簇索引中的位置，然后再执行删除操作。因此，索引的存在与选择会直接影响删除的定位成本，并间接影响整体吞吐量。为了快速判断，通常通过执行计划（EXPLAIN）的输出来判断是否走了索引以及走的是哪一个索引。执行计划是判断删除是否使用索引的核心工具。
联合索引的左前缀匹配原则
当表中存在一个联合索引（例如列 a,b,c），若 WHERE 条件包含 a，或同时包含 a 与 b，那么该联合索引通常能够被用于定位要删除的行；这就是所说的左前缀匹配。只有满足左前缀规则，MySQL 才能充分利用该联合索引来提升删除语句的性能。
相反，如果 WHERE 条件仅涉及未覆盖在左前缀上的列（例如仅使用 c），那么联合索引的作用会显著下降，可能导致 索引失效、回表增加或直接进行全表扫描，从而降低删除的效率。为确保删操作能用上索引，往往需要将过滤条件按左前缀顺序组织好。左前缀原则是设计联合索引时的关键要点。
通过执行计划判断删除是否使用了索引
执行计划的关键字段
执行计划（EXPLAIN）输出中包含若干字段，其中 type、key、rows、Extra 是判断删除是否走索引的核心依据。type 表示访问类型，如 ALL、index、range、ref、eq_ref 等；key 表示实际使用的索引；rows 表示估计扫描的行数，这些信息共同指示了是否通过索引定位行以及扫描的成本。
另外一个重要点是在 Extra 字段中看到的提示，如 Using where、Using index 等信息。Using where 说明条件在读取阶段需要额外筛选；Using index 常指索引覆盖或索引层面的数据定位，能减少回表操作的需要。>对于删除语句，这些标记可以帮助判断是否沿用索引以及是否可能回表。理解这些标记是判断删除是否走索引的实际方法。
具体操作步骤与解读要点
要判断删除是否走索引，可以按以下步骤进行：对 DELETE 语句执行 EXPLAIN，并关注关键字段的变化。
步骤要点包括：首先查看 key 字段是否为 null；若不为 null，表示确实有使用某个索引。其次查看 type 字段的取值，若为 range、ref、eq_ref，通常表示利用了索引；若为 ALL，表示全表扫描。最后注意 Extra 字段中的 Using where、Using index 等提示，帮助判断是否存在覆盖或额外筛选开销。
EXPLAIN DELETE FROM orders WHERE user_id = 123 AND status = 'PENDING';id: 1
select_type: SIMPLE
table: orders
type: range
possible_keys: idx_user_status, PRIMARY
key: idx_user_status
key_len: 8
ref: const
rows: 2
Extra: Using where
以上示例中，type 为 range，key 使用了联合索引 idx_user_status，并且 Extra 显示 Using where，表明删除操作确实通过索引定位到候选行并执行过滤。这是判断删除走索引的直接证据。
联合索引在删除中的作用与注意点
左前缀匹配在删除条件中的实际效果
在有联合索引的场景中，若 WHERE 条件符合左前缀条件（如 a，或 a 与 b），索引可被用于定位删除目标，从而减少全表扫描的成本。若条件不满足左前缀，索引的作用可能会降低，甚至可能不被使用，导致需要进行全表扫描或回表操作。
因此，在设计带有删除条件的查询时，优先将过滤条件放在联合索引的前列，并尽量匹配左前缀。这也是提升删除性能、降低锁粒度的常用做法。左前缀设计原则直接决定了删除操作的执行计划。
覆盖索引与回表的影响
所谓覆盖索引，指查询只需要从索引本身即可获取需要的数据，不需要回到主表读取数据。对于删除语句，覆盖索引可以在某些情况下减少回表开销，提升删除效率；不过在 InnoDB 中，实际删除仍需对聚簇索引中的行进行修改，因此不会完全摆脱对主表的访问。覆盖索引有助于减少额外的 I/O，在适合的场景下能带来显著收益。
在分析执行计划时，若看到 Using index 出现在 Extra 字段，通常意味着已经通过索引完成了定位并可能减少了回表；若没有，则可能意味着需要进一步回表来定位具体行或执行删除。要点在于理解回表成本与索引覆盖的实际影响。
实例演示：从创建表到执行计划的完整流程
搭建一个可复现的示例表
下面给出一个简化的示例表，包含一个联合索引，用来演示删除操作对执行计划的影响。通过这个例子可以直观地看到如何通过 EXPLAIN 判断删除是否走索引。实际操作时应以自己的数据结构为准。
CREATE TABLE orders (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
user_id INT NOT NULL,
status VARCHAR(20) NOT NULL,
created_at DATETIME NOT NULL,
amount DECIMAL(10,2) NOT NULL,
INDEX idx_user_status (user_id, status)
) ENGINE=InnoDB;该表包含一个联合索引，用于覆盖常见的删除条件，例如按 user_id 和 status 过滤的场景。
执行 DELETE 的执行计划输出示例
在具有上述联合索引的表上执行删除时，可以通过如下方式获取执行计划，以判断是否走索引。请将实际环境中的 SQL 替换成示例中的语句。
EXPLAIN DELETE FROM orders WHERE user_id = 42 AND status = 'PENDING';id: 1
select_type: SIMPLE
table: orders
type: range
possible_keys: idx_user_status
key: idx_user_status
key_len: 8
ref: const
rows: 2
Extra: Using where
从输出可以看出：type 为 range、key 使用了 idx_user_status，以及 Extra 含有 Using where，这些都指示了删除操作确实通过联合索引定位并进行条件筛选。这是判断删除是否走索引的直接依据。
基于执行计划的优化建议（不含总结与建议性结论
如果 EXPLAIN 显示 key 为 null，意味着当前 DELETE 语句没有使用任何索引，应该考虑修改 WHERE 条件、添加或调整索引、以及检视 LEFT 前缀是否匹配。若 type 为 ALL，表明是全表扫描，应优先考虑创建或调整联合索引，以便让左前缀匹配生效，从而提升删除效率。结合实际执行计划进行优化，通常能显著降低删除语句的成本。
实际操作示例回顾
通过以上示例，可以看到在合适的条件下，删除语句确实可以借助联合索引完成定位，减少全表扫描带来的成本，并且执行计划中出现的 Using where 与 range、ref 等标记，直观反映了索引的实际作用。
总结性观察与常见误区（与标题相关的要点再次强调）
常见错误认知与避免方式
很多人误以为删除一定会走索引，实际上只有在 WHERE 条件能够与现有索引前缀匹配时才会发生。没有左前缀匹配的联合索引在删除中的效用有限，这也是为何设计联合索引时要特别关注左前缀顺序。通过执行计划验证是最可靠的方法。
另一个常见点在于覆盖索引的理解。虽有覆盖索引时可减少回表，但在 InnoDB 的删除中，实际行更新仍然需要对聚簇索引做修改，因此“覆盖”更多体现为减少回表带来的额外 I/O，而非完全消除对主表的访问。理解覆盖的边界有助于准确评估成本。
