备案控制台
探索云世界
开发者社区 数据库 文章 正文

MySQL SQL 分析 - 参数化查询 vs query cache 功能

2013-10-23 1343
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
云数据库 RDS MySQL Serverless，0.5-2RCU 50GB
推荐场景：
学生管理系统数据库设计 搭建个人博客
云数据库 RDS MySQL Serverless，价值2615元额度，1个月
简介： query cache,  mysql 5 开始附带的一个功能， 与引擎无关， 只与数据查询语法相关。   测试描述： 当前使用中是 MySQL-5.6.14 Linux RHEL6  64 位系统产生环境,  使用 INNODB 引擎， 分配 innodb 2g 内存空间   [root@TiYanPlat ~]# uname -a Linux TiYanPlat 2.6.32

query cache,  mysql 5 开始附带的一个功能， 与引擎无关， 只与数据查询语法相关。

 

测试描述： 当前使用中是 MySQL-5.6.14 Linux RHEL6  64 位系统产生环境,  使用 INNODB 引擎， 分配 innodb 2g 内存空间

 

[root@TiYanPlat ~]# uname -a
Linux TiYanPlat 2.6.32-358.el6.x86_64 #1 SMP Tue Jan 29 11:47:41 EST 2013 x86_64 x86_64x86_64 GNU/Linux

mysql> select version();
+-----------+
| version() |
+-----------+
| 5.6.14    |
+-----------+
1 row in set (0.00 sec)

mysql> show variables like 'innodb_buffer_pool_size';
+-------------------------+------------+
| Variable_name           | Value      |
+-------------------------+------------+
| innodb_buffer_pool_size | 2147483648 |
+-------------------------+------------+
1 row in set (0.01 sec)

 

Query cache 功能：

利用 qeury_cache_size 定义内存大小， 内存用于把用户 SQL 放入内存中， 包括 SQL 语句， 包括SQL 语句执行的结果

假如下一次查询时使用相同的 SQL 语句， 则直接从内存中获得结果， 不再进行 SQL 分析， 不在进行磁盘 I/O 读数据。加速数据查询返回结果。

 

实现目标，开启 QCACHE 功能， 如 my.cnf 定义

query-cache-size=16777216
query-cache-type=ON

查询数据库中是否使用当前功能

mysql> show status like '%qcache%';
+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+
| Qcache_free_blocks      | 440      |
| Qcache_free_memory      | 12306960 |
| Qcache_hits             | 13176    |
| Qcache_inserts          | 29777    |
| Qcache_lowmem_prunes    | 0        |
| Qcache_not_cached       | 45862    |
| Qcache_queries_in_cache | 2098     |
| Qcache_total_blocks     | 4701     |
+-------------------------+----------+
8 rows in set (0.02 sec)

参数返回结果不再一一详细描述， 自行参考官方文档， 从上返回结果可以看到，使用中的数据库 SQL 命中率 （Qcache_hits） 并不理想，原因与业务有关。

 

SQL 分析一， 使用了 QUERY CACHE 的好处

原理， 利用 EXPLAIN 分析当前 SQL 执行计划， 利用 PROFILE 功能分析当前 SQL 执行计划，过程

执行下面语句进行分析

mysql> explain select tbcrbtnumb0_.id as id41_, tbcrbtnumb0_.business_ring_id as business2_41_, tbcrbtnumb0_.application_no as applicat3_41_, tbcrbtnumb0_.mobile as mobile41_ from tb_crbt_numbers_load tbcrbtnumb0_ where 1=1 and tbcrbtnumb0_.business_ring_id=11024;
+----+-------------+--------------+------+---------------+------+---------+------+--------+-------------+
| id | select_type | table        | type | possible_keys | key  | key_len | ref  | rows   | Extra       |
+----+-------------+--------------+------+---------------+------+---------+------+--------+-------------+
|  1 | SIMPLE      | tbcrbtnumb0_ | ALL  | NULL          | NULL | NULL    | NULL |180182 | Using where |
+----+-------------+--------------+------+---------------+------+---------+------+--------+-------------+
1 row in set (0.00 sec)

当前语法执行的是全表扫描，另外，需要从 180182 行中扫描相关结果

 

