澳门新萄京MySql存储过程中limit传参,Stmt预处理提
分类:数据库

复制代码 代码如下: DELIMITER $$ set @stmt = 'select userid,username from myuser where userid between ? and ?'; prepare s1 from @stmt; set @s1 = 2; set @s2 = 100; execute s1 using @s1,@s2; deallocate prepare s1; $$ DELIMITER ; 用这种形式写的查询,可以随意替换参数,给出代码的人称之为预处理,我想这个应该就是MySQL中的变量绑定吧……但是,在查资料的过程中我却听到了两种声音,一种是,MySQL中有类似Oracle变量绑定的写法,但没有其实际作用,也就是只能方便编写,不能提高效率,这种说法在几个09年的帖子中看到: 另一种说法是MySQL中的变量绑定是能确实提高效率的,这个是希望有的,那到底有木有,还是自己去试验下吧。 试验是在本机进行的,数据量比较小,具体数字并不具有实际意义,但是,能用来说明一些问题,数据库版本是mysql-5.1.57-win32免安装版。 本着对数据库不是很熟悉的态度^_^,试验过程中走了不少弯路,此文以结论为主,就不列出实验的设计过程,文笔不好,文章写得有点枯燥,写出来是希望有人来拍砖,因为我得出的结论是:预处理在有没有cache的情况下的执行效率都不及直接执行…… 我对自己的实验结果不愿接受。。如果说预处理只为了规范下Query,使cache命中率提高的话个人觉得大材小用了,希望有比较了解的人能指出事实究竟是什么样子的——NewSilen 实验准备 第一个文件NormalQuery.sql 复制代码 代码如下: Set profiling=1; Select * From MyTable where DictID = 100601000004; Select DictID from MyTable limit 1,100; Select DictID from MyTable limit 2,100; /*从limit 1,100 到limit 100,100 此处省略重复代码*/ ...... Select DictID from MyTable limit 100,100; SELECT query_id,seq,STATE,10000*DURATION FROM information_schema.profiling INTO OUTFILE 'd:/NormalResults.csv' FIELDS TERMINATED BY ',' LINES TERMINATED BY 'n'; 第二个sql文件 StmtQuery.sql 复制代码 代码如下: Set profiling=1; Select * From MyTable where DictID = 100601000004; set @stmt = 'Select DictID from MyTable limit ?,?'; prepare s1 from @stmt; set @s = 100; set @s1 = 101; set @s2 = 102; ...... set @s100 =200; execute s1 using @s1,@s; execute s1 using @s2,@s; ...... execute s1 using @s100,@s; SELECT query_id,seq,STATE,10000*DURATION FROM information_schema.profiling INTO OUTFILE 'd:/StmtResults.csv' FIELDS TERMINATED BY ',' LINES TERMINATED BY 'n'; 做几点小说明: 1. Set profiling=1; 执行此语句之后,可以从information_schema.profiling这张表中读出语句执行的详细信息,其实包含不少内容,包括我需要的时间信息,这是张临时表,每新开一个会话都要重新设置profiling属性才能从这张表中读取数据

在oracle数据库中,有一个变量绑定的用法,很多人都比较熟悉,可以调高数据库效率,应对高并发等,好吧,这其中并不包括我,当同事问我MySQL中有没有类似的写法时,我是很茫然的,于是就上网查,找到了如下一种写法:

MySQL性能分析工具profile使用教程,mysqlprofile

分析SQL执行带来的开销是优化SQL的重要手段。在MySQL数据库中,可以通过配置profiling参数来启用SQL剖析。该参数可以在全局和session级别来设置。对于全局级别则作用于整个MySQL实例,而session级别紧影响当前session。该参数开启后,后续执行的SQL语句都将记录其资源开销,诸如IO,上下文切换,CPU,Memory等等。根据这些开销进一步分析当前SQL瓶颈从而进行优化与调整。本文描述了如何使用MySQL profile,不涉及具体的样例分析。

