SQL怎么優(yōu)化

這篇文章將為大家詳細(xì)講解有關(guān)SQL怎么優(yōu)化，小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考，希望大家閱讀完這篇文章后可以有所收獲。

為什么要優(yōu)化

系統(tǒng)的吞吐量瓶頸往往出現(xiàn)在數(shù)據(jù)庫的訪問速度上，即隨著應(yīng)用程序的運(yùn)行，數(shù)據(jù)庫的中的數(shù)據(jù)會(huì)越來越多，處理時(shí)間會(huì)相應(yīng)變慢，且數(shù)據(jù)是存放在磁盤上的，讀寫速度無法和內(nèi)存相比

如何優(yōu)化

1、設(shè)計(jì)數(shù)據(jù)庫時(shí)：數(shù)據(jù)庫表、字段的設(shè)計(jì)，存儲(chǔ)引擎

2、利用好MySQL自身提供的功能，如索引，語句寫法的調(diào)優(yōu)

3、MySQL集群、分庫分表、讀寫分離

關(guān)于SQL語句的優(yōu)化的方法方式，網(wǎng)絡(luò)有很多經(jīng)驗(yàn)，所以本文拋開這些，設(shè)法在DAO層的優(yōu)化和數(shù)據(jù)庫設(shè)計(jì)優(yōu)化上建樹，并列舉兩個(gè)簡單實(shí)例

例子1：ERP查詢優(yōu)化

現(xiàn)狀分析：

1、缺少關(guān)聯(lián)索引
2、Mysql本身的性能所限，對多個(gè)表的關(guān)聯(lián)支持不好，目前的性能主要集中在列表查詢上面，列表查詢關(guān)聯(lián)了很多表

應(yīng)對方法：

1 增加必要的索引：通過explain查看執(zhí)行記錄，根據(jù)執(zhí)行計(jì)劃添加索引；
2 先統(tǒng)計(jì)業(yè)務(wù)數(shù)據(jù)主表主鍵，獲取較小結(jié)果集，然后再利用結(jié)果集關(guān)聯(lián)查詢；
1） 先根據(jù)主表和條件查詢顯示業(yè)務(wù)數(shù)據(jù)的主鍵
2） 根據(jù)主鍵作為查詢條件，再關(guān)聯(lián)其他關(guān)聯(lián)表，查詢需要的業(yè)務(wù)字段
3） 在主表查詢時(shí)，針對需要關(guān)聯(lián)其他表的查詢條件，需要做只有設(shè)置這個(gè)條件，才會(huì)做表關(guān)聯(lián)的設(shè)置

例如 有如下表 TT_A   TT_B    TT_C  TT_D

假設(shè)未優(yōu)化前的SQL是這樣的

SELECT
    A.ID,
    ....
    B.NAME,
    .....
    C.AGE,
    ....
    D.SEX
    .....

FROM  TT_A A
LEFT JOIN TT_B B ON A.ID  = B.ITEM_ID
LEFT JOIN TT_C C ON B.ID = C.ITEM_ID
LEFT JOIN TT_D D ON C.ID = D.ITEM_ID
WHERE 1=1AND A.XX = ?AND A.VV = ?.....

那么優(yōu)化后的SQL是

第一步

SELECT
    A.ID

FROM  TT_A A
WHERE 1=1AND A.XX = ?AND A.VV = ?第二步

SELECT
    A.ID,
    ....
    B.NAME,
    .....
    C.AGE,
    ....
    D.SEX
    .....
FROM  ( SELECT A.ID,..... FROM  TT_A  WHERE ID IN (1,2,3..)  ) A
LEFT JOIN TT_B B ON A.ID  = B.ITEM_ID
LEFT JOIN TT_C C ON B.ID = C.ITEM_ID
LEFT JOIN TT_D D ON C.ID = D.ITEM_ID
WHERE 1=1AND A.XX = ?AND A.VV = ?

小結(jié)：

這種優(yōu)化適用于，列表查詢，因?yàn)橐粋€(gè)列表查詢的條件一般都是和主表掛鉤的，所以利用這一點(diǎn)，建立關(guān)鍵字段索引，同時(shí)通過查詢條件的限制大大的縮小主表的數(shù)據(jù)量。這樣關(guān)聯(lián)其他表的時(shí)候就會(huì)快的多

例子2：文章搜索優(yōu)化

