为什么MySQL做查询语句时，第一次会很慢，但是第二次，第三次就会变快

为什么MySQL的查询事务第一次执行会很慢，第二次，第三次就会快很多呢？

在国外，有个老外这么提问

Hi, I have an sql query which takes 8 seconds in the first run. The next run there after takes 0.5 seconds and all consecutive runs take 0.5 seconds. Is the plan getting cached? How do i make this query run in 0.5 second in the first run itself? Please find the query below.

翻译：

我有一个SQL查询，第一次运行需要8秒。之后的下一次运行需要0.5秒，所有连续运行需要0.5秒。该计划是否被缓存？如何在第一次运行中以0.5秒的速度运行此查询？请在下面找到查询。

select isnull(joblabor.IDNumber,-1) 'ProcessTransactionID',EmpNo 'EmployeeID',case(joblabor.lJob) when '-1' then '0' else joblabor.ljob end 'JobID',
joblabor.ProcNo 'ActivityID',process.Process 'ActvityName', joblabor.shift 'Shift',case (isnull(suspend,0)) when 1 then 'true' else 'false' end 'Suspended',
joblabor.StartTime 'StartDateTime',joblabor.starttime 'StartTime', joblabor.updated 'UpdatedDate',
ProcQuant 'Quantity',Prochours 'Hours',isnull(Remarks,'') 'Remark',IsNull(JCNotes,'') 'Notes',IsNULL(JobFormSpecs.PartDes,'') as FormDesc,
IsNull(Job.EstDes1,'') 'JobDesc',0 'Standard',0 'MinimumStd',0 'MaximumStd',JobLabor.PartNo 'FormID',joblabor.CostDate 'CostDate',isnull(JobLabor.linenum,1) 'ProcessTransactionIndex',case(joblabor.suspend) when 1 then 1 else 0 end 'ProcessType'
,(joblabor.timepct*100) 'Percent',IsNull(Job.FCustNo,'') 'CustomerID', IsNull(Job.FCompany,'') 'CustomerName' , joblabor.EndTime 'EndDateTime',process.ProcGroup 'ActivityGroup',
case (LEN(LTRIM(SUBSTRING(Job.remark1, 1, 25)))) when 0 then 'false' else 'true' end 'HasJobNotes' ,
case (isnull(ProcessRemarks.ContainsProcessRemarks,0)) when 0 then 'false' else 'true' end 'HasProcessRemarks' ,
case (isnull(ChangeOrder.ContainsChangeOrders,0)) when 0 then 'false' else 'true' end 'HasAlteration'
,isnull(joblabor.costcode,'') 'CostStatus'
,isnull(Complete,'') 'CompletionCode',GRYield 'GrossYield',NetYield 'NetYield'
from BBJobCST joblabor (nolock)
Left Outer Join bbjthead Job (nolock) on (joblabor.lJob = Job.lJob)
inner join SSProces as Process (nolock) on( process.ProcNo = joblabor.ProcNo AND process.archive = 0)
left outer join bbPthead JobFormSpecs (nolock) on (ltrim(rtrim(joblabor.Ljob)) = ltrim(rtrim(JobFormSpecs.LJob)) and ltrim(rtrim(JobLabor.PartNo))=ltrim(rtrim(jobFormSpecs.PartNo)) )
left outer join (
SELECT Count(bbchghdr.ljob) 'ContainsChangeOrders', bbchghdr.ljob FROM bbchghdr (nolock)
inner join bbchglin (nolock) ON bbchghdr.ljob = bbchglin.ljob AND bbchghdr.changeno = bbchglin.changeno
WHERE type = 'P' AND descript NOT LIKE '' group by bbchghdr.ljob) ChangeOrder on ChangeOrder.ljob=joblabor.ljob
left join (
SELECT Count(bbjobcst.ljob) 'ContainsProcessRemarks', bbjobcst.ljob
FROM bbjobcst (nolock) WHERE ( LEN(LTRIM(SUBSTRING(bbjobcst.jcnotes, 1, 25))) > 0 or LEN(LTRIM(remarks)) > 0)
Group By bbjobcst.ljob) ProcessRemarks on ProcessRemarks.ljob=joblabor.ljob
where joblabor.empno = '000002013' and
(isnull(joblabor.endtime,'') = '' or suspend=1 ) and (joblabor.ProcHours = 0 or suspend=1 )
and joblabor.ljob <> 0
order by joblabor.Costdate desc,joblabor.starttime desc,[linenum] asc

