昨天我参加了一个用户组会议,他们指出使用参数化查询比编码查询更好。这让我思考,这有什么好处(显然比这更大):
DECLARE @Client1 UNIQUEIDENTIFIER,
@Client2 UNIQUEIDENTIFIER
SET @ClientId1 ='41234532-2342-3456-3456-123434543212';
SET @ClientId2 = '12323454-3432-3234-5334-265456787654';
SELECT ClientName
FROM dbo.tblclient
WHERE id IN (@Client1,@Client2)
相反:
SELECT ClientName
FROM dbo.tblclient
WHERE id IN ('41234532-2342-3456-3456-123434543212','12323454-3432-3234-5334-265456787654')
答案 0 :(得分:4)
如果您的IN
列表不时发生变化,参数化查询和IN
子句实际上并不是一致的。
阅读这个问题和答案:Parameterize an SQL IN clause
按设计,参数只是一个值。除此之外的其他所有内容都必须手动实施,并考虑到安全问题,例如SQL Injection。
从性能角度来看,参数化查询的性能会更好,特别是如果重复运行相同的查询但具有不同的参数值。但是,如果您有一个动态IN
列表(有时是2个项目,有时是3个项目),您可能无法使用参数化查询。
IN
子句)。但是,这又不是微不足道的。
答案 1 :(得分:1)
它不应该受到伤害,但是当您使用由用户输入生成的查询时,您将从预准备语句中获得最大效果。如果他们点击一个按钮来“全部显示”,那就不是什么大问题了;但是,如果您提示用户输入其名称,则在插入/更新/选择/ etc之前,您需要对输入进行参数化。
例如,如果我输入我的名字为“Mike DROP TABLE MASTER”;“或者你的数据库中有一个大表名,这对你来说真的很难看。比抱歉更安全,对吧?
编辑:OP在这里评论并提出问题。更新了代码示例。public int myNum;
SqlParameter spNum=new SqlParameter("@myNum", SqlDbType.Int);
//you can also check for null here (but not really relevant in this case)
command.Parameters.Add(spNum);
string sql="INSERT INTO Table(myNum)";
sql+=" VALUES(@myNum)";
command.CommandText = sql;
int resultsCt = command.ExecuteNonQuery();
在使用数据库进行任何操作之前,请查看代码如何强制输入为整数?这样,如果任何人尝试任何恶作剧,它就会被拒绝,直到它对数据库造成伤害。
答案 2 :(得分:1)
在具有许多连接的大型数据库和复杂查询上,数据库可以使用时间来构建执行计划。使用参数化查询时,执行计划在使用不同参数多次调用查询时保留在数据库缓存中一段时间