mysql中避免大字段（text/blob）参与join可防止内存抖动，因其触发每行预分配大内存并易致tmp_table_size溢出落盘；应通过延迟关联、exists替代或拆分查询剥离大字段。
直接结论：不让大字段（TEXT、BLOB、VARCHAR(MAX)等）参与JOIN执行路径，就能避开内存抖动——它不是字段本身慢，而是数据库在JOIN阶段为每行预分配几MB内存空间，撑爆tmp_table_size后强制落盘。
为什么EXPLAIN里没选TEXT列却还是Using temporary？
数据库优化器只要看到JOIN表里定义了TEXT字段，就会按最大可能长度（比如65535字节甚至更大）为每一行预留内存，哪怕SELECT列表里完全没写它。MySQL 8.0+ 和 SQL Server 都会这样，尤其当该表是被驱动表时。
- 用
EXPLAIN FORMAT=JSON查看used_columns字段，确认实际加载的列；仅靠SELECT *的表别名推断不靠谱 - LEFT JOIN 中右表无匹配行时，仍为NULL行预留大字段空间，浪费更隐蔽
- 临时表落盘后出现
Using filesort或Using temporary; Using disk table就是典型信号
用延迟关联把大字段“踢出”JOIN阶段
核心是拆开“找ID”和“取内容”两个动作：先用轻量字段完成关联逻辑，再按需单点回查大字段。
- 第一层只选主键和筛选字段：
SELECT order_id, user_id FROM orders WHERE status = 'shipped' - 外层用这个结果集
JOIN原表补大字段：SELECT o1.order_id, o2.remark FROM light_orders o1 JOIN orders o2 ON o1.order_id = o2.order_id -
o2.order_id必须是主键或唯一索引，否则外层JOIN退化成全表扫描 - 避免在子查询里写
SELECT *，哪怕只是封装一层CTE，也会把TEXT拖进来
用EXISTS替代JOIN做条件过滤
当大字段只用于WHERE判断（比如“备注含紧急”），完全没必要JOIN出来——EXISTS不读取字段值，只判断存在性。
- 把
JOIN order o ON u.id = o.user_id AND o.remark LIKE '%紧急%'改成：WHERE EXISTS (SELECT 1 FROM order o WHERE o.user_id = u.id AND o.remark LIKE '%紧急%') - 如果字段上有全文索引，
MATCH(remark) AGAINST('紧急')比LIKE快一个数量级 - 注意：EXISTS不能返回remark内容，只适用于过滤场景；要取值必须走延迟关联或单独查
- SQL Server中若用
CONTAINS，需确保列已启用全文目录且状态为active
分批JOIN时怎么避免IN列表超长触发max_allowed_packet？
批量ID传入时拼长IN列表是常见翻车点，尤其当批次超过5000个ID时，MySQL容易报错或退化成全表扫描。
- Java用
PreparedStatement批量绑定参数，别字符串拼接 - Python psycopg2 用
executemany()，PostgreSQL推荐VALUES构造：WHERE o.user_id IN (SELECT id FROM (VALUES (1),(2),...,(5000)) AS v(id)) - MySQL 8.0+ 可建临时表存ID：
CREATE TEMPORARY TABLE tmp_ids(id BIGINT PRIMARY KEY); INSERT INTO tmp_ids VALUES (...); SELECT ... JOIN tmp_ids ... - 临时表必须加主键或索引，否则JOIN时变成ALL扫描
最容易被忽略的是：即使你写了 SELECT u.id, u.name，只要 JOIN 的右表含TEXT字段，且没做任何剥离，优化器仍可能把它拖进中间结果集——得靠 EXPLAIN FORMAT=JSON 看 used_columns 才能真正确认。