SQL 分析二， 判断第一次执行该 SQL 时候的执行过程

mysql> set profiling=1;

mysql> select tbcrbtnumb0_.id as id41_, tbcrbtnumb0_.business_ring_id as business2_41_, tbcrbtnumb0_.application_no as applicat3_41_, tbcrbtnumb0_.mobile as mobile41_ from tb_crbt_numbers_load tbcrbtnumb0_ where 1=1 and tbcrbtnumb0_.business_ring_id=11024;

+-------+---------------+---------------+-------------+
| id41_ | business2_41_ | applicat3_41_ | mobile41_   |
+-------+---------------+---------------+-------------+
| 30838 |         11024 | TH20121127229 | 02038688592 |
+-------+---------------+---------------+-------------+
1 row in set (0.30 sec)

mysql> show profile;                                                                                                          +--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.000191 |
| Waiting for query cache lock   | 0.000023 |
| init                           | 0.000090 |
| checking query cache for query | 0.000499 |
| checking permissions           | 0.000030 |
| Opening tables                 | 0.000131 |
| init                           | 0.000277 |
| System lock                    | 0.000042 |
| Waiting for query cache lock   | 0.000005 |
| System lock                    | 0.000443 |
| optimizing                     | 0.000364 |
| statistics                     | 0.000107 |
| preparing                      | 0.000059 |
| executing                      | 0.000019 |
| Sending data                   | 0.290067 |
| end                            | 0.000483 |
| query end                      | 0.000169 |
| closing tables                 | 0.000158 |
| freeing items                  | 0.000252 |
| Waiting for query cache lock   | 0.000063 |
| freeing items                  | 0.000305 |
| Waiting for query cache lock   | 0.000015 |
| freeing items                  | 0.000095 |
| storing result in query cache  | 0.000145 |
| cleaning up                    | 0.000330 |
+--------------------------------+----------+
25 rows in set, 1 warning (0.01 sec)

从上面看出， 第一次执行该 SQL， MySQL 需要对 SQL 进行锁缓存，初始化，从缓存中查询是否具备之前缓存过的 SQL，检查用户权限， 表权限，打开表，锁定内存，定制执行计划，执行语句，把数据从磁盘中放入内存中操作，关闭表，锁定数据， 缓存数据等操作， 工作原理与 ORACLE 类似

 

按照 QUERY CACHE 原则， 假如 SQL 语句改变 (tbcrbtnumb0_.business_ring_id=11024) 替换该变量值， 那么该 SQL 会被看作为一个新的 SQL， 这个时候， MySQL 将会对整个 SQL 做一次全新的操作， 如上（黄线标注描述）

 

分析 SQL 三

mysql> select tbcrbtnumb0_.id as id41_, tbcrbtnumb0_.business_ring_id as business2_41_, tbcrbtnumb0_.application_no as applicat3_41_, tbcrbtnumb0_.mobile as mobile41_ from tb_crbt_numbers_load tbcrbtnumb0_ where 1=1 and tbcrbtnumb0_.business_ring_id=11021;
+-------+---------------+---------------+-------------+
| id41_ | business2_41_ | applicat3_41_ | mobile41_   |
+-------+---------------+---------------+-------------+
| 30835 |         11021 | TH20121127259 | 02038688592 |
+-------+---------------+---------------+-------------+
1 row in set (0.34 sec)

mysql> show profile;
+--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.000795 |
| Waiting for query cache lock   | 0.000077 |
| init                           | 0.000045 |
| checking query cache for query | 0.000337 |
| checking permissions           | 0.000040 |
| Opening tables                 | 0.000113 |
| init                           | 0.000488 |
| System lock                    | 0.000050 |
| Waiting for query cache lock   | 0.000030 |
| System lock                    | 0.000289 |
| optimizing                     | 0.000512 |
| statistics                     | 0.000278 |
| preparing                      | 0.000078 |
| executing                      | 0.000028 |
| Sending data                   | 0.322662 |
| end                            | 0.004777 |
| query end                      | 0.001703 |
| closing tables                 | 0.000526 |
| freeing items                  | 0.000874 |
| Waiting for query cache lock   | 0.000311 |
| freeing items                  | 0.001809 |
| Waiting for query cache lock   | 0.000105 |
| freeing items                  | 0.000184 |
| storing result in query cache  | 0.000966 |
| cleaning up                    | 0.000678 |
+--------------------------------+----------+
25 rows in set, 1 warning (0.00 sec)

