我们都知道,参数化查询可以处理SQL注入,以及提高查询的效率,因为参数化查询会使MSSQL缓存查询的计划. 但是会出现一个问题:有的时候参数化查询比直接拼接sql字符串效率低好多,甚至是查询超时. 原因:原来是字符类型的不匹配造成的.如果代码没有为SqlParameter设置DbType,非字符串类型,比如tinyint,int等,系统可以自动推断出SqlDbType,但是string对应数据库的nvarchar varchar等若干类型,所以无法自动推断,默认为Nvarchar.如果数据库字段

这个问题困扰我好长时间了,使用SQLSERVER 事务探查器找到执行超时的SQL语句,参数查询都是通过执行exe sp_executesql 的存储过程调用,因为它能够分析并缓存查询计划,从而优化查询效率,但是现在反而很慢.本地调试没有问题,开始上线也没有问题,但是运行一个月左右有时候会出现超时现象: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is

执行同样的存储过程,调用同样的参数 在VS 中调用存储过程和传参后,到数据加载需要20秒或更多, 在SQL直接调用则不到一秒,同一个存储过程为什么有这么大的区别呢? 原因:存储过程计划失效的原因 产生原因:存储过程涉及到的对象表结构发生改变或数据量发生大的变化. 解决方案1: 1.重启数据库服务 2.执行exec sp_recompile @objname='存储过程名称' 3.重新执行一次存储过程 解决方案2: 使用 WITH RECOMPILE 每次运行都编译存储过程 对于不经常使用的SQL

在做一个数据删除的时候,条件需要用到关联其他表,用到子查询,但是查询的时候使用 别名 没有问题,但是删除就有语法错误,在网上查询后得到了完美解决: --查询出来需要删除的数据 select * from RubricInfo A where exists ( and A.SubjectID=B.SubjectID) -- 删除数据,使用别名的时候 delete A from RubricInfo A where exists ( and A.SubjectID=B.SubjectID)

参数化查询(Parameterized Query 或 Parameterized Statement)是指在设计与数据库链接并访问数据时,在需要填入数值或数据的地方,使用参数 (Parameter) 来给值,这个方法目前已被视为最有效可预防SQL注入攻击 (SQL Injection) 的攻击手法的防御方式. 数据库参数化规律:在参数化SQL中参数名的格式跟其在存储过程中生命存储过程参数一致,例如在Oracle中存储过程参数一律以”:”开头,在MS SQL Server中存储过程参数一律以”@

转载至: http://www.cnblogs.com/lzrabbit/archive/2012/04/21/2460978.html 错误认识1.不需要防止sql注入的地方无需参数化 参数化查询就是为了防止SQL注入用的,其它还有什么用途不知道.也不关心,原则上是能不用参数就不用参数,为啥?多麻烦,我只是做公司内部系统不用担心SQL注入风险,使用参数化查询不是给自己找麻烦,简简单单拼SQL,万事OK 错误认识2.参数化查询时是否指定参数类型.参数长度没什么区别 以前也一直都觉的加与不加参数长

说来惭愧,工作差不多4年了,直到前些日子被DBA找上门让我优化一个CPU占用很高的复杂SQL语句时,我才突然意识到了参数化查询的重要性. 相信有很多开发者和我一样对于参数化查询认识比较模糊,没有引起足够的重视 错误认识1.不需要防止sql注入的地方无需参数化 参数化查询就是为了防止SQL注入用的,其它还有什么用途不知道.也不关心,原则上是能不用参数就不用参数,为啥?多麻烦,我只是做公司内部系统不用担心SQL注入风险,使用参数化查询不是给自己找麻烦,简简单单拼SQL,万事OK 错误认识2.参数化查

1.问题的来源 在.NET或者C#中,我们一般执行sql语句的话,推荐使用参数化查询,这样可以避免sql注入的攻击,但是,我在使用参数化查询的时候 出现了以下的错误,详细如下图: 图一这是写sql语句参数化查询的代码 图2 这是MSSQL执行的sql语句 2.问题的原因   出现这种错误的原因在于,在参数化查询的时候,有几个参数的值为null,这样的话,就出现了如图2所示的错误. 为啥会这样了?? 虽然参数的值就是为null,传入数据库中就必须变成DbNull.Value因为此null为c#的,

在MySQL中,有一些语句即使逻辑相同,执行起来的性能差异确实极大的. 先抛出一个结论:如果想使用索引树搜索功能,就不能使用数据库函数来处理索引字段值,而是在不改变索引字段值的同时,自己通过SQL语句来实现逻辑 条件字段函数操作 假设我们现在维护了一张系统交易表: mysql> CREATE TABLE `tradelog` ( `id` ) NOT NULL, `tradeid` ) DEFAULT NULL, `operator` ) DEFAULT NULL, `t_modified` d

==================================声明================================== 本文原创,转载在正文中显要的注明作者和出处,并保证文章的完整性. 未经作者同意请勿修改(包括本声明),保留法律追究的权利. 未经作者同意请勿用于出版.印刷或学术引用. 本文不定期修正完善,为保证内容正确,建议移步原文处阅读. 本文链接:http://www.cnblogs.com/wlsandwho/p/4364899.html =============

