Mysql prepare预处理的具体使用
导读
目录
1.预处理2.预处理应用方式A.例子:B.预处理对执行计划变化跟踪C.存储过程包含预处理D.通过profile 查看解析语句的开销3.总结
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环境来说忽略不计 执行计划也是随着数据量而变化的。
从局限性和实际效果来看,目前没有发挥应有的功能。不适合声场环境中使用。