1、有关profile的描述

复制代码 代码如下:

--当前版本 
[email protected][sakila]> show variables like 'version'; 
--------------- ---------------------------------------  
| Variable_name | Value                                 | 
--------------- ---------------------------------------  
| version       | 5.6.17-enterprise-commercial-advanced | 
--------------- ---------------------------------------  
 
--查看profiling系统变量 
[email protected][sakila]> show variables like '%profil%'; 
------------------------ -------  
| Variable_name          | Value | 
------------------------ -------  
| have_profiling         | YES   |   --只读变量,用于控制是否由系统变量开启或禁用profiling 
| profiling              | OFF   |   --开启SQL语句剖析功能 
| profiling_history_size | 15    |   --设置保留profiling的数目,缺省为15,范围为0至100,为0时将禁用profiling 
------------------------ -------  
 
profiling [539] 
If set to 0 or OFF (the default), statement profiling is disabled. If set to 1 or ON, statement prof 
is enabled and the SHOW PROFILE and SHOW PROFILES statements provide access to prof 
information. See Section 13.7.5.32, “SHOW PROFILES Syntax”. 
 
This variable is deprecated in MySQL 5.6.8 and will be removed in a future MySQL release. 
profiling_history_size [539] 
The number of statements for which to maintain profiling information if profiling [539] is 
enabled. The default value is 15. The maximum value is 100. Setting the value to 0 effectively 
disables profiling. See Section 13.7.5.32, “SHOW PROFILES Syntax”. 
This variable is deprecated in MySQL 5.6.8 and will be removed in a future MySQL release. 
 
 
--获取profile的帮助 
[email protected][sakila]> help profile; 
Name: 'SHOW PROFILE' 
Description: 
Syntax: 
SHOW PROFILE [type [, type] ... ] 
    [FOR QUERY n] 
    [LIMIT row_count [OFFSET offset]] 
 
type: 
    ALL                --显示所有的开销信息 
  | BLOCK IO           --显示块IO相关开销 
  | CONTEXT SWITCHES   --上下文切换相关开销 
  | CPU                --显示CPU相关开销信息 
  | IPC                --显示发送和接收相关开销信息 
  | MEMORY             --显示内存相关开销信息 
  | PAGE FAULTS        --显示页面错误相关开销信息 
  | SOURCE             --显示和Source_function,Source_file,Source_line相关的开销信息 
  | SWAPS              --显示交换次数相关开销的信息  
 
The SHOW PROFILE and SHOW PROFILES statements display profiling 
information that indicates resource usage for statements executed 
during the course of the current session. 
 
*Note*: These statements are deprecated as of MySQL 5.6.7 and will be 
removed in a future MySQL release. Use the Performance Schema instead; 
see . 
--上面描述从5.6.7开始该命令将会被移除,用Performance Schema instead代替 
--在Oracle数据库中,是通过autotrace来剖析单条SQL并获取真实的执行计划以及其开销信息 

2、开启porfiling

复制代码 代码如下:

--启用session级别的profiling 
[email protected][sakila]> set profiling=1; 
Query OK, 0 rows affected, 1 warning (0.00 sec) 
 
--验证修改后的结果 
[email protected][sakila]> show variables like '%profil%'; 
------------------------ -------  
| Variable_name          | Value | 
------------------------ -------  
| have_profiling         | YES   | 
| profiling              | ON    | 
| profiling_history_size | 15    | 
------------------------ -------  
 
--发布SQL查询 
[email protected][sakila]> select count(*) from customer; 
----------  
| count(*) | 
----------  
|      599 | 
----------  
 
--查看当前session所有已产生的profile 
[email protected][sakila]> show profiles; 
---------- ------------ --------------------------------  
| Query_ID | Duration   | Query                          | 
---------- ------------ --------------------------------  
|        1 | 0.00253600 | show variables like '%profil%' | 
|        2 | 0.00138150 | select count(*) from customer  | 
---------- ------------ --------------------------------  
2 rows in set, 1 warning (0.01 sec) 
 
