在当今数据驱动的开发环境中，Python与PostgreSQL的组合已成为后端服务、数据分析及ETL管道的标配。作为最成熟的PostgreSQL适配器，psycopg2以其高性能和安全性广受开发者青睐。然而，许多新手在编写动态SQL查询时，常因忽视参数化查询而陷入SQL注入风险，尤其在多表连接（INNER JOIN）场景中，将外部变量安全地嵌入JOIN条件更是一道“技术门槛”。本文将结合实战案例，详解如何在psycopg2中使用变量执行内连接操作。

背景：为什么需要动态JOIN条件？

假设我们有两个表：users（用户）和orders（订单），业务需求是根据传入的用户ID列表，查询该用户的所有订单详情。此时SQL语句的INNER JOIN ... ON子句必须接收一个可变参数——用户ID。若直接使用字符串拼接，如f"SELECT * FROM orders INNER JOIN users ON orders.user_id = users.id WHERE users.id = {user_id}"，不仅存在SQL注入风险，还可能在PostgreSQL的语法检查中因类型不匹配而报错。psycopg2内置的参数化机制正是解决这一痛点的利器。

核心方法：使用占位符和execute()传参

psycopg2支持两种占位符风格：%s（位置参数）和%(name)s（命名参数）。在INNER JOIN中，变量可以出现在ON子句、WHERE子句甚至SELECT字段中。以下是一个典型示例：

import psycopg2

conn = psycopg2.connect(
    host="localhost",
    database="mydb",
    user="postgres",
    password="secret"
)
cur = conn.cursor()

# 使用%s占位符
user_id = 1024
sql = """
SELECT orders.id, orders.amount, users.name
FROM orders
INNER JOIN users ON orders.user_id = users.id
WHERE users.id = %s
"""
cur.execute(sql, (user_id,))
rows = cur.fetchall()

核心要点： - SQL字符串中的%s不表示Python的格式化，而是psycopg2的占位符。 - 第二个参数必须是一个元组（即使只有一个变量，也要写成(user_id,)）或列表。 - 驱动会自动处理变量转义和类型转换，避免注入。

进阶：多变量与命名参数

当JOIN条件涉及多个动态字段时，命名参数更直观。例如按用户ID和订单状态筛选：

sql = """
SELECT o.id, o.amount, u.name
FROM orders o
INNER JOIN users u ON o.user_id = u.id
WHERE u.id = %(user_id)s AND o.status = %(status)s
"""
cur.execute(sql, {"user_id": 2048, "status": "completed"})

命名参数使用%(name)s，传入一个字典即可。这种方式在处理复杂查询时显著提升代码可读性。

实战案例：批量查询与IN子句

有时需要同时查询多个用户的内连接数据，此时需配合IN子句。但注意：不能直接写成WHERE u.id IN (%s)然后将一个列表传入，因为psycopg2不会自动展开列表。正确做法是动态生成占位符列表：

user_ids = [101, 102, 205]
placeholders = ','.join(['%s'] * len(user_ids))
sql = f"""
SELECT o.id, o.amount, u.name
FROM orders o
INNER JOIN users u ON o.user_id = u.id
WHERE u.id IN ({placeholders})
"""
cur.execute(sql, user_ids)  # 传入列表即可

这里使用了Python的字符串格式化生成占位符，但传入的数据部分仍由psycopg2参数化处理，安全可靠。

避坑指南：常见错误

  1. 误用Python格式化：cur.execute(f"SELECT ... WHERE id = {user_id}") 直接拼接字符串，属于高危操作。
  2. 忘记传递参数：如果SQL中有占位符但execute()未提供第二个参数，会引发TypeError。
  3. 多语句执行：psycopg2默认禁止同时执行多条语句（execute()只处理第一条），若需批量插入请使用executemany()。
  4. 占位符数量不一致：若SQL中有3个%s，传入的元组必须正好有3个元素，否则会报错。

性能与安全：为何必须参数化？

除了防止SQL注入，参数化查询还能利用数据库的预编译计划缓存（Prepared Statement）。对于重复执行的同结构SQL，PostgreSQL会跳过解析和优化阶段，直接复用执行计划，显著提升性能。因此，即使变量值不来自用户输入，也推荐使用参数化方式。

结语

在psycopg2中执行带有变量的INNER JOIN，核心就是将变量作为独立参数传入execute()方法，而非拼接进SQL字符串。无论是单值、多值还是列表，只需掌握占位符的正确用法，即可实现安全、高效的动态查询。随着Python生态向数据密集型应用持续渗透，这一基础技能将成为每位开发者必备的数据库操作素养。建议读者在真实项目中坚持参数化查询，并定期审查代码中是否存在字符串拼接的“历史遗留问题”。

（本文示例基于psycopg2 2.9.9版本，PostgreSQL 15测试通过。）