dav*_*vka 3 mysql sql odbc prepared-statement relational-database
我的理解是在服务器上编译一个预准备语句,从而节省了重复解析,优化等的开销.显然,我应该总是更喜欢使用预处理语句来运行多次查询.
这种方法有任何缺点吗？
我正在使用从C++到mysql的odbc(libodbc ++).
为何使用准备好的陈述
出于安全性和性能原因,在应用程序中使用预准备语句有许多优点.
准备好的语句可以通过将SQL逻辑与提供的数据分开来帮助提高安全性.逻辑和数据的这种分离有助于防止称为SQL注入攻击的非常常见的漏洞类型.通常,在处理即席查询时,在处理从用户收到的数据时需要非常小心.这需要使用能够逃避所有必要的故障字符的函数,例如单引号,双引号和反斜杠字符.在处理预准备语句时,这是不必要的.数据的分离允许MySQL自动考虑这些字符,并且不需要使用任何特殊功能进行转义.
准备好的陈述中的绩效增加可以来自几个不同的特征.首先是需要一次只解析查询.当您最初准备语句时,MySQL将解析语句以检查语法并设置要运行的查询.然后,如果您多次执行查询,它将不再具有该开销.如果需要多次运行相同的查询,这种预解析可以提高速度,例如在执行许多INSERT语句时.
(注意:虽然MySQL 4.1不会发生这种情况,但未来的版本也会缓存预准备语句的执行计划,从而消除了当前为每次查询执行支付的额外开销.)
性能可能增加的第二个位置是使用预处理语句可以使用的新二进制协议.MySQL中的传统协议总是将所有内容转换为字符串,然后再通过网络发送.这意味着客户端将数据转换为字符串,这些字符串通常比原始数据大,通过网络(或其他传输)将其发送到服务器,最终将字符串解码为正确的数据类型.二进制协议消除了此转换开销.所有类型都以本机二进制形式发送,这样可以节省转换CPU的使用量,还可以减少网络使用量.
什么时候应该使用准备好的陈述 准备好的语句可以用于上述所有原因,但是它们不应该(也不能)用于应用程序中的所有内容.首先,它们处理的查询类型仅限于DML(INSERT,REPLACE,UPDATE和DELETE),CREATE TABLE和SELECT查询.将在其他版本中添加对其他查询类型的支持,以使准备好的语句API更加通用.
- >有时准备好的语句实际上比常规查询慢.这样做的原因是服务器有两次往返,这可能会减慢只执行一次的简单查询.在这种情况下,必须决定是否值得权衡这次额外往返的性能影响,以获得使用预准备报表的安全性好处.