merge时on与left_on/right_on混用易出错，必须根据字段名一致性选择参数；多字段关联需等长列表一一对应；how='outer'配合indicator=True可识别匹配状态；merge默认丢失索引，需显式处理；重复键导致笛卡尔积需提前去重或改用map。
merge 时 on 参数和 left_on/right_on 混用容易出错
当左右表的关联字段名不一致（比如 user_id 和 uid），不能只靠 on，必须拆成 left_on 和 right_on。否则会报 KeyError: 'xxx'，或者静默返回空结果——因为 pandas 默认在两边都找同名列。
实操建议：
- 先用
df1.columns和df2.columns确认字段名，别凭印象写 - 如果一边是索引、一边是普通列，用
left_index=True+right_on='col_name'，别强行reset_index() - 多字段关联时，
left_on和right_on必须是等长列表，顺序一一对应，比如left_on=['region', 'year']对应right_on=['area', 'yr']
how='outer' 与 indicator=True 配合查缺失关联
数据库里常用 FULL OUTER JOIN 查“哪些记录在左表有但右表没匹配上”，pandas 的 how='outer' 能做到，但默认不告诉你每行来自哪边。加 indicator=True 后会生成一列 _merge，值为 both/left_only/right_only。
常见误用：
立即学习“Python免费学习笔记（深入）”；
- 忘了设
indicator=True，只能靠人工比对 NaN 判断来源，极易漏判 -
_merge列类型是category，排序或过滤时最好先转成字符串：merged[merged['_merge'] == 'left_only'] - 如果后续要 drop 掉 indicator 列，别用
drop('_merge', axis=1)—— 它可能被重命名过，稳妥做法是merged.drop(columns=['_merge'], errors='ignore')
merge 后索引丢失或重复导致 loc 失效
pandas 的 merge 默认不保留任何一方的索引，结果 DataFrame 的索引是整数递增的 RangeIndex。如果你原来靠索引做快速定位（比如 df.loc['id123']），merge 后这个操作会失效或报 KeyError。
解决路径分情况：
- 若需保留左表索引：加
left_index=True且确保right_on指向右表某列（不是索引） - 若两表都按业务主键索引，且想让结果也以该主键为索引：merge 完立即
set_index('key_col')，别依赖 merge 自动推断 - 避免索引污染：merge 前检查是否有重复值——
df1.index.duplicated().any()，重复索引 merge 后会爆炸式膨胀行数
大数据量下 merge 性能卡在笛卡尔积陷阱
当某侧关联列存在大量重复值（比如订单表 join 用户表，但用户表里一个 user_id 出现 1000 次），merge 会隐式做笛卡尔积，内存暴涨、耗时陡增。这不是 bug，是 SQL 中也存在的经典问题。
提速关键动作：
- 提前去重：若语义允许（如只需用户基础信息），对右表先
drop_duplicates(subset=['user_id']) - 换策略：对超大表，考虑用
map替代 merge ——df1['city'] = df1['user_id'].map(df2.set_index('uid')['city'])，快且省内存 - 验证重复度：merge 前跑
df2.groupby('join_col').size().describe()，如果max> 100，就得警惕
真正麻烦的不是语法写不对，而是 merge 后数据量翻了几倍却没意识到——尤其当原始 CSV 看不出重复时，得靠 len(result) / (len(left) * len(right)) 这个比值来嗅探异常。
