直接拼接字符串会导致SQL注入，因PyMySQL不自动转义用户输入，f-string或%格式化拼接会使恶意输入（如' OR '1'='1）破坏查询逻辑；必须用%s占位符配合独立参数传入。
为什么直接拼接字符串会导致SQL注入
因为用户输入的内容如果未经处理就直接插入到 SQL 语句中，攻击者可以构造恶意输入（比如 ' OR '1'='1），让查询逻辑失控。PyMySQL 本身不自动过滤或转义字符串，cursor.execute() 如果用 %s 占位符以外的方式传参（例如用 Python 的 f-string 或 .format() 拼接），就等于把信任交给了用户输入。
必须用参数化查询：只允许 %s 占位符 + 参数元组/字典
PyMySQL 只识别 %s 作为安全占位符（注意：不是 ?，也不是 :name），且参数必须以单独的第二个参数传入，不能拼进 SQL 字符串里。
- ✅ 正确：
cursor.execute("SELECT * FROM users WHERE name = %s", (user_input,)) - ❌ 错误：
cursor.execute(f"SELECT * FROM users WHERE name = '{user_input}'") - ❌ 错误：
cursor.execute("SELECT * FROM users WHERE name = %s" % user_input) - ⚠️ 注意：
%s是 PyMySQL 的占位符语法，和 Python 字符串格式化无关；即使user_input是数字、None 或含单引号，PyMySQL 也会内部做类型适配与转义
批量插入时仍需统一使用参数化，别用字符串拼接 values
常见误区是以为“只拼接 values 部分没关系”，比如手动拼出 (%s,%s),(%s,%s) 然后用 .execute() 执行——这仍然危险，因为拼接逻辑可能被绕过，且 PyMySQL 对这种写法不保证参数绑定顺序或安全性。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- ✅ 推荐方式：用
executemany()，例如：cursor.executemany("INSERT INTO logs (msg, level) VALUES (%s, %s)", data_list) - ✅ 替代方式：若必须动态字段数，先生成固定结构的 SQL（如
"INSERT INTO t (a,b,c) VALUES (%s,%s,%s)"），再传对应长度的元组 - ❌ 避免：
"VALUES " + ",".join(["(%s,%s)"] * len(data))再用.execute(sql, flat_data)—— 这种混合拼接易出错，也不受 PyMySQL 参数化保护机制覆盖
其他容易被忽略的安全细节
参数化能防注入，但不解决所有问题。有些场景看似“没 SQL 拼接”，实则仍有风险。
立即学习“Python免费学习笔记（深入）”；
- 表名、列名、ORDER BY 字段不能用
%s占位——PyMySQL 不支持参数化标识符；必须白名单校验或正则严格匹配，例如：if not re.fullmatch(r"[a-zA-Z_][a-zA-Z0-9_]*", table_name): raise ValueError("Invalid table name") - 不要把用户输入用于构建
SET子句字段名，比如"UPDATE t SET {} = %s".format(user_col)—— 这属于标识符注入，%s在这里完全无效 - 开启
autocommit=False时，记得显式调用connection.commit()或rollback()，否则事务状态混乱可能掩盖异常，间接影响数据一致性判断
实际项目里最常踩的坑，不是不会写 %s，而是把参数化当成万能膏药，然后在表名、排序字段、动态条件组合这些地方偷偷拼接字符串。
