本文主要介绍了Mysql prepare预处理,文中通过示例代码介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
mysql prepare预处理技术意义在于,是为了减轻服务器压力的一种技术。
就是说绝大多数情况下,某需求某一条sql语句可能会被反复调用执行,或者每次执行的时候只有个别的值不同。
比如:
select的 where子句值不同;
update的 set子句值不同;
insert的 values值不同;
如果每次都需要经过上面的词法语义解析、语句优化、制定执行计划等,则效率就明显下降。
1.预处理
mysql提供了对服务器端准备语句的支持,就叫预处理。
这种支持利用了高效的客户机/服务器二进制协议,使用带有参数值占位符的预编译语句有以下好处:
减少每次执行语句时解析语句的开销。通常,数据库应用程序处理大量几乎相同的语句,只对子句中的字面值或变量值进行更改,例如用于查询和删除的where、用于更新的set和用于插入的values。
防止sql注入攻击。参数值可以包含未转义的sql引号和分隔符。
预处理接口
1.应用程序中的预处理语句
可以通过客户端编程接口使用服务器端准备好的语句,包括用于c程序的mysql c api客户端库,用于java程序的mysql connector/j,以及用于使用。net技术的程序的mysql connector/net。例如,c api提供了一组函数调用,这些函数调用构成了它的预编译语句api
2.sql脚本中的准备语句
还有一个用于预处理语句的替代sql接口。但不需要编程,在sql级别直接可用,可以在任何可以将sql语句发送到要执行的服务器的程序中使用它,例如mysql客户端程序。
2.预处理应用方式
预处理语句的sql语法基于三个sql语句:
prepare语句准备执行。
execute执行一条预处理语句。
deallocate prepare释放一个预处理语句。
a.例子:
预处理语句无法跨session操作:mysql>create table `t1` (
`id` int not null,
name varchar(20),
key `idx_id` (`id`)
) engine=innodb ;
mysql>insert into t1(id,name) values(1,'a'),(2,'b'),(3,'c'),(4,'d'),(5,'e'),(6,'f');
#设定预处理语句
mysql>prepare stmt1 from 'select * from t1 where a=? ';
#设置传递变量
mysql>set @a = 8;
#执行语句
mysql>execute stmt1 using @a;
#释放预处理语句
mysql>deallocate prepar stmt1;
b.预处理对执行计划变化跟踪
通过观察status指标select_scan(执行全表搜索查询的数量)变化判断是否会受到数据量变更的影响。
预处理sql语句随着数据量的变化执行计划也在变更。
c.存储过程包含预处理
预处理语句在存储的例程中创建预处理语句,则在存储的例程结束时不会释放该语句。delimiter //
drop procedure if exists proc_prepared;
create procedure proc_prepared()
begin
declare a int;
declare i int;
prepare stmt1 from 'select * from t1 where id>? ';
set @a = 5;
execute stmt1 using @a;
end //
delimiter ;
call proc_prepared();
存储过程之后单独调用预处理语句,返回结果集:说明预处理没有销毁
set @a = 5;
execute stmt1 using @a;
+----+------+
| id | name |
+----+------+
| 6 | f |
。。。
存储过程之后单独调用预处理语句,返回结果集:说明预处理没有销毁
set @a = 5; execute stmt1 using @a; +----+------+ | id | name | +----+------+ | 6 | f | 。。。
d.通过profile 查看解析语句的开销
通过profile各种语句执行时间,解析语句花费的时间都在0.01秒以内。可以忽略不计。
所以目前在预处理方面上没有发现明显的优势。
3.总结
预编译初始的作用:
提高效率:事先解析、检查、编译等工作。
提高安全性:预防sql注入
局限性和实际效果:
预处理因为局限在session级别,现在无法体现真正的价值。因为mysql ga版本没有线程池概念,每个链接就是每个session
解析编译语句的开销 基本对于mysql环境来说忽略不计
执行计划也是随着数据量而变化的。
从局限性和实际效果来看,目前没有发挥应有的功能。不适合声场环境中使用。
到此这篇关于mysql prepare预处理的具体使用的文章就介绍到这了,更多相关mysql prepare预处理内容请搜索CodeAE代码之家 以前的文章或继续浏览下面的相关文章希望大家以后多多支持CodeAE代码之家!
原文链接:https://blog.csdn.net/dreamyuzhou/article/details/120050346