--我们看到有2个warning,之前一个,现在一个 
[email protected][sakila]> show warnings;    --下面的结果表明SHOW PROFILES将来会被Performance Schema替换掉 
--------- ------ --------------------------------------------------------------------------------------------------------------  
| Level   | Code | Message                                                                                                      | 
--------- ------ --------------------------------------------------------------------------------------------------------------  
| Warning | 1287 | 'SHOW PROFILES' is deprecated and will be removed in a future release. Please use Performance Schema instead | 
--------- ------ --------------------------------------------------------------------------------------------------------------  

3、获取SQL语句的开销信息

复制代码 代码如下:

--可以直接使用show profile来查看上一条SQL语句的开销信息 
--注,show profile之类的语句不会被profiling,即自身不会产生Profiling 
--我们下面的这个show profile查看的是show warnings产生的相应开销 
[email protected][sakila]> show profile;   
---------------- ----------  
| Status         | Duration | 
---------------- ----------  
| starting       | 0.000141 | 
| query end      | 0.000058 | 
| closing tables | 0.000014 | 
| freeing items  | 0.001802 | 
| cleaning up    | 0.000272 | 
---------------- ----------  
 
--如下面的查询show warnings被添加到profiles 
[email protected][sakila]> show profiles; 
---------- ------------ --------------------------------  
| Query_ID | Duration   | Query                          | 
---------- ------------ --------------------------------  
|        1 | 0.00253600 | show variables like '%profil%' | 
|        2 | 0.00138150 | select count(*) from customer  | 
|        3 | 0.00228600 | show warnings                  | 
---------- ------------ --------------------------------  
 
--获取指定查询的开销 
[email protected][sakila]> show profile for query 2; 
---------------------- ----------  
| Status               | Duration | 
---------------------- ----------  
| starting             | 0.000148 | 
| checking permissions | 0.000014 | 
| Opening tables       | 0.000047 | 
| init                 | 0.000023 | 
| System lock          | 0.000035 | 
| optimizing           | 0.000012 | 
| statistics           | 0.000019 | 
| preparing            | 0.000014 | 
| executing            | 0.000006 | 
| Sending data         | 0.000990 | 
| end                  | 0.000010 | 
| query end            | 0.000011 | 
| closing tables       | 0.000010 | 
| freeing items        | 0.000016 | 
| cleaning up          | 0.000029 | 
---------------------- ----------  
 
--查看特定部分的开销,如下为CPU部分的开销 
[email protected][sakila]> show profile cpu for query 2 ; 
---------------------- ---------- ---------- ------------  
| Status               | Duration | CPU_user | CPU_system | 
---------------------- ---------- ---------- ------------  
| starting             | 0.000148 | 0.000000 |   0.000000 | 
| checking permissions | 0.000014 | 0.000000 |   0.000000 | 
| Opening tables       | 0.000047 | 0.000000 |   0.000000 | 
| init                 | 0.000023 | 0.000000 |   0.000000 | 
| System lock          | 0.000035 | 0.000000 |   0.000000 | 
| optimizing           | 0.000012 | 0.000000 |   0.000000 | 
| statistics           | 0.000019 | 0.000000 |   0.000000 | 
| preparing            | 0.000014 | 0.000000 |   0.000000 | 
| executing            | 0.000006 | 0.000000 |   0.000000 | 
| Sending data         | 0.000990 | 0.001000 |   0.000000 | 
| end                  | 0.000010 | 0.000000 |   0.000000 | 
| query end            | 0.000011 | 0.000000 |   0.000000 | 
| closing tables       | 0.000010 | 0.000000 |   0.000000 | 
| freeing items        | 0.000016 | 0.000000 |   0.000000 | 
| cleaning up          | 0.000029 | 0.000000 |   0.000000 | 
---------------------- ---------- ---------- ------------  
 
