navicat 16 本身不防注入，仅当使用参数占位符（如 ? 或 :name）并配合参数面板输入时，才通过预编译与参数分离实现防注入；直接拼接字符串仍危险。
Navicat 16 本身不执行 SQL 注入，也不参与应用层的参数绑定逻辑；它只是把你在查询编辑器里写的语句原样发给数据库。所谓“防止 SQL 注入”，只在你主动使用参数占位符（如 ? 或 :name）并配合参数面板输入值时才生效——且仅限于 Navicat 自己的执行流程，不影响你复制粘贴到代码里的字符串拼接行为。
为什么 ? 和 :name 在 Navicat 中能防注入
Navicat 把参数值和 SQL 语句分开传给数据库驱动：语句结构先预编译，参数值作为独立数据传入。数据库服务器不会把 ? 替换后的值当 SQL 解析，而是当作纯数据处理。
- MySQL 连接下必须用
?（不能写:id或@id），否则 Navicat 不识别为参数，直接报错或当字面量处理 - Oracle/PostgreSQL 连接下支持
:name，但注意冒号后不能有空格：: user_id是无效的，:user_id才行 - SQL Server 连接下不支持
?占位符，只认命名参数@param，但 Navicat 16 对@param的识别不稳定——建议改用 ODBC 连接或直接切到 SSMS 测试 - 参数面板里填
' OR 1=1 --不会触发注入，因为 Navicat 不做字符串拼接，而是交给数据库按参数类型（如 VARCHAR）安全绑定
怎么验证参数化查询是否真起作用
最直接的方法是看 Navicat 底部状态栏或启用「查询日志」：如果看到类似 PREPARE stmt FROM 'SELECT * FROM users WHERE id = ?'; EXECUTE stmt USING @1; 的记录，说明走的是预编译路径；如果只显示 SELECT * FROM users WHERE id = 123，那就是字符串拼接，防注入失效。
- 开启查询日志：菜单栏「工具」→「选项」→「环境」→ 勾选「启用查询日志」，日志会输出到「日志」窗口
- 对比两种写法：
SELECT * FROM orders WHERE status = ? AND created_at > ?
vsSELECT * FROM orders WHERE status = 'shipped' AND created_at > '2025-01-01'
前者在日志里能看到两阶段执行，后者只有一条完整语句 - 故意输错参数类型（比如对 INT 字段填
abc），Navicat 会弹窗报错「参数类型不匹配」，而不是数据库返回 SQL 语法错误——这是参数分离的明确信号
参数化查询在 Navicat 里对性能的影响
预编译语句在数据库端会被缓存执行计划，重复执行同结构、不同参数的查询时，比每次解析新语句快。但 Navicat 本身不复用连接或语句句柄，每次点击「运行」都新建一次会话，所以性能提升有限，主要体现在数据库侧。
- 单次查询几乎看不出差异；连续执行 50 次同一参数化语句，平均耗时可能比拼接式低 8%~15%（取决于数据库负载和网络延迟）
- 若语句含子查询或 JOIN，且参数位置影响索引选择（如
WHERE create_time > ?vsWHERE create_time ），数据库可能生成不同执行计划，此时参数化反而导致计划缓存失效 - Navicat 的「自动提交」开关（默认开）会影响事务粒度，但和参数化无关；关掉它后手动 COMMIT，才能真实模拟应用中长事务场景下的参数复用效果
真正容易被忽略的是：Navicat 的参数化只保护你在它界面里执行的那一行操作。一旦你把带 ? 的语句复制出去，粘贴进 Python 的 pymysql.execute() 或 Go 的 db.Query()，就得确保目标驱动也支持并启用了参数绑定——否则 ? 只是普通字符，毫无防护力。