回答：

It isn’t the query plan that is getting cached – it is the actual data and indexes which are being cached. This is common behavior of any database. If you ran the query, then waited a while and ran again (keeping the session active), you would see the query take longer again, based on the cached data/indexes being flushed to make room for other data.
You can see if you can reduce the 0.5 seconds repeat time, and/or you can see if you can reduce the intermediate result sets (which are usually what get cached and speed up the queries the second…nth runs).
If the query is producing a large intermediate result set (perhaps a large join where most records are then discarded), you may be able to speed it up by changing parts of your query. Also, sometimes just adding the right index can solve issues like this.
Look at the execution plan and see if there are any “table access full”, “index access full”, “cartesian”, or similar joins indicating inefficient join/indexing.

翻译：

意思就是说Sql语句第一次查询慢的原因不仅仅是因为执行计划没有被缓存这么简单，有时候你会发现Sql语句重用了执行计划，但是第一次查询还是很慢。就如同上面回答一样，最主要的原因是第一次查询的时候，mysql会将查询出的部分数据和索引从磁盘加载到内存作为缓存，而第二次查询的时候就直接从内存缓存中拿出数据了，自然要比从磁盘上加载数据快很多，mysql 会定期清除缓存，所以一段Sql语句如果长期不执行后，就需要从磁盘从新加载数据。

为什么MySQL做查询语句时，第一次会很慢，但是第二次，第三次就会变快相关推荐

当我们输入一条SQL查询语句时，发生了什么？
我们经常说,看一个事儿千万不要直接陷入细节里,你应该先鸟瞰其全貌,这样能够帮助你从高维度理解问题.同样,对于 MySQL 的学习也是这样.平时我们使用数据库,看到的通常都是一个整体.比如,你有个最简单 ...
MySQL高级查询语句——超详细，一篇就够了
MySQL高级查询语句一.MySQL进阶查询 1.1.按关键字排序--order by 1.2.对结果进行分组--group by 1.2.1.单个分组 1.2.2.分组结合order by使用 1 ...
MySQL数据查询语句
MySQL数据查询语句 MySQL 表单查询是指从一张表的数据中查询所需的数据,主要有查询所有字段.查询指定字段.查询指定记录.查询空值.多条件的查询.对查询结果进行排序分组等. 查询结构 SELEC ...
mysql中如何分页查询_MySQL_mysql分页原理和高效率的mysql分页查询语句，以前我在mysql中分页都是用的 l - phpStudy...
mysql分页原理和高效率的mysql分页查询语句以前我在mysql中分页都是用的 limit 100000,20这样的方式,我相信你也是吧,但是要提高效率,让分页的代码效率更高一些,更快一些,那我 ...
MySQL 基本查询语句
MySQL基本查询语句表示例 id name price author stock img_path 1 java从入门到放弃 80.00 国哥 7 static/img/default.jpg 2 ...
mysql 查询语句参数,mysql参数化查询语句有关问题
mysql参数化查询语句问题部分代码如下: using (MySqlConnection conn = new MySqlConnection(connectionString)) { conn.O ...
Mysql高级查询语句练习
Mysql高级查询语句练习 DROP TABLE IF EXISTS `tblcourse`; CREATE TABLE `tblcourse` ( `CourseId` varchar(3) NOT ...
【SQL】MySQL的查询语句
文章目录 SELECT语句 WHERE子句 JOIN语句 GROUP BY和HAVING ORDER BY LIMIT 其他关键字 MySQL是一种广泛使用的关系型数据库管理系统,它被广泛地应用于各种 ...
MySQL数据库——查询语句SELECT的学习总结，2W字超详细总结，值得收藏
文章目录一.基本的SELECT语句 1.SQL分类 2.SQL的语言规范 2.1.基本规则(必须遵守) 2.2.SQL大小写规范(建议遵守) 2.3.注释 2.4.数据导入指令 3.基本的SELEC ...

为什么MySQL做查询语句时，第一次会很慢，但是第二次，第三次就会变快

为什么MySQL做查询语句时，第一次会很慢，但是第二次，第三次就会变快

为什么MySQL做查询语句时，第一次会很慢，但是第二次，第三次就会变快相关推荐

最新文章

热门文章