1、查詢語句的執(zhí)行順序

select[distinct]  
from  
join（如left join）  
on  
where  
group by  
having  
union  
order by  
limit

執(zhí)行順序: from where 聚 having order limit

1、from 先做表連接

2、where 進(jìn)行條件限制

3、然后做聚合 group by

4、然后做 having 過濾

5、然后對(duì)結(jié)果進(jìn)行排序

6、最后限制數(shù)量 limit

sql 的查詢執(zhí)行順序我想有些人還是記不住的，我的建議就是自己整理一個(gè)簡單的記憶短句，然后反復(fù)閱讀，直至記住，下次再遇到問題的時(shí)候自己回想下自己記憶的短句，能解決問題就行了，死記硬背就好，盡量簡短。

2、數(shù)據(jù)類型的選擇

• 更小的數(shù)據(jù)類型通常更好：因?yàn)楦玫拇鎯?chǔ)空間

• 簡單數(shù)據(jù)類型

• 盡量避免NULL：含NULL復(fù)合索引無效. 可為NULL的列會(huì)使用更多的存儲(chǔ)空間，在Mysql中也需要特殊處理。

TIMESTAMP空間利用比DATETIME小的多，比整形方便處理，整形不會(huì)帶來任何好處。

IPV4的地址，經(jīng)常使用VARCHAR(15)來存儲(chǔ)。然而它實(shí)際是32為無符號(hào)整數(shù)，不是字符串。用小數(shù)點(diǎn)將地址分成四段只是為了讓人們?nèi)菀组喿x。

對(duì)象關(guān)系映射（ORM）系統(tǒng)（以及使用它們的“框架”）通常都是低效的，一些ORM系統(tǒng)會(huì)存儲(chǔ)任意類型的數(shù)據(jù)到任意類型的后端數(shù)據(jù)存儲(chǔ)中。這種設(shè)計(jì)對(duì)開發(fā)者很有吸引力，因?yàn)檫@使得開發(fā)者可以用面向?qū)ο蟮姆绞焦ぷ?，不需要考慮數(shù)據(jù)是怎么存儲(chǔ)的。

原則：盡可能?。ㄕ加么鎯?chǔ)空間少）、盡可能定長（占用存儲(chǔ)空間固定）、盡可能使用整數(shù)。

3、索引優(yōu)化

主鍵索引

InnoDB通過主鍵聚集數(shù)據(jù)，數(shù)據(jù)按主鍵順序存儲(chǔ)，更新主鍵索引列的代價(jià)很高，因?yàn)闀?huì)強(qiáng)制InnoDB將每個(gè)被更新的行移動(dòng)到新的位置

多列索引

一個(gè)常見的錯(cuò)誤就是為每個(gè)列創(chuàng)建單獨(dú)的索引，這種錯(cuò)誤的認(rèn)知一般都是聽了“把where條件里面的列都建上索引”這樣模糊的建議導(dǎo)致的。

實(shí)際上，在多個(gè)列上建立獨(dú)立的索引大部分情況下都不能提高mysql的查詢性能，有時(shí)反而會(huì)使查詢變的更慢。

因?yàn)樗饕枰~外的空間記錄，在查詢到時(shí)候如果索引使用不當(dāng)，需要同時(shí)加載索引和數(shù)據(jù)，會(huì)造成查詢慢。

注意：索引列的順序

正確的順序依賴于使用該索引的查詢，并且同時(shí)需要考慮如何更好地滿足排序和分組的需要

一般性的經(jīng)驗(yàn)法則：

1、將選擇性最高的列放在最前面

2、在查詢的時(shí)候不要對(duì)索引列進(jìn)行函數(shù)操作

3、盡可能的使用索引

4、查詢性能優(yōu)化

1、查詢的生命周期

客戶端 -> 服務(wù)器查詢緩存 -> 解析器 -> 預(yù)處理器 -> 查詢優(yōu)化器-> 查詢執(zhí)行引擎 -> 存儲(chǔ)引擎 -> 數(shù)據(jù)

盡量命中緩存，盡量少讀數(shù)據(jù)，盡量少查數(shù)據(jù)。

2、SELECT語句盡量指明查詢字段名稱

• select * 會(huì)增加不必要的消耗，如果使用的字段很少，會(huì)導(dǎo)致讀取的數(shù)據(jù)量變多，網(wǎng)絡(luò)傳輸也會(huì)變慢，消耗cpu，所以 select count(1) 優(yōu)于 select count(*)
• 在表進(jìn)行修改的時(shí)候，代碼里的查詢字段可能會(huì)忘記修改，導(dǎo)致代碼報(bào)錯(cuò)，是安全隱患。

3、小表驅(qū)動(dòng)大表

盡量少的關(guān)聯(lián)數(shù)據(jù)讀取，數(shù)據(jù)量越少越快，

注意：副表不存在的數(shù)據(jù)是null

優(yōu)化數(shù)據(jù)訪問原則：

1、是否向數(shù)據(jù)庫請(qǐng)求了不需要的數(shù)據(jù)，減少數(shù)據(jù)加載和網(wǎng)絡(luò)傳輸

2、查詢是否掃描了大量不需要的記錄（返回的行數(shù)/掃描的行數(shù)），降低讀取數(shù)據(jù)的時(shí)間

總結(jié)

• 使用小而簡單的合適的數(shù)據(jù)類型，盡量避免NULL
• 避免過度設(shè)計(jì)，例如會(huì)導(dǎo)致復(fù)雜查詢的schema設(shè)計(jì)
• 合理混用范式化和反范式化設(shè)計(jì)，以空間換時(shí)間，適當(dāng)?shù)娜哂鄮硭俣?/li>
• 行訪問是很慢的，最好讀取的數(shù)據(jù)塊中能包含盡可能多所需要的行
• 按順序訪問范圍數(shù)據(jù)是很快的
• 當(dāng)數(shù)據(jù)量逐漸增大時(shí)，不恰當(dāng)?shù)乃饕龝?huì)導(dǎo)致性能急劇下降

要想寫一個(gè)好的查詢，必須要理解schema設(shè)計(jì)、索引設(shè)計(jì)等知識(shí)。他們之間環(huán)環(huán)相扣，密不可分。只有綜合考慮各方需

求，權(quán)衡利弊，才能設(shè)計(jì)出一個(gè)高性能的數(shù)據(jù)庫系統(tǒng)。

本篇文章就到這里了，希望能給你帶來幫助，也希望您能夠多多關(guān)注腳本之家的更多內(nèi)容！

最新評(píng)論