pandas.merge(..., how='left') 是标准左连接，需显式指定 on 或 left_on/right_on，否则报错；左表重复键会复制右表匹配行，NaN 表示无匹配，连接前应确保键类型一致、无空值且值对齐。
merge 用 how='left' 就是标准左连接，但必须确保 on 或 left_on/right_on 对齐
Python 的 pandas.merge() 调用 how='left' 确实对应 SQL 的 LEFT JOIN，但它不会自动猜字段名。如果你没显式指定连接键，会报 MergeError: No common columns to perform merge on。
常见做法是：
- 两表有同名列（如都叫
'id'）：直接用on='id' - 列名不同（如左表叫
'user_id'，右表叫'uid'）：必须写left_on='user_id', right_on='uid' - 按多列连接（如
['date', 'region']）：on接列表，不能传字符串
漏掉 on 参数是最常见的“调了 left 却报错”原因。
左表重复 key 会导致右表行被复制，不是 bug 是预期行为
如果左表的连接键存在重复值（比如同一个 'order_id' 出现 3 次），而右表只有一条匹配记录，merge 会把那条右表记录复制 3 行，拼到左表对应位置。这不是数据错误，而是 LEFT JOIN 的语义本身如此。
立即学习“Python免费学习笔记（深入）”；
验证是否发生这种情况：
- 检查左表：
df_left['key'].duplicated().sum() - 检查右表：
df_right['key'].duplicated().any()（右表重复 key 会导致笛卡尔积膨胀）
若需去重后再连，先对右表做 drop_duplicates(subset=['key'])，但得确认业务上是否允许丢弃重复。
how='left' 和 how='inner' 性能几乎没差别，但内存占用可能翻倍
连接方式本身不显著影响计算速度，pandas 底层都是哈希连接。真正影响性能的是结果集大小：左连接保留左表全部行，即使右表无匹配也会补 NaN。这意味着最终 DataFrame 行数 = 左表行数，列数 = 左表列 + 右表非连接键列。
容易被忽略的点：
- 右表如果有大量列但只用其中 2 列，先用
df_right[['key', 'value']]筛选再 merge，省内存 - 连接键类型不一致（如左表
int64，右表object存数字字符串）会强制类型转换、拖慢速度，且可能隐式转成float64引入精度问题 - 用
validate='m:1'可在运行时断言右表 key 唯一，避免意外膨胀
merge 后 NaN 出现在右表列里，说明左表某行没匹配上
这是左连接最核心的特征，也是调试关键线索。如果发现右表字段批量为 NaN，别急着改代码，先查三件事：
- 左表连接字段是否有空值？
df_left['key'].isna().sum()—— 空值永远无法匹配，必然产出NaN - 左右表连接字段值是否真的一致？比如右表是
'A001'，左表是'a001'（大小写）、或带空格（' A001 '） - 是否用了
suffixes=('_left', '_right')却忘了处理重名列？重名字段会被自动加后缀，但如果不注意，可能误以为某列“消失了”
连接逻辑本身很简单，难的是让两边的数据干净、对齐、类型一致 —— 这部分花的时间往往超过写 merge 那一行代码本身。
