本文首發(fā)于個(gè)人微信公眾號(hào)《andyqian》，期待你的關(guān)注

前言

有好幾天沒有寫文章了，實(shí)在不好意思。之前就有朋友希望我寫寫MySQL優(yōu)化的文章。我遲遲沒有動(dòng)筆，主要是因?yàn)?#xff0c;SQL優(yōu)化這個(gè)東西，很廣，技巧也很多。自己在SQL優(yōu)化方面的知識(shí)又還很欠缺。總覺得還不到分享的。思考許久，還是寫一篇文章，記錄一下。就算是拋磚引玉吧！

SQL優(yōu)化

SQL優(yōu)化是一個(gè)分析，優(yōu)化，再分析，再優(yōu)化的過程。站在執(zhí)行計(jì)劃的角度來(lái)說(shuō)，我們這個(gè)過程，就是在不斷的減少rows的數(shù)量。主要步驟有:

通過explain 來(lái)查看執(zhí)行計(jì)劃。通過這一步驟，我們能夠分析出，該語(yǔ)句有沒有走索引，索引合不合理的重要依據(jù)。《讀懂MySQL執(zhí)行計(jì)劃》

縮小范圍。例如使用 < > ，between …and。來(lái)縮小掃描范圍。

(對(duì)于該類，通常可優(yōu)化于limit，時(shí)間范圍等SQL，而且非常有效)。

減少連接數(shù)量 (對(duì)于連接查詢，我們必須盡可能減少每個(gè)子連接的結(jié)果集數(shù)量，只包含有效數(shù)據(jù))。

避免類型轉(zhuǎn)換。

之前我們就談過，隱式類型轉(zhuǎn)換是最容易疏忽的慢SQL。如何避免？大家可以參考之前的文章《談?wù)凪ySQL隱式類型轉(zhuǎn)換》。

對(duì)于主鍵連續(xù)時(shí)而且允許的情況下，我們甚至可以使用max(id)來(lái)代替count(*)來(lái)統(tǒng)計(jì)用戶數(shù)。

用 in 代替 or， 少用like，避免使用函數(shù)運(yùn)算。

系統(tǒng)拆分

對(duì)于互聯(lián)網(wǎng)應(yīng)用，特別是高并發(fā)應(yīng)用來(lái)說(shuō)，我們遇到多表連接導(dǎo)致慢SQL影響性能時(shí)。我們不應(yīng)一味的追求在SQL上如何優(yōu)化。更應(yīng)該考慮這樣的設(shè)計(jì)是否合理，是否有拆分的可能性。所以，

我甚至認(rèn)為：系統(tǒng)拆分才是解決慢SQL的終極方法。

報(bào)表庫(kù)

其實(shí)呀，有些SQL是無(wú)法再進(jìn)行優(yōu)化的，為什么這么說(shuō)呢？沒有在線運(yùn)算，沒有離線運(yùn)算，統(tǒng)計(jì)報(bào)表如何出？在一定量級(jí)的數(shù)據(jù)表中，做統(tǒng)計(jì)報(bào)表。即使合理的索引，也會(huì)比較慢，這時(shí)建議將這些SQL放入特定的報(bào)表庫(kù)執(zhí)行。以免造成主庫(kù)壓力。性能下降。對(duì)主流程造成影響。

結(jié)語(yǔ)

SQL優(yōu)化是一個(gè)比較廣的話題且非常有意思的話。這篇文章主要給的是一些優(yōu)化思路，不足的是并沒有給出更多的優(yōu)化實(shí)例。等攢夠了優(yōu)化實(shí)例，會(huì)再次分享出來(lái)。

最后：在留言區(qū)也分享一下你們SQL優(yōu)化的思路唄～

相關(guān)閱讀:

掃碼關(guān)注，一起進(jìn)步

總結(jié)

以上是生活随笔為你收集整理的谈谈mysql优化_浅谈MySQL SQL优化的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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