上 SQL二，三结果可以看到， 当 WHERE 条件改变， MySQL 会把这两个 SQL 识别为一个新的 SQL， 需要重新操作。

 

SQL 分析四， 假如我们重新执行 SQL 三操作，看看结果如何？（注意，这个时候 QUERY CACHE 真正发挥作用）

mysql> select tbcrbtnumb0_.id as id41_, tbcrbtnumb0_.business_ring_id as business2_41_, tbcrbtnumb0_.application_no as applicat3_41_, tbcrbtnumb0_.mobile as mobile41_ from tb_crbt_numbers_load tbcrbtnumb0_ where 1=1 and tbcrbtnumb0_.business_ring_id=11021;
+-------+---------------+---------------+-------------+
| id41_ | business2_41_ | applicat3_41_ | mobile41_   |
+-------+---------------+---------------+-------------+
| 30835 |         11021 | TH20121127259 | 02038688592 |
+-------+---------------+---------------+-------------+
1 row in set (0.00 sec)

mysql> show profile;                                                                                                          +--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.001367 |
| Waiting for query cache lock   | 0.000071 |
| init                           | 0.000027 |
| checking query cache for query | 0.000163 |
| checking privileges on cached  | 0.000129 |
| checking permissions           | 0.000386 |
| sending cached result to clien | 0.000164|
| cleaning up                    | 0.000079 |
+--------------------------------+----------+
8 rows in set, 1 warning (0.01 sec)

参考 SQL 分析三，四，数据查询需要使用的时间（绿色标注部分）很明显， SQL 分析四返回速度块了很多，另外，从系统返回的 SQL 分析看出来，系统直接从缓存中返回数据给客户， 没有重复进行 SQL 分析及磁盘 I/O 操作。（蓝色标注部分） 因此， QEURY CACHE 明显加速了 SQL 返回结果。

但必须注意，只有两个 SQL 相同的情况下，才能够获得 QUERY CACHE 的优点。

 

 

参数化查询

参数化查询能够在一定情况下避免了 SQL 注入， 而 ORACLE 也比较推荐使用参数化查询， ORACLE 每次执行 SQL （无论 SQL 是否语法一致）都存在 SQL 分析，

假如SQL语法不一样，则进行硬解析，需要重新定制执行计划

假如SQL语法不一致则进行软解析，避免重复定制执行计划，减少 CPU 消耗，增加 SQL 语句返回时间。

MySQL 官方文档中并没有提出到这点。

 

对 MySQL 进行参数化查询分析

SQL 参数化分析一


mysql> set @num=11204;
mysql> select tbcrbtnumb0_.id as id41_, tbcrbtnumb0_.business_ring_id as business2_41_, tbcrbtnumb0_.application_no as applicat3_41_, tbcrbtnumb0_.mobile as mobile41_ from tb_crbt_numbers_load tbcrbtnumb0_ where 1=1 and tbcrbtnumb0_.business_ring_id=@num;
+-------+---------------+---------------+-----------+
| id41_ | business2_41_ | applicat3_41_ | mobile41_ |
+-------+---------------+---------------+-----------+
| 31051 |         11204 | 1222570       | 85237810  |
| 31052 |         11204 | 1222570       | 82685386  |
| 31053 |         11204 | 1222570       | 82783689  |
| 31054 |         11204 | 1222570       | 82685106  |
| 31055 |         11204 | 1222570       | 38880051  |
+-------+---------------+---------------+-----------+
5 rows in set (0.37 sec)

