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 進行條件限制

3、然后做聚合 group by

4、然后做 having 過濾

5、然后對結(jié)果進行排序

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

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

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

• 更小的數(shù)據(jù)類型通常更好：因為更好的存儲空間

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

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

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

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

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

原則：盡可能小（占用存儲空間少）、盡可能定長（占用存儲空間固定）、盡可能使用整數(shù)。

3、索引優(yōu)化

主鍵索引

InnoDB通過主鍵聚集數(shù)據(jù)，數(shù)據(jù)按主鍵順序存儲，更新主鍵索引列的代價很高，因為會強制InnoDB將每個被更新的行移動到新的位置

多列索引

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

實際上，在多個列上建立獨立的索引大部分情況下都不能提高mysql的查詢性能，有時反而會使查詢變的更慢。

因為索引需要額外的空間記錄，在查詢到時候如果索引使用不當，需要同時加載索引和數(shù)據(jù)，會造成查詢慢。

注意：索引列的順序

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

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

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

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

3、盡可能的使用索引

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

1、查詢的生命周期

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

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

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

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

3、小表驅(qū)動大表

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

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

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

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

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

總結(jié)

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

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

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

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

最新評論