MySQL SQL分析 - 参数化查询vs query cache功能(三)
1188 |
| Waiting for query cache lock | 0.000052 |
| init | 0.000030 |
| checking query cache for query | 0.001791 |
| checking permissions | 0.000172 |
| Opening tables | 0.000614 |
| init | 0.001346 |
| System lock | 0.000268 |
| optimizing | 0.000626 |
| statistics | 0.000674 |
| preparing | 0.000439 |
| executing | 0.000028 |
| Sending data | 0.327278 |
| end | 0.000649 |
| query end | 0.000217 |
| closing tables | 0.000408 |
| freeing items | 0.000692 |
| cleaning up | 0.000570 |
+--------------------------------+----------+
18 rows in set, 1 warning (0.01 sec)
分析结果
从数据返回时间上看来（蓝色标注）， 使用参数化查询，并没有在时间返回上获得优势。
从SQL执行计划上看来（紫色标注), 相同 SQL 语句使用参数化查询，系统同样会重新定制执行计划，产生磁盘I/O， 并没有想 ORACLE 一样获得性能上的优化。
另外，参数化查询是不会在 query cache 内存块中取结果的。
可以看做每次使用参数化查询都会被认为是一个全新的 SQL 进行分析， （没有学习到 ORACLE 的精髓，比较失望）
注意，使用参数化查询时， 即时使用 SQL_cache 语法, 也无法使用 query cache 功能。
常见开发下有几种选择
1. 直接把 SQL 变量值提交至 MySQL API 执行，（可利用 QUERY CACHE 功能，有部分 SQL 能够进行数据加速）但可能会遇到 SQL 注入， 升级程序麻烦。
2. 利用 procudure, function 等功能先吧 SQL 进行打包然后再调用执行， 类似参数化查询， 无法获得 QUERY CACHE 功能， 令程序清晰， 程序升级，修改比较方便， 并且有效防止了 SQL 注入。