派生表在mysql 5.7中并不天然易维护，反而因强制物化、无索引、explain信息不透明及调试困难而降低可维护性；其“模块化”假象常掩盖性能问题与执行逻辑不可预测性。
派生表本身并不天然更易维护——反而是多数场景下更难维护，尤其在 MySQL 5.7 及更早版本中。 它常被误认为“结构清晰”，但实际容易掩盖性能问题、破坏索引、导致执行计划失控。真正影响可维护性的不是语法形式，而是执行逻辑是否透明、是否可预测。
派生表让 EXPLAIN 看不出真实瓶颈
当你写 FROM (SELECT ... FROM t1 WHERE x = ? GROUP BY y) AS dt，MySQL 5.7 默认强制物化这个子查询，生成无索引临时表。EXPLAIN 中只会显示 type: ALL 和 Extra: Using temporary，但你根本看不到内层 WHERE 是否走索引、GROUP BY 是否触发 filesort——这些全被封装进“派生表”黑盒里了。
- 调试时无法单独执行派生表部分（比如加
EXPLAIN或LIMIT 10），必须整个重写成独立语句 - 修改外层
JOIN条件时，优化器可能放弃合并派生表，但你从 SQL 表面完全看不出这种退化 - 一旦派生表含
DISTINCT、UNION或聚合函数，MySQL 8.0 的derived_merge也会自动关闭，而你得靠EXPLAIN FORMAT=TREE才能确认
嵌套子查询反而更容易定位和拆解
比如 SELECT id, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) AS order_cnt FROM users u，每个子查询都明确绑定外层字段，执行路径是线性的：先查 users，对每行调用一次子查询。虽然相关子查询有性能风险，但它的好处是：
- 你可以直接把子查询部分复制出来，替换
u.id为具体值（如WHERE o.user_id = 123），立刻验证逻辑和索引效果 - EXPLAIN 显示
DEPENDENT SUBQUERY，一眼知道它会逐行执行，不会误判为“一次性计算” - 当需要提取中间结果时，只需把子查询拎出来建临时表或 CTE，改造路径清晰（例如改写为
WITH user_orders AS (...) SELECT ...）
所谓“易维护”其实是幻觉：依赖的是人脑补逻辑，而非数据库行为
很多人觉得派生表“像视图一样结构分明”，但视图可重用、可授权、可缓存元数据；派生表只是语法糖，每次执行都重新解析、物化、丢弃。它带来的“模块化”假象，往往导致：
- 把本该加在内层的
WHERE条件错误地挪到外层JOIN后过滤，造成全量物化 - 以为给派生表别名（如
AS stats）就等于封装了业务含义，结果发现stats里没索引、没统计信息、ORDER BY 失效 - 团队新人看到
FROM (SELECT ...) AS a JOIN (SELECT ...) AS b，第一反应是“两个表关联”，却不知道这两个“表”根本没走任何索引
真正值得投入维护成本的地方，是让每一层查询的执行意图可观察、可隔离、可验证。派生表在绝大多数 OLTP 场景下，既不加速也不简化——它只是把问题藏得更深了一点。