最近我们的正式环境一直在报错一个异常,首先我贴出来异常信息 BLL层 捕获到了请求的url Net.BLL.MobileFun MobileFun.GetBusinessBidPolicy 异常 传入参数为:AucId=643129;CarId=680362;businessid:41773: 异常信息为:必须声明标量变量 "@UID". 必须声明标量变量 "@UID". 必须声明标量变量 "@UID". URL:http://*********

参数化查询 使用参数化查询的情景有很多,但最常用的情景是需要用户在查询中进行输入的情况. 有两种方法可供使用.第一,可以讲用户输入嵌入到查询字符串中,例如可能使用.NET Framework中的String.Format函数. 第二种方法是构造一种参数化查询.      在开始时执行如下所示的基本查询: select count(*) from UserInfo }’ and PassWord=‘{}’      然后利用用户的输入构造如下查询: 1 select count(*) from U

第19课-数据库开发及ado.net ADO.NET--SQLDataReader使用.SqlProFiler演示.ADoNET连接池,参数化查询.SQLHelper .通过App.Config文件获得连接字符串 01对TblStudent表进行增删改查 using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Data.SqlClien

今天遇到一个问题,有用户反应,在site上打开报表,一直loading,出不来结果. 遇到这种问题,我立刻simulate用户使用Filter Condition,问题repro,看来不是偶然事件,通过SQL Server Profile Capture 到执行的查询语句. Step1,奇怪的是,在SSMS中执行,SQL Server 很快返回结果,初步结论是问题可能不是由于SQL Server 造成的(事实证明,我错了). 我的第一反应:是不是network的问题,点击F12,查看Networ

where in 的参数化查询实现 首先说一下我们常用的办法,直接拼SQL实现,一般情况下都能满足需要 string userIds = "1,2,3,4"; using (SqlConnection conn = new SqlConnection(connectionString)) { conn.Open(); SqlCommand comm = new SqlCommand(); comm.Connection = conn; comm.CommandText = string

转载至: http://www.cnblogs.com/lzrabbit/archive/2012/04/29/2475427.html 在上一篇Sql Server参数化查询之where in和like实现详解中介绍了在Sql Server使用参数化查询where in的几种实现方案,遗漏了xml和表值参数,这里做一个补充 文章导读 方案5使用xml参数 方案6 使用表值参数TVP,DataTable传参 6种实现方案总结 方案5 使用xml参数 对sql server xml类型参数不熟悉的

转载至:http://www.cnblogs.com/lzrabbit/archive/2012/04/22/2465313.html 文章导读 拼SQL实现where in查询 使用CHARINDEX或like实现where in 参数化 使用exec动态执行SQl实现where in 参数化 为每一个参数生成一个参数实现where in 参数化 使用临时表实现where in 参数化 like参数化查询 xml和DataTable传参  身为一名小小的程序猿,在日常开发中不可以避免的要和wh

为什么要使用参数化查询呢?参数化查询写起来看起来都麻烦,还不如用拼接sql语句来的方便快捷.当然,拼接sql语句执行查询虽然看起来方便简洁,其实不然.远没有参数化查询来的安全和快捷. 今天刚好了解了一下关于Sql Server 参数化查询和拼接sql语句来执行查询的一点区别. 参数化查询与拼接sql语句查询相比主要有两点好处: 1.防止sql注入  2. 提高性能(复用查询计划) 首先我们来谈下参数化查询是如何防止sql注入的这个问题吧. 防注入例子: 拼接sql语句: ("select * f

文章导读 拼SQL实现where in查询 使用CHARINDEX或like实现where in 参数化 使用exec动态执行SQl实现where in 参数化 为每一个参数生成一个参数实现where in 参数化 使用临时表实现where in 参数化 like参数化查询 xml和DataTable传参  身为一名小小的程序猿,在日常开发中不可以避免的要和where in和like打交道,在大多数情况下我们传的参数不多简单做下单引号.敏感字符转义之后就直接拼进了SQL,执行查询,搞定.若有一天

文章导读 拼SQL实现where in查询 使用CHARINDEX或like实现where in 参数化 使用exec动态执行SQl实现where in 参数化 为每一个参数生成一个参数实现where in 参数化 使用临时表实现where in 参数化 like参数化查询 xml和DataTable传参 身为一名小小的程序猿,在日常开发中不可以避免的要和where in和like打交道,在大多数情况下我们传的参数不多简单做下单引号.敏感字符转义之后就直接拼进了SQL,执行查询,搞定.若有一天你

SQL注入的原理 以往在Web应用程序访问数据库时一般是采取拼接字符串的形式,比如登录的时候就是根据用户名和密码去查询: string sql * FROM [User] WHERE UserName = '" + userName + "' AND Password = '" + password + "'"; 其中userName和password两个变量的值是由用户输入的.在userName和password都合法的情况下,这自然没有问题,但是用户输