假設(shè)你要做個(gè)貼吧的文章搜索功能，最簡單直接的存儲(chǔ)結(jié)構(gòu)，就是利用關(guān)系數(shù)據(jù)庫，創(chuàng)建這樣一個(gè)存儲(chǔ)文章的關(guān)系數(shù)據(jù)庫表 TT_ARTICLES：

那么，假如現(xiàn)在的搜索關(guān)鍵字是“目標(biāo)”，我們就可以利用字符串匹配的方式來對 CONTENT 列進(jìn)行匹配查詢：

select * from ARTICLES where CONTENT like '% 目標(biāo) %';

這很容易就實(shí)現(xiàn)了搜索功能。但是，這樣的方式有著明顯的問題，即使用 % 來進(jìn)行字符串匹配是非常低效的，因此這樣的查詢需要遍歷整個(gè)表（全表掃描）。幾篇、幾十篇文章的時(shí) 候，還不是什么問題，但是如果有幾十萬、幾百萬的文章，這種方式是完全不可行的。且不說單獨(dú)的關(guān)系數(shù)據(jù)庫表就不能容納那么大的數(shù)據(jù)了，就是能夠容納，要掃描一遍，這里的時(shí)間代價(jià)是難以想象的

于是，我們就要引入“倒排索引”的技術(shù)了。在前面所述的場景下， 我們可以把這個(gè)概念拆分為兩個(gè)部分來解釋： 好，那上面的 ARTICLES 表依然存在，但現(xiàn)在需要添加一個(gè)關(guān)鍵字表 KEYWORDS，并且，KEYWORD 列需要添加索引，因此這條關(guān)鍵字的記錄可以被迅速找到：

當(dāng)然，我們還需要一個(gè)關(guān)聯(lián)關(guān)系表把 KEYWORDS 表和 ARTICLES 表結(jié)合起來， KEYWORD_ID 和 ARTICLE_ID 作為聯(lián)合主鍵

你看，這其實(shí)是一個(gè)多對多的關(guān)系，即同一個(gè)關(guān)鍵字可以出現(xiàn)在多篇文章中，而一篇文章可 以包含多個(gè)不同的關(guān)鍵字。這樣，我們可以先根據(jù)被索引了的關(guān)鍵字，從 KEYWARDS 表 中找到相應(yīng)的 KEYWORD_ID，進(jìn)而根據(jù)它在上面的關(guān)聯(lián)關(guān)系表找到 ARTICLE_ID，再根據(jù) 它去 ARTICLES 表中找到對應(yīng)的文章。

小結(jié)：

這看起來是三次查找，但是因?yàn)槊看味甲咚饕兔馊チ巳頀呙?，在?shù)據(jù)量較小的時(shí)候速 度并不慢，并且，在使用 SQL 實(shí)現(xiàn)的時(shí)候，這個(gè)過程完全可以放到一個(gè) SQL 語句中。在數(shù) 據(jù)量較小的時(shí)候，上面的方法已經(jīng)足夠好用了。 這樣解決了全表掃描和字符串 % 匹配查詢造成的性能問題。

總結(jié)：

在技術(shù)面試的時(shí)候，如果你能舉出實(shí)際的例子，或者是直接說自己開發(fā)過程的問題和收獲會(huì)讓面試分會(huì)加很多，回答邏輯性也要強(qiáng)一點(diǎn)，不要東一點(diǎn)西一點(diǎn)，容易把自己都繞暈的。例如，問為怎么優(yōu)化SQL你不要一上來就直接回答加索引，你可以這樣回答：

面試官您好，首先我們的項(xiàng)目DB數(shù)據(jù)量遇到了瓶頸，導(dǎo)致列表查詢非常緩慢，給用戶的體驗(yàn)不好，為了解決這個(gè)問題，有很多種方法，例如最基本的數(shù)據(jù)庫表設(shè)計(jì)，基本的SQL優(yōu)化，MYSQL的集群，讀寫分離，分庫分表，架構(gòu)上增加緩存層等，他們的優(yōu)缺點(diǎn)……，綜合這些然后再結(jié)合我們項(xiàng)目特點(diǎn)，最后我們在技術(shù)選型的時(shí)候選了誰。

如果你這樣有條不紊，有理有據(jù)的回答了問題而且還說出這么多問題外的知識點(diǎn)，面試官會(huì)覺得你不只是一個(gè)會(huì)寫代碼的人，而是你邏輯清晰，你對技術(shù)選型，有自己的理解和思考

關(guān)于SQL怎么優(yōu)化就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。