--如下为MEMORY部分的开销 
[email protected][sakila]> show profile memory for query 2 ; 
---------------------- ----------  
| Status               | Duration | 
---------------------- ----------  
| starting             | 0.000148 | 
| checking permissions | 0.000014 | 
| Opening tables       | 0.000047 | 
| init                 | 0.000023 | 
| System lock          | 0.000035 | 
| optimizing           | 0.000012 | 
| statistics           | 0.000019 | 
| preparing            | 0.000014 | 
| executing            | 0.000006 | 
| Sending data         | 0.000990 | 
| end                  | 0.000010 | 
| query end            | 0.000011 | 
| closing tables       | 0.000010 | 
| freeing items        | 0.000016 | 
| cleaning up          | 0.000029 | 
---------------------- ----------  
 
--同时查看不同资源开销 
[email protected][sakila]> show profile block io,cpu for query 2; 
---------------------- ---------- ---------- ------------ -------------- ---------------  
| Status               | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out | 
---------------------- ---------- ---------- ------------ -------------- ---------------  
| starting             | 0.000148 | 0.000000 |   0.000000 |            0 |             0 | 
| checking permissions | 0.000014 | 0.000000 |   0.000000 |            0 |             0 | 
| Opening tables       | 0.000047 | 0.000000 |   0.000000 |            0 |             0 | 
| init                 | 0.000023 | 0.000000 |   0.000000 |            0 |             0 | 
| System lock          | 0.000035 | 0.000000 |   0.000000 |            0 |             0 | 
| optimizing           | 0.000012 | 0.000000 |   0.000000 |            0 |             0 | 
| statistics           | 0.000019 | 0.000000 |   0.000000 |            0 |             0 | 
| preparing            | 0.000014 | 0.000000 |   0.000000 |            0 |             0 | 
| executing            | 0.000006 | 0.000000 |   0.000000 |            0 |             0 | 
| Sending data         | 0.000990 | 0.001000 |   0.000000 |            0 |             0 | 
| end                  | 0.000010 | 0.000000 |   0.000000 |            0 |             0 | 
| query end            | 0.000011 | 0.000000 |   0.000000 |            0 |             0 | 
| closing tables       | 0.000010 | 0.000000 |   0.000000 |            0 |             0 | 
| freeing items        | 0.000016 | 0.000000 |   0.000000 |            0 |             0 | 
| cleaning up          | 0.000029 | 0.000000 |   0.000000 |            0 |             0 | 
---------------------- ---------- ---------- ------------ -------------- ---------------  
 
 
--下面的SQL语句用于查询query_id为2的SQL开销,且按最大耗用时间倒序排列 
[email protected][sakila]> set @query_id=2; 
 
[email protected][sakila]> SELECT STATE, SUM(DURATION) AS Total_R, 
    ->   ROUND( 
    ->        100 * SUM(DURATION) / 
    ->           (SELECT SUM(DURATION) 
    ->            FROM INFORMATION_SCHEMA.PROFILING 
    ->            WHERE QUERY_ID = @query_id 
    ->        ), 2) AS Pct_R, 
    ->     COUNT(*) AS Calls, 
    ->     SUM(DURATION) / COUNT(*) AS "R/Call" 
    ->  FROM INFORMATION_SCHEMA.PROFILING 
    ->  WHERE QUERY_ID = @query_id 
    ->  GROUP BY STATE 
    ->  ORDER BY Total_R DESC; 
