MySQL 升级后 DELETE 报 ERROR 1093：多套一层子查询仍可能被合并

删除或更新语句需要先从同一张表中挑出目标行，SQL 已经多套了一层 SELECT，升级 MySQL 后仍报 ERROR 1093: You can't specify target table ... for update in FROM clause。检查派生表是否被优化器合并：括号里的查询看起来独立，不代表执行时一定保留为独立结果。

这篇处理普通业务表作为写入目标、又在子查询中被读取的情况。MySQL 5.7 系列开始采用派生表合并优化后，旧写法可能暴露这一限制。下面的 NO_MERGE 写法按当前 MySQL 8.4 规则说明；其他版本、MariaDB 或 ORM 生成语句，需要先确认各自的语法和实际 SQL。

先看失败的完整语句

保存应用实际发出的 SQL、绑定参数与完整报错，而不只看代码里的查询对象。确认哪个表是 DELETE 或 UPDATE 的目标，子查询中是否读取它，以及外面的 SELECT 是否真的改变了结果。

用发生错误的连接读取当前版本和优化设置：

SELECT VERSION(), @@SESSION.optimizer_switch;

关注 derived_merge 是否启用。这个结果能说明当前会话允许派生表合并，但不能单独证明每个派生表都被合并。查询结构、提示和执行计划也会影响选择。

如果报的是 Can't reopen table，并且多次引用同一张显式 TEMPORARY 表，应按临时表重复引用限制处理。它与这里的 1093 不同，改派生表合并设置不能解除所有临时表限制。

外层 SELECT 可能没有形成隔离结果

派生表既可以合并进外部查询块，也可以物化为内部结果。合并后，原本隔了一层的目标表读取重新进入写入语句，可能触发 ER_UPDATE_TABLE_USED，也就是这类 1093。

继续添加没有其他作用的 SELECT 层，不保证阻止合并。先确认当前查询确实需要先形成候选集，再对这个候选集控制物化；不要只凭括号数量判断问题已经解决。

在 MySQL 8.4 中，可以针对派生表别名使用 NO_MERGE。下面是会修改数据的结构示例，假设 app_items 是普通表，id 为唯一标识，三个金额与数量列都存在；不能直接拿它代替自己的业务条件执行：

UPDATE /*+ NO_MERGE(candidates) */ app_items AS target,
       (SELECT id
        FROM app_items
        WHERE retail / wholesale >= 1.3 AND quantity < 100) AS candidates
SET target.retail = target.retail * 0.9
WHERE target.id = candidates.id;

提示中的 candidates 对应派生表别名，作用范围是当前查询块。迁移自己的语句时，要保持目标键、筛选条件和更新表达式的含义，不能只替换表名就认为候选集正确。ORM 若重写别名或剥掉提示，还需检查最终发送到数据库的 SQL。

该方式不需要在语句执行后恢复一个会话开关。不能由此推断物化一定更快：内部结果可能增加内存或磁盘开销，数据规模和索引仍需评估。

老版本方案要保留会话与结果语义

旧版本或现有框架不能使用相应提示时，可以评估在受控连接上暂时关闭 derived_merge。这样会影响这个连接后续的其他查询；连接池复用时，未恢复设置会把影响带给下一个请求。

采用会话方案前保存完整的原 optimizer_switch，限定到这一次任务，并在成功和异常路径都恢复原值。不要把一个局部查询问题直接改成全局 optimizer_switch，也不要仅把 derived_merge 重新设为 on，覆盖原本就关闭它的连接约定。

DISTINCT、聚合、GROUP BY、LIMIT 等结构也可能阻止合并，但它们通常会改变查询含义。为了绕过 1093 随意增加 LIMIT，会缩小候选集；增加 DISTINCT 也要确认去重符合业务规则。选择这些结构必须有结果语义上的理由，不能把一个碰巧不再报错的查询当作等价替换。

若读取的是视图，还需检查视图算法；受支持版本中的 ALGORITHM=TEMPTABLE 可以阻止相应视图合并。更改共享视图会影响其他调用者，应作为单独的结构变更评估，不能当作只对一个请求生效的开关。

修复检查应包括将被修改的行

先保留原 SQL 和应用版本，按表引擎及现有备份流程准备恢复条件。在隔离数据或受控窗口里，先用只读查询核对候选 id、数量和筛选边界，再验证修改语句。只读候选集是在那个读取时点看到的数据，并不自动冻结随后并发写入；一致性要求需要由事务、锁和业务流程明确保证。

成功标准是原场景不再报 1093，实际修改范围、更新值和业务结果都符合预期，同时连接设置没有泄漏给其他任务。查看计划时区分只解释计划与会实际执行语句的工具，不要为了诊断而对生产写操作使用执行分析。

回退时恢复原 SQL 或应用配置，撤销本次会话或视图变更。已经提交的数据修改不能靠恢复 SQL 文本撤销；需使用先前准备的数据恢复路径，并防止重复执行折扣、扣减等非幂等操作。