sql執(zhí)行順序：

1、LIMIT 語句；

分頁查詢，是最常用的場景之一，但也通常也是最容易出問題。比如對(duì)于簡單的語句，一般 DBA ，想到的辦法是在 type, name, create_time 字段上加組合索引。條件排序都能有效的【利用到索引】，性能迅速提升。

好吧，可能90%以上的 【DBA】 解決該問題就到此為止。但當(dāng) LIMIT 子句變成 “LIMIT 1000000,10” 時(shí)，程序員仍然會(huì)抱怨：我只取10條記錄，為什么還是慢？

要知道數(shù)據(jù)庫也并不知道，第1000000條記錄從什么地方開始，即使有索引，也需要從頭計(jì)算一次。出現(xiàn)這種性能問題，多數(shù)情形下是程序員偷懶了。

在前端數(shù)據(jù)瀏覽翻頁，或者大數(shù)據(jù)分批導(dǎo)出等場景下，是可以將上一頁的最大值當(dāng)成參數(shù)作為select條件的。SQL 重新設(shè)計(jì)如下：

在新設(shè)計(jì)下select時(shí)間基本固定，不會(huì)隨著數(shù)據(jù)量的增長而變。

2、隱式轉(zhuǎn)換；

SQL語句中，select變量和字段定義類型不匹配，是另一個(gè)常見的錯(cuò)誤。比如下面的語句：

其中字段 bpn 的定義為 varchar(20)，MySQL 的策略是將字符串轉(zhuǎn)換為數(shù)字之后再比較。函數(shù)作用于表字段，索引失效。

上述情況可能是應(yīng)用程序框架自動(dòng)填入的參數(shù)，而不是程序員的原意。現(xiàn)在應(yīng)用框架很多很繁雜，使用方便的同時(shí)也小心它可能給自己挖坑。

3、關(guān)聯(lián)更新、刪除

雖然 MySQL5.6 引入了物化特性，目前僅僅針對(duì)【select】語句的優(yōu)化。對(duì)于更新或刪除，需要手工重寫成 JOIN。

比如下面 UPDATE 語句，MySQL 實(shí)際執(zhí)行的是循環(huán)/嵌套子查詢(DEPENDENT SUBQUERY)，時(shí)間可想而知。

執(zhí)行計(jì)劃：

重寫為 JOIN 之后，子查詢的選擇模式，從 DEPENDENT SUBQUERY 變成 DERIVED，執(zhí)行速度大大加快，從7秒降低到2毫秒。

執(zhí)行計(jì)劃簡化為：

4、混合排序

MySQL 不能利用索引進(jìn)行混合排序。但在某些場景，還是有機(jī)會(huì)使用特殊方法提升性能的。

執(zhí)行計(jì)劃顯示為全表掃描：

由于 is_reply 只有0和1兩種狀態(tài)，我們按照下面的方法重寫后，執(zhí)行時(shí)間從1.58秒，降低到2毫秒。

5、EXISTS語句

MySQL 對(duì)待 EXISTS 子句時(shí)，仍然采用嵌套【子查詢】的執(zhí)行方式。如下面的 SQL 語句：

執(zhí)行計(jì)劃為：

去掉 exists 更改為 join，能夠避免嵌套【子查詢】，將執(zhí)行時(shí)間從1.93秒降低為1毫秒。

新的執(zhí)行計(jì)劃：

6、條件下推；

外部select條件，不能夠下推到復(fù)雜的視圖，或子查詢的情況有：

1、聚合子查詢； 2、含有 LIMIT 的子查詢； 3、UNION 或 UNION ALL 子查詢； 4、輸出字段中的【子查詢】；

如下面的語句，條件作用于，聚合子查詢之后：

確定從語義上，查詢條件，可以直接下推后，重寫如下；

執(zhí)行計(jì)劃變?yōu)?#xff1a;

7、提前縮小范圍**

先上初始 SQL 語句：

該SQL語句原意是：先做一系列的左連接，然后排序取前15條記錄。從執(zhí)行計(jì)劃，也可以看出，最后一步估算排序記錄數(shù)為90萬，時(shí)間消耗為12秒。

由于最后 WHERE 條件，及排序均針對(duì)最左主表，因此可以先對(duì) 【my_order】 提前縮小數(shù)據(jù)量，再做左連接。SQL 重寫后如下，執(zhí)行時(shí)間縮小為，1毫秒左右。

再檢查執(zhí)行計(jì)劃：子查詢物化后(select_type=DERIVED)參與 JOIN。雖然估算行掃描仍然為90萬，但是利用了索引以及 LIMIT 子句后，實(shí)際執(zhí)行時(shí)間變得很小。

8、中間結(jié)果集下推

再來看下面這個(gè)已經(jīng)初步優(yōu)化過的例子(左連接中主表優(yōu)先作用【查詢條件】)：

不難看出子查詢 c ，是全表聚合查詢，表數(shù)量大情況下，導(dǎo)致性能下降。

其實(shí)對(duì)于子查詢 c，左連接最后結(jié)果集只關(guān)心能和主表 resourceid 能匹配的數(shù)據(jù)。因可以重寫語句，執(zhí)行時(shí)間從原來的2秒下降到2毫秒。

但是子查詢 a 在我們的SQL語句中出現(xiàn)了多次。這種寫法不僅存在額外的開銷，顯的繁雜。使用 WITH 語句再次重寫：

總結(jié)；

數(shù)據(jù)庫編譯器，產(chǎn)生執(zhí)行計(jì)劃，決定著【SQL】實(shí)際執(zhí)行。編譯器只是服務(wù)，數(shù)據(jù)庫的編譯器都不是完美的。

了解數(shù)據(jù)庫特性，才能揚(yáng)長避短，寫出高性能的SQL。

SQL語句不在于多復(fù)雜，簡潔清晰就好。

總結(jié)

以上是生活随笔為你收集整理的sql limit不接具体数字_SQL别再秀操作了，这么写吧还是。的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。