left join 多对一结果行数变多，是因为“一”侧表存在重复数据或连接条件不完整，导致“一”被多次匹配；应检查“一”侧主键唯一性及补充生效时间等过滤条件。
用 LEFT JOIN 处理多对一查询时，为什么结果行数变多了？
多对一本身不会导致结果膨胀，但如果你在「一对」侧（比如 dept 表）有重复数据，或连接条件没写全（漏了时间、状态等过滤字段），就容易让「一」侧被多次匹配，最终查出远超预期的行数。常见于日志类表和维度表关联时，维度表未去重或未加生效时间约束。
实操建议：
- 先确认「一」侧表（如
dept）主键是否真正唯一：SELECT dept_id, COUNT(*) FROM dept GROUP BY dept_id HAVING COUNT(*) > 1 - 检查连接条件是否完整：比如
emp.dept_id = dept.id是基础，但如果dept有历史快照，还需加上AND dept.effective_date - 若无法清理源数据，可在子查询中提前去重：
LEFT JOIN (SELECT DISTINCT id, name FROM dept) d ON e.dept_id = d.id
MyBatis 中 association 和分步查询哪种更适合多对一？
association 是标准解法，但前提是能写出高效联表 SQL；分步查询（N+1）看似简单，实际在高并发或大数据量下极易拖垮数据库。
实操建议：
- 优先用
association+ 显式LEFT JOIN，并确保ON条件中的外键列（如emp.dept_id）已建索引 - 避免在
association的select属性里写带ORDER BY或LIMIT的子查询，这会强制为每条主记录单独执行一次 - 如果必须用分步查询，至少开启 MyBatis 的
lazyLoadingEnabled=true，并配合aggressiveLazyLoading=false控制加载时机
SQL Server 里 LEFT JOIN 比 INNER JOIN 慢很多，怎么调？
LEFT JOIN 本身不慢，慢是因为优化器无法有效利用索引做外连接驱动，尤其当「左表」大、「右表」小且无合适索引时，容易退化成嵌套循环扫描。
实操建议：
- 确保右表（「一」侧）的连接字段（如
dept.id）是主键或有唯一索引；非唯一时加OPTION (HASH JOIN)强制改用哈希连接 - 把过滤条件尽量下推到右表子查询中：
LEFT JOIN (SELECT id, name FROM dept WHERE status = 'active') d ON ... - 禁用「连接消除」干扰：SQL Server 可能因外键约束自动改写 LEFT JOIN 为 INNER JOIN，若业务逻辑依赖 NULL 值，需显式加
WHERE d.id IS NULL OR d.status = 'active'阻断优化
一对多反向查多对一时，GROUP BY 容易漏字段
比如从 orders 查每个订单的客户信息（customers），本是多对一，但若误用 GROUP BY order_id 却没把 customer.name 加进 SELECT 或 GROUP BY，SQL Server 或 MySQL 8.0+ 会直接报错：Column 'customer.name' is invalid in the select list。
实操建议：
- 明确「一」侧字段是否函数依赖于分组键：如果
order.customer_id是主键，那customer.name就可安全出现在SELECT中而无需GROUP BY—— 但得关掉ONLY_FULL_GROUP_BY模式才允许 - 更稳妥的做法是用
MAX(customer.name)或STRING_AGG包裹，避免模式差异引发兼容问题 - 别指望
DISTINCT能替代GROUP BY：它只去重整行，无法聚合关联字段