---------------------- ---------- ------- ------- --------------  
| STATE                | Total_R  | Pct_R | Calls | R/Call       | 
---------------------- ---------- ------- ------- --------------  
| Sending data         | 0.000990 | 71.53 |     1 | 0.0009900000 |--最大耗用时间部分为发送数据 
| starting             | 0.000148 | 10.69 |     1 | 0.0001480000 | 
| Opening tables       | 0.000047 |  3.40 |     1 | 0.0000470000 | 
| System lock          | 0.000035 |  2.53 |     1 | 0.0000350000 | 
| cleaning up          | 0.000029 |  2.10 |     1 | 0.0000290000 | 
| init                 | 0.000023 |  1.66 |     1 | 0.0000230000 | 
| statistics           | 0.000019 |  1.37 |     1 | 0.0000190000 | 
| freeing items        | 0.000016 |  1.16 |     1 | 0.0000160000 | 
| preparing            | 0.000014 |  1.01 |     1 | 0.0000140000 | 
| checking permissions | 0.000014 |  1.01 |     1 | 0.0000140000 | 
| optimizing           | 0.000012 |  0.87 |     1 | 0.0000120000 | 
| query end            | 0.000011 |  0.79 |     1 | 0.0000110000 | 
| end                  | 0.000010 |  0.72 |     1 | 0.0000100000 | 
| closing tables       | 0.000010 |  0.72 |     1 | 0.0000100000 | 
| executing            | 0.000006 |  0.43 |     1 | 0.0000060000 | 
---------------------- ---------- ------- ------- --------------  
 
--开启profiling后,我们可以通过show profile等方式查看,其实质是这些开销信息被记录到information_schema.profiling表 
--如下面的查询,部分信息省略 
profiling 
[email protected][information_schema]> select * from profiling limit 3,3G; 
*************************** 1. row *************************** 
           QUERY_ID: 1 
                SEQ: 5 
              STATE: init 
           DURATION: 0.000020 
           CPU_USER: 0.000000 
         CPU_SYSTEM: 0.000000 
  CONTEXT_VOLUNTARY: 0 
CONTEXT_INVOLUNTARY: 0 
       BLOCK_OPS_IN: 0 
      BLOCK_OPS_OUT: 0 
      MESSAGES_SENT: 0 
  MESSAGES_RECEIVED: 0 
  PAGE_FAULTS_MAJOR: 0 
  PAGE_FAULTS_MINOR: 0 
              SWAPS: 0 
    SOURCE_FUNCTION: mysql_prepare_select 
        SOURCE_FILE: sql_澳门新萄京,select.cc 
        SOURCE_LINE: 1050 
 
--停止profile,可以设置profiling参数,或者在session退出之后,profiling会被自动关闭 
[email protected][sakila]澳门新萄京MySql存储过程中limit传参,Stmt预处理提高效率问题的小研究。> set profiling=off; 
Query OK, 0 rows affected, 1 warning (0.00 sec)     

最近做项目用到了MySQL数据库,感觉还是蛮好用的,但是有同事前几天写存储过程的时候老调不通,我看了看后发现把limit语句后面带的参数随便改成一个数字就调试通过了,不知道是MySql当初就这么设计的还是一个bug。后来在网上找到一个方法可以通过传参数的方法解决该问题:

  1. Select *澳门新萄京MySql存储过程中limit传参,Stmt预处理提高效率问题的小研究。 From MyTable where DictID = 100601000004; 这行代码貌似和我们的实验没什么关系,本来我也是这么认为的,之所以加这句,是我在之前的摸索中发现,执行过程中有个步骤是open table,如果是第一次打开某张表,那时间是相当长的,所以在执行后面的语句前,我先执行了这行代码打开试验用的表 3. MySQL默认在information_schema.profiling表中保存的查询历史是15条,可以修改profiling_history_size属性来进行调整,我希望他大一些让我能一次取出足够的数据,不过最大值只有100,尽管我调整为150,最后能够查到的也只有100条,不过也够了 4. SQL代码我没有全列出来,因为查询语句差不多,上面代码中用省略号表示了,最后的结果是两个csv文件,个人习惯,你也可以把结果存到数据库进行分析 实验步骤 重启数据库,执行文件NormalQuery.sql,执行文件StmtQuery.sql,得到两个结果文件 再重启数据库,执行StmtQuery.sql,执行文件NormalQuery.sql,得到另外两个结果文件 实验结果 详细结果在最后提供了附件下载,有兴趣的朋友可以看下 结果分析 每一个SQL文件中执行了一百个查询语句,没有重复的查询语句,不存在查询cache,统计执行SQL的平均时间得出如下结果

