直接结论：优先改写查询逻辑，用分批主键范围查+精准IN替代单次大JOIN。因数据库JOIN性能取决于算法选择与索引，而非单纯调大内存参数；分批需满足主键单调、每批≤1000、避免字符串拼接，并验证索引与执行计划。
直接结论：别硬调内存参数，优先改写查询逻辑——用分批主键范围查 + 精准 IN 替代单次大 JOIN，这是最可控、副作用最小的解法。
为什么调 work_mem 或 join_buffer_size 常常无效
数据库执行 JOIN 时，并不是“内存不够才慢”，而是算法选择本身决定了内存消耗模式。比如 PostgreSQL 默认倾向 HASH JOIN，必须把整个右表载入内存；MySQL 在无索引时启用 Block Nested-Loop Join，靠 join_buffer_size 缓冲，但该缓冲只对无索引场景生效。
- 如果
EXPLAIN里没出现Using join buffer（MySQL）或Hash行里带disk（PostgreSQL），说明问题不在缓冲大小，而在索引缺失或驱动表选错 -
work_mem设太高会直接拖垮并发能力：100 个连接 × 256MB = 25GB，机器可能开始 swap - SQL Server 的
HASH JOIN内存估算依赖统计信息，过期统计会导致优化器误判，调内存也救不了 - MySQL 8.0.22+ 默认启用
hash_join，此时join_buffer_size完全不参与，调了也没用
分批查询怎么写才不踩坑
核心是把“一次全量匹配”拆成“多次小范围拉取”，但必须满足前提、控制边界、避免新瓶颈。
- 左表要有单调主键（如
id BIGINT PRIMARY KEY AUTO_INCREMENT）或时间字段（如created_at），否则无法安全分段 - 每批
IN列表长度建议 ≤ 1000 —— MySQL 默认max_allowed_packet=4MB，2000 个 INT 就超限；PostgreSQL 对VALUES构造也有解析开销 - 禁止应用层字符串拼接长
IN：Python 应用用executemany()，Java 用PreparedStatement批量绑定 - PostgreSQL 推荐用
VALUES子句代替裸IN：WHERE o.user_id IN (SELECT id FROM (VALUES (1),(2),...,(1000)) AS v(id)) - MySQL 8.0+ 可建临时表：
CREATE TEMPORARY TABLE tmp_ids(id BIGINT); INSERT INTO tmp_ids VALUES (...); SELECT ... JOIN tmp_ids ON ...
索引和执行计划必须同步验证
分批能跑通，不代表性能好。真正卡住的往往是隐性扫描——你以为走了索引，其实没生效。
- 检查
EXPLAIN中type是否为ref或eq_ref（MySQL）、Index Scan（PostgreSQL），而不是ALL或Seq Scan - JOIN 字段类型必须严格一致：
INT对BIGINT、VARCHAR(50)对VARCHAR(100)都会触发隐式转换，索引失效 - 复合索引顺序要匹配 JOIN 条件：若写
JOIN t1 ON t1.a = t2.a AND t1.b = t2.b，t1 上索引必须是(a,b)，不是(b,a) - 宽字段（如
TEXT、多个VARCHAR(2000)）会让单行内存占用翻倍，分批时得按字节估算，不能只看行数
最容易被忽略的是：分批后仍用 SELECT * 或跨表重复字段，会让每次查询实际加载的数据量远超预期。哪怕只分 1000 行，若每行含 3 个 TEXT 字段，内存压力依然可观。动手前先确认你真正需要哪些字段。