mysql> show profile;                                                                                                          +--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.001858 |
| Waiting for query cache lock   | 0.000089 |
| init                           | 0.000150 |
| checking query cache for query | 0.001143 |
| checking permissions           | 0.000970 |
| Opening tables                 | 0.000544 |
| init                           | 0.000743 |
| System lock                    | 0.000170 |
| optimizing                     | 0.000332 |
| statistics                     | 0.000293 |
| preparing                      | 0.000134 |
| executing                      | 0.000057 |
| Sending data                   | 0.438626 |
| end                            | 0.000694 |
| query end                      | 0.000221 |
| closing tables                 | 0.000300 |
| freeing items                  | 0.000521 |
| cleaning up                    | 0.000360 |
+--------------------------------+----------+
18 rows in set, 1 warning (0.01 sec)


变量值不变情况下，重复执行该 SQL 语句

mysql> select tbcrbtnumb0_.id as id41_, tbcrbtnumb0_.business_ring_id as business2_41_, tbcrbtnumb0_.application_no as applicat3_41_, tbcrbtnumb0_.mobile as mobile41_ from tb_crbt_numbers_load tbcrbtnumb0_ where 1=1 and tbcrbtnumb0_.business_ring_id=@num;
+-------+---------------+---------------+-----------+
| id41_ | business2_41_ | applicat3_41_ | mobile41_ |
+-------+---------------+---------------+-----------+
| 31051 |         11204 | 1222570       | 85237810  |
| 31052 |         11204 | 1222570       | 82685386  |
| 31053 |         11204 | 1222570       | 82783689  |
| 31054 |         11204 | 1222570       | 82685106  |
| 31055 |         11204 | 1222570       | 38880051  |
+-------+---------------+---------------+-----------+
5 rows in set (0.34 sec)

mysql> show profile;                                                                                                          +--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.001188 |
| 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 注入。

 

 

文章标签：
云数据库 RDS MySQL 版
SQL
关系型数据库
MySQL
Oracle
缓存
关键词：
云数据库 RDS MySQL 版功能
云数据库 RDS MySQL 版查询
SQL查询
SQL功能
SQL查询功能
相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境，其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心，利用清洁计算为万物互联的新世界提供源源不断的能源动力，目前开服的区域包括中国（华北、华东、华南、香港）、新加坡、美国（美东、美西）、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程，来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品：云服务器ECS 云服务器 ECS（Elastic Compute Service）是一种弹性可伸缩的计算服务，助您降低 IT 成本，提升运维效率，使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
terry.zeng
目录
相关文章
辰辰zZ
|
4天前
|
SQL 关系型数据库 MySQL
【MySQL系列笔记】常用SQL
常用SQL分为三种类型，分别为DDL，DML和DQL；这三种类型的SQL语句分别用于管理数据库结构、操作数据、以及查询数据，是数据库操作中最常用的语句类型。 在后面学习的多表联查中，SQL是分析业务后业务后能否实现的基础，以及后面如何书写动态SQL，以及完成级联查询的关键。
辰辰zZ
19 6
你的小笔记本YY
|
5天前
|
SQL 关系型数据库 MySQL
【MySQL-4】简述SQLの通用语法及4种基本语句介绍（DDL/DML/DQL/DCL）
【MySQL-4】简述SQLの通用语法及4种基本语句介绍（DDL/DML/DQL/DCL）
你的小笔记本YY
12 1
辰辰zZ
|
5天前
|
SQL 存储 关系型数据库
【MySQL系列笔记】SQL优化
SQL优化是通过调整数据库查询、索引、表结构和配置参数等方式，提高SQL查询性能和效率的过程。它旨在减少查询执行时间、减少系统资源消耗，从而提升数据库系统整体性能。优化方法包括索引优化、查询重写、表分区、适当选择和调整数据库引擎等。
辰辰zZ
25 3
讓丄帝愛伱
|
6天前
|
SQL 关系型数据库 MySQL
MySQL SQL error: #1271 - Illegal mix of collations for operation ‘UNION‘
MySQL SQL error: #1271 - Illegal mix of collations for operation ‘UNION‘
讓丄帝愛伱
21 0
讓丄帝愛伱
|
6天前
|
SQL 关系型数据库 数据库
SQL 42501: Postgresql查询中的权限不足错误
SQL 42501: Postgresql查询中的权限不足错误
讓丄帝愛伱
16 0
屿小夏
|
7天前
|
SQL 关系型数据库 MySQL
【MySQL】：探秘主流关系型数据库管理系统及SQL语言
【MySQL】：探秘主流关系型数据库管理系统及SQL语言
屿小夏
14 0
三分钟热度的鱼
|
7天前
|
SQL 分布式计算 大数据
MaxCompute操作报错合集之在sql 里嵌套查询时，查询条件带有instr时报错，如何解决
MaxCompute是阿里云提供的大规模离线数据处理服务，用于大数据分析、挖掘和报表生成等场景。在使用MaxCompute进行数据处理时，可能会遇到各种操作报错。以下是一些常见的MaxCompute操作报错及其可能的原因与解决措施的合集。
三分钟热度的鱼
20 1
你的小笔记本YY
|
5天前
|
SQL 关系型数据库 MySQL
【MySQL-3】图形化界面工具DataGrip安装＆配置＆使用
【MySQL-3】图形化界面工具DataGrip安装＆配置＆使用
你的小笔记本YY
16 0
你的小笔记本YY
|
5天前
|
关系型数据库 MySQL Linux
【MySQL-2】MySQL的下载＆安装＆启停＆配置环境变量【一条龙教程】
【MySQL-2】MySQL的下载＆安装＆启停＆配置环境变量【一条龙教程】
你的小笔记本YY
14 0
魏红斌
|
6天前
|
弹性计算 关系型数据库 MySQL
在线安装MySQL5.7和MySQL8.0
【4月更文挑战第30天】
魏红斌
21 0