view sourceprint?DELIMITER $$ 

服务器维护-查看mysql的各项性可以指标

日常维护有很多方面的工作:数据库状态监控、性能分析、SQL代码分析与优化等等。数据库巡检等等工作,你可以参考国内上海爱可生公司网站上提供的MySQL服务相关的内容来写,呵呵。还可以咨询他们。  

 set @stmt = concat('select * from ',table_name,' limit ?,?');  //table_name 是参数, 要写死则如'slect * from table_name',  limit前要有空格,保证连接起来单词有间隔,否则会挤在一起.
  prepare s1 from @stmt;
  set @s1 = page_begin;
  set @s2 = page_end;
  execute s1 using @s1,@s2;

从结果中可以看出,无论是先执行还是后执行,NormalQuery中的语句都比使用预处理语句的要快一些=.=!

  set @stmt = select userid,username from myuser where userid between ? and ?; 

mysql性可以优化,欢迎

你给的信息基本没用,你没说你数据库的应用类型,以及你运营环境

配置文件基本不用改动,具体问题具体微调,他不会对数据库优化起明显作用

优化一般分一下几个:
1.存储引擎的选择。高并发,update,insert较多、切需要事务处理适用 innodb;select为主用myisam;通常所有的表会使用相同的引擎,便于维护
2.根据数据量、cpu、内存、磁盘i/o开销可以选择分表、分库、主从负载
3.最关键的就是sql和索引了,配合适当的索引,写出高效的sql是优化的基本

优化是一个调试的过程,没有1个通用的模式,要从实际情况作合理选择  

分析SQL执行带来的开销是优化SQL的重要手段。在MySQL数据库中,可以通过配置profiling参数来启用...

  deallocate prepare s1;

那再来看看每一句查询具体的情况,Normal和Stmt的query各执行了两百次,每一步的详细信息如下:

  prepare s1 from @stmt; 

从这里面可以看出,第一个,normalquery比stmtquery少一个步骤,第二个,虽然stmt在不少步骤上是优于normal的,但在executing一步上输掉太多,最后结果上也是落败

  set @s1 = 2; 

最后,再给出一个查询缓存的实验结果,具体步骤就不列了

  set @s2 = 100; 

在查询缓存的时候,Normal完胜……

  execute s1 using @s1,@s2; 

写在最后

  deallocate prepare s1; 

大概情况就是这样,我回忆了一下,网上说预处理可以提高效率的,基本都是用编程的方式去执行查询,不知道这个有没有关系,基础有限,希望园子里的大牛能看到,帮忙解惑实验结果附件 MySQL预处理实验结果

$$ 

  

DELIMITER ;

 用这种形式写的查询,可以随意替换参数,给出代码的人称之为预处理,我想这个应该就是MySQL中的变量绑定吧……但是,在查资料的过程中我却听到了两种声音,一种是,MySQL中有类似Oracle变量绑定的写法,但没有其实际作用,也就是只能方便编写,不能提高效率,这种说法在几个09年的帖子中看到:

另一种说法是MySQL中的变量绑定是能确实提高效率的,这个是希望有的,那到底有木有,还是自己去试验下吧。

试验是在本机进行的,数据量比较小,具体数字并不具有实际意义,但是,能用来说明一些问题,数据库版本是mysql-5.1.57-win32免安装版。

  本着对数据库不是很熟悉的态度^_^,试验过程中走了不少弯路,此文以结论为主,就不列出实验的设计过程,文笔不好,文章写得有点枯燥,写出来是希望有人来拍砖,因为我得出的结论是:预处理在有没有cache的情况下的执行效率都不及直接执行…… 我对自己的实验结果不愿接受。。如果说预处理只为了规范下Query,使cache命中率提高的话个人觉得大材小用了,希望有比较了解的人能指出事实究竟是什么样子的——NewSilen

