小睿從這一篇章開始說一說具體的sql語句的優化，希望大家可以在這乙個篇章裡面找到編寫sql語句的感覺，也會在這裡闡述一下為什麼有些語句要這樣子寫才能把效率提高上來。這乙個章節並沒有什麼系統化的東西，基本上都是本人平時在工作裡面的積累，所以讀起來可能會比較散，不過這不會影響大家對於sql語句優化的了解。
問題一：
很多程式設計師在編寫sql的時候忽略了join，而使用了子查詢，其實這樣子是比較低效的做法。子查詢在mysql5.5版本裡，內部執行計畫器是這樣執行的：先查外表再匹配內錶，而不是先查內錶t2，當外表的資料很大時，查詢速度會非常慢。
例如：select * from record_maintable where mainid in (select id from record_maininformation);
優化後：
select * from record_maintable a left join record_maininformation b on b.id=a.mainid
我們執行了兩條語句對比發現，子查詢語句執行時間0.022s，優化後的語句執行時間0.003s，優化後的效率明顯比優化前高了好幾倍。當資料量越大的時候這種優化會更明顯。所以在這裡作者建議大家，可以用join的千萬不要用子查詢的方案。
問題二：
有很多程式設計師在多條件查詢的時候喜歡用or，不過筆者在這裡提醒一下的是，當你的語句的條件是同乙個欄位的時候，用in去代替or執行的效率會更加的高喔。
例如：select * from record_maintable where id=131 or id=139 or id=140
優化後：
select * from record_maintable where id in (131,139,140)
我們對比了同乙個字段作為條件，用or與用in的區別是有多大了。用or的執行效率不僅慢，而且對於接受你**的那個小夥伴來說，**更加難看懂。所以當滿足上述調條件的情況下，作者更加推薦大家使用in。效率更高，而且使得**更加美觀。
問題三：
很多人經常說，我的資料表裡面已經新增了索引，為什麼用起來的速度沒有發生變化呢？答案是因為你們在搜尋的時候用了左側百分號。資料庫一般都是字首索引，所以支援模糊匹配在後面。因此你如果模糊搜尋用了雙百分號，索引就起不到作用，也就不能提高執行效率了。
我們現在做乙個實驗吧，有一張資料表已經加上了id索引了。我們對比一下雙百分號與右側百分號的區別吧。
語句1：
select * from record_maintable where id like 『%1%』;
語句2：
select * from record_maintable where id like 『1%』;
從實驗裡面看雙百分號的語句確實是沒用使用到索引，因此效率比右側百分號的模糊搜尋速度要慢。在這裡作者倡導大夥們，當你的資料表裡面已經有了索引的時候，而且資料表中的資料比較多的時候，盡可能使用右側百分號吧。這樣子你能把執行效率提高乙個檔次。
問題四：
例如：select * from record_maintable where id=131
優化後：
select * from record_maintable where id=131 limit 1
結果顯而易見，加了limit的並沒有做全文搜尋因此效率會更高一些。
問題五：
很多程式設計師的插入語句分多條寫，其實這樣子的執行效率並不夠單條插入語句高。所以在這裡我推薦盡量使用一條語句插入的方法。
例如：insert into record_tokenaddress (path,createts) values (『123/123』,』2018-11-24 18:13:38』);
insert into record_tokenaddress (path,createts) values (『456/456』,』2018-11-24 18:13:38』);
insert into record_tokenaddress (path,createts) values (『789/789』,』2018-11-24 18:13:38』);
優化後：
insert into record_tokenaddress (path,createts) values (『123/123』,』2018-11-24 00:00:00』),(『456/456』,』2018-11-24 00:00:00』),(『789/789』,』2018-11-24 00:00:00』);
大家看一下就知道了，執行多條語句跟執行一條語句的差距還是挺大的。所以在寫sql的時候也要好好考慮好這個問題了。
總結：sql語句這裡的優化我就用了5個例子表明sql的編寫要注重好細節，多看看文件，多試試其他的寫法，慢慢寫多了，積累多了就能夠寫出更加好的sql了。這裡的sql優化並沒有捷徑可走，必須靠自己一步乙個腳印去積累吧。其實我在工作中對於sql的優化還是有一定的積累。但是也沒有全部展示出來，因為實際情況要實際分析，不能生搬硬套。還是強調一下，多看看文件，多動動手試試不同的寫法，你將會獲益良多！
mysql 語句優化例項 MySQL 語句優化例項
優化 limit 分頁 執行耗時 1.379s select from vio basic domain info limit 1000000,10 處理分頁慢查詢的方式一般有以下幾種 思路一 構造覆蓋索引 思路二 優化 offset 無法用上覆蓋索引，那麼重點是想辦法快速過濾掉前 100w 條資料...
mysql語句優化原則 MySQL語句優化的原則
1 使用索引來更快地遍歷表。預設情況下建立的索引是非群集索引，但有時它並不是最佳的。在非群集索引下，資料在物理上隨機存放在資料頁上。合理的索引設計要建立在對各種查詢的分析和 上。一般來說 a.有大量重複值 且經常有範圍查詢 和order by group by發生的列，可考慮建立群集索引 b.經常同...
mysql語句優化原則 mysql語句優化原則
有時候發現資料量大的時候查詢起來效率就比較慢了，學習一下mysql語句優化的原則，自己在正常寫sql的時候還沒注意到這些，先記錄下來，慢慢一點一點的學，加油！這幾篇部落格寫的都可以 使用索引的原則 1.最左字首匹配原則。mysql會一直向右匹配直到遇到範圍查詢 不會用到b的索引 where a 1 ...