应改写为join连接：将where id in (select...)替换为inner join或left join ... where ... is not null，并确保join条件字段有索引，避免dependent subquery导致外层每行重复执行子查询。
相关子查询被反复执行，怎么停住它
外层扫描 10 万行，子查询就真跑 10 万次——这不是错觉，是 MySQL/PostgreSQL 默认行为。只要子查询里引用了外层字段（比如 WHERE o.user_id = u.id），它就是相关子查询，优化器无法物化，只能逐行探查。
- 用
EXPLAIN看执行计划，如果出现DEPENDENT SUBQUERY，基本确认在重复执行 - 立刻改写为
JOIN：把WHERE id IN (SELECT ...)拆成显式INNER JOIN或LEFT JOIN ... WHERE ... IS NOT NULL - 别信“加索引就能救”：即使
user_id有索引，相关子查询仍可能因驱动顺序错误而全表扫内表；先确保JOIN条件走索引，再看EXPLAIN的type是否为ref或eq_ref
IN (SELECT ...) 内存爆了，换什么写法
WHERE id IN (SELECT id FROM huge_table WHERE status = 'active') 在 MySQL 5.7 或 PG 12 下极易触发临时表膨胀，尤其当子查询返回超 10 万行时，内存直接打满。
宝塔Linux面板11.3.0
下载
宝塔面板11.3.0是一款针对Linux服务器设计的可视化管理工具，通过重构核心模块实现资源占用显著降低，尤其适合低配置服务器环境。它将复杂的命令行操作转化为直观的图形界面，帮助开发者快速完成网站部署、环境配置及日常运维工作，无需专业技术背景即可高效管理服务器。
- 优先改成
JOIN：MySQL 对IN (subquery)的物化策略不智能，但对JOIN能走流式关联 + 索引下推 - 只查必要字段：子查询里别写
SELECT *，只取SELECT user_id这类关联键，减少物化行大小 - PostgreSQL 用户注意：
EXISTS更稳，但必须带关联条件（WHERE o.user_id = u.id），否则退化为半连接，照样全加载 - MySQL 大表场景下，手动分页驱动比硬扛更可靠：用
SELECT id FROM huge_table WHERE status = 'active' ORDER BY id LIMIT 1000 OFFSET 0拆批处理
WITH 子句真能提速？什么时候会翻车
WITH 不是性能银弹，它只是逻辑重写。PostgreSQL 默认不物化中间结果，MySQL 8.0+ 对 MATERIALIZED 支持有限，盲目套用反而掩盖真实瓶颈。
- 想靠
WITH提速，先看执行计划：对比EXPLAIN ANALYZE中Actual Total Time和Rows Removed by Filter是否下降 - 别在
WITH里写ORDER BY或LIMIT（除非做分页），它们对中间结果无意义，还可能干扰优化器裁剪 - 多个
WITH子句之间引用必须按定义顺序，后定义的可以引用前一个，反向引用直接报错 - 最隐蔽的坑：字段名没显式声明，
SELECT *引用时列顺序错乱，跨库迁移（PG → MySQL）时突然崩
临时表不是懒人方案，而是可控开关
当子查询逻辑稳定、复用率高（比如“VIP 用户列表”每天只算一次），手动物化成临时表，比依赖优化器自动物化靠谱得多。
- 用
CREATE TEMPORARY TABLE AS SELECT ...或CREATE TABLE AS SELECT ...显式落地，再加索引 - 临时表记得建联合索引：比如按
(status, created_at)查询，就建INDEX idx_status_created ON temp_vip (status, created_at) - MySQL 注意
join_buffer_size实际值：用SHOW VARIABLES LIKE 'join_buffer_size'查，默认常是 256KB，远不够大表关联 - 别在事务里长期持有临时表：云数据库连接池回收可能失败，导致表残留或锁等待
WHERE 里显式出现，分区就形同虚设；比如 EXISTS 子查询里漏了 AND o.created_at > '2024-01-01'，哪怕外层有日期过滤，内层仍扫全表。