实验准备

  第一个文件NormalQuery.sql

NormalQuery
Set profiling=1;Select * From MyTable where DictID = 100601000004;Select DictID from MyTable limit 1,100;Select DictID from MyTable limit 2,100;/*从limit 1,100 到limit 100,100 此处省略重复代码*/......Select DictID from MyTable limit 100,100;SELECT query_id,seq,STATE,10000*DURATION FROM information_schema.profiling INTO OUTFILE d:/NormalResults.csv FIELDS TERMINATED BY , LINES TERMINATED BY ;
  第二个sql文件 StmtQuery.sql

StmtQuery
Set profiling=1;Select * From MyTable where DictID = 100601000004;set @stmt = Select DictID from MyTable limit ?,?;prepare s1 from @stmt;set @s = 100;set @s1 = 101;set @s2 = 102;......set @s100 =200;execute s1 using @s1,@s;execute s1 using @s2,@s;......execute s1 using @s100,@s;SELECT query_id,seq,STATE,10000*DURATION FROM information_schema.profiling INTO OUTFILE d:/StmtResults.csv FIELDS TERMINATED BY , LINES TERMINATED BY ;
做几点小说明:

  1. Set profiling=1; 执行此语句之后,可以从information_schema.profiling这张表中读出语句执行的详细信息,其实包含不少内容,包括我需要的时间信息,这是张临时表,每新开一个会话都要重新设置profiling属性才能从这张表中读取数据

  2. Select * From MyTable where DictID = 100601000004;

  这行代码貌似和我们的实验没什么关系,本来我也是这么认为的,之所以加这句,是我在之前的摸索中发现,执行过程中有个步骤是open table,如果是第一次打开某张表,那时间是相当长的,所以在执行后面的语句前,我先执行了这行代码打开试验用的表

3. MySQL默认在information_schema.profiling表中保存的查询历史是15条,可以修改profiling_history_size属性来进行调整,我希望他大一些让我能一次取出足够的数据,不过最大值只有100,尽管我调整为150,最后能够查到的也只有100条,不过也够了

4. SQL代码我没有全列出来,因为查询语句差不多,上面代码中用省略号表示了,最后的结果是两个csv文件,个人习惯,你也可以把结果存到数据库进行分析

  实验步骤

重启数据库,执行文件NormalQuery.sql,执行文件StmtQuery.sql,得到两个结果文件

再重启数据库,执行StmtQuery.sql,执行文件NormalQuery.sql,得到另外两个结果文件

  实验结果

详细结果在最后提供了附件下载,有兴趣的朋友可以看下

  结果分析

每一个SQL文件中执行了一百个查询语句,没有重复的查询语句,不存在查询cache,统计执行SQL的平均时间得出如下结果

澳门新萄京 1

从结果中可以看出,无论是先执行还是后执行,NormalQuery中的语句都比使用预处理语句的要快一些=.=!

那再来看看每一句查询具体的情况,Normal和Stmt的query各执行了两百次,每一步的详细信息如下:

澳门新萄京 2

从这里面可以看出,第一个,normalquery比stmtquery少一个步骤,第二个,虽然stmt在不少步骤上是优于normal的,但在executing一步上输掉太多,最后结果上也是落败

 最后,再给出一个查询缓存的实验结果,具体步骤就不列了

澳门新萄京 3

在查询缓存的时候,Normal完胜……

 

...

本文由澳门新萄京发布于数据库,转载请注明出处:澳门新萄京MySql存储过程中limit传参,Stmt预处理提

上一篇:mysql无限级分类实现原理与代码,无限级分类实现 下一篇:没有了
猜你喜欢
热门排行
精彩图文