热门文章

最新文章

  • 1
    一文搞懂SQL优化——如何高效添加数据
  • 2
    【SQL server】玩转SQL server数据库：第三章 关系数据库标准语言SQL（二）数据查询
  • 3
    NL2SQL实践系列(2)：2024最新模型实战效果(Chat2DB-GLM、书生·浦语2、InternLM2-SQL等)以及工业级案例教学
  • 4
    数据库管理与电脑监控软件：SQL代码优化与实践
  • 5
    【SQL server】玩转SQL server数据库：第二章 关系数据库
  • 6
    SQL常见面试题总结2
  • 7
    大模型与数据分析：探索Text-to-SQL（上）
  • 8
    NL2SQL进阶系列(4)：ConvAI、DIN-SQL等16个业界开源应用实践详解[Text2SQL]
  • 9
    NL2SQL进阶系列(5)：论文解读业界前沿方案（DIN-SQL、C3-SQL、DAIL-SQL）、新一代数据集BIRD-SQL解读
  • 10
    大模型与数据分析：探索Text-to-SQL（中）
  • 1
    [MySQL]SQL优化之索引的使用规则
    37
  • 2
    【mysql】—— 用户管理
    32
  • 3
    【mysql】—— 视图
    32
  • 4
    【mysql】—— 表的增删改查
    42
  • 5
    【mysql】—— 表的约束
    33
  • 6
    【MYSQL】—— MySQL 在 Centos 7环境安装
    63
  • 7
    MySQL模糊查询二三事
    26
  • 8
    MySQL的JOIN到底是怎么玩的
    108
  • 9
    MySQL怎样删除重复数据，只保留一条？
    38
  • 10
    【怒怼大厂面试官】你先说说知道哪些MySQL的高级特性
    49

    • 相关课程

    更多
  • 如何在 PolarDB-X 中优化慢 SQL
  • SQL完全自学手册
  • SQL Server on Linux入门教程
  • SQL入门与实践
  • 数据库及SQL/MySQL基础
  • SQL进阶及查询

    • 相关电子书

    更多
  • SQL Server 2017
  • GeoMesa on Spark SQL
  • 原生SQL on Hadoop引擎- Apache HAWQ 2.x最新技术解密malili

    • 相关实验场景

    更多
  • SQL的增删改查及函数应用
  • MyBase MySQL实例资源灵活弹配
  • PolarDB MySQL自动SQL限流
  • 如何实现AnalyticDB MySQL多租户功能
  • PolarDB MySQL从表回收站中恢复误删的表
  • 如何开通SQL Server的专属集群

    • 推荐镜像

    更多
  • mysql
  • mariadb
  • postgresql
    • 下一篇
    将Stable Diffusion模型文件转存到FC环境的NAS