Python带变量字符串格式化：不同SQL构造方法的适用场景辨析

核心概念澄清 #

你看到的早期加号拼接写法，从底层逻辑上就是最纯粹的字符串拼接，没有任何特殊优化或者隐藏语义——Python中字符串类型的+运算符，作用就是将前后两个字符串首尾连接生成新的独立字符串，和日常把“你好”和“世界”拼成“你好世界”的逻辑完全一致。

这种写法本身不是完全没有适用场景：如果拼接的所有片段都是硬编码的固定文本，没有引入任何动态可变值，那用加号拼接没有任何问题。但一旦把它用在需要嵌入动态值的SQL构造场景下，就是典型的历史遗留坏实践，没有合理的生产使用价值。 #

老旧代码大量使用加号拼接的原因 #

这种写法的流行完全是历史路径依赖的结果：

• 它是Python发展早期最符合直觉的字符串拼接方式：早在2000年前后的Python教程、示例代码中，f-string（Python3.6版本才引入）、str.format（Python2.6版本才推出）都还没有普及，甚至很多开发者都不了解%格式化语法，从C、Shell等其他语言转过来的开发者，最先掌握的就是用+拼接字符串的方式，自然会把这种写法用到所有日常开发场景里。
• 示例代码里特意把单引号也放进拼接逻辑（'" + date + "'），纯粹是开发者为了让拼接出来的SQL符合语法要求做的临时处理：因为要让传入的日期值在SQL中被识别为字符串类型，手动给值前后补上单引号，完全是“手搓字面量”的笨办法。

为什么老旧脚本会把字符串拼接用在SQL查询构造上 #

这本质是早期开发认知不足留下的问题，和写法本身的合理性无关：

• 很多早期的数据库驱动文档、入门示例，根本没有提及参数化查询的用法，给出的演示代码全是先拼好完整SQL字符串再传给游标执行，新手照着写自然就把这个习惯延续了下来。
• 很多写这类老旧脚本的开发者本身没有数据库安全意识，只追求“快速跑通查询结果”，完全没意识到字符串拼接会带来两个核心问题：一是值中包含特殊字符（比如单引号）时会直接破坏原有SQL逻辑，甚至引发SQL注入风险；二是手动拼引号很容易出现类型不匹配的语法错误，比如日期字段是数值类型时，给值包上单引号会直接触发数据库报错。
• 还有部分流传很广的错误认知，认为参数化查询会降低数据库性能，导致部分开发者故意绕开参数化、选择手动拼接SQL。

几种常见SQL构造写法的差异 #

这里需要明确区分几个容易混淆的实践：

• 加号拼接、str.format、f-string这三种SQL构造方式，本质上没有安全维度的差异：三者都是把查询值直接替换、嵌入到SQL文本中，完成完整SQL语句的拼接，都没有把SQL语法结构和参数值做隔离，只是写法的整洁度不同，从安全角度都是需要被淘汰的反模式。
• 你日常使用的Sybase参数化查询，是从设计层面就避免了拼接风险的正确实践：它会把固定的SQL语法结构和动态的参数值分开发送给数据库引擎，数据库先对SQL结构做编译、生成执行计划，再把参数值安全填充到对应位置，从根本上避免了参数中的特殊字符篡改SQL逻辑的问题，同时还能帮助数据库复用执行计划，降低重复查询的性能开销。

内容的提问来源于stack exchange，提问作者SimonT