客戶端傳送sql請求給mysql伺服器
mysql伺服器會在查詢快取中進行檢查，檢視是否可以在查詢快取中命中
服務端會對sql進行解析、預處理再由優化器生成對應的執行計畫
根據執行計畫，呼叫儲存引擎中的api來查詢資料
將查詢的資料返回給客戶端，必要的時候進行快取過濾
如果查詢快取開關是開啟的會優先對快取中檢查：
這個檢查是對大小寫敏感的hash查詢實現：so，只能進行全值匹配查詢。
如果在快取中命中查詢結果，會進行角色的許可權認證，然後跳過後面的步驟把資料返回給客戶端。
1. 查詢的sql要和快取中的完全一致，所以命中並不容易。
2. 如果快取中的資料是正確的，需要每次修改表的時候進行快取的維護。
3. 而且進行快取中查詢的同時會對錶加鎖，所以對讀寫頻繁的應用，查詢快取很可能降低查詢效率（不建議開啟查詢快取）
解析sql
語法解析階段是通過關鍵字對mysql進行語法解析並生成一顆對應的解析樹
此階段，使用mysql語法規則驗證和解析查詢：檢查語法是否使用的正確的關鍵字和關鍵字的位置是否正確
預處理
預處理階段進一步的驗證檢查解析樹是否合法
此階段檢查查詢中所涉及的表和資料列是否存在及名字或者別名是否有存在歧義
優化sql執行計畫
查詢優化器生成查詢計畫
統計資訊不準確
執行計畫中的成本估算並不等於實際的執行計畫成本
mysql伺服器層並不知道哪些頁面在記憶體中，哪些頁面在磁碟中，哪些頁面順序讀，哪些頁面要隨機讀
mysql所認為的最優可能和我們所認為的最優並不一致
mysql基於其成本模型選擇最優的執行計畫
mysql不會考慮到其他的併發查詢
有時候也會基於一些固定的規則來生成執行計畫
mysql不會考慮不受其控制的成本，如：儲存過程和使用者自定義的函式
mysql會重新定義標的關聯順序
將外鏈結轉換成內連線
使用等價變換原則
可以利用索引對count(),min(),max()進行優化。如最小值 btree索引第乙個資料
將表示式轉化為乙個常數
子查詢優化：把子查詢轉換成關係查詢
會提前終止查詢：如發現不成立的條件，如屬性設定為正數，查詢條件是負數
對in()進行優化，會對in中的資料進行排序，然後進行二分查詢
profiling是從 mysql5.0.3版本以後才開放的。
啟動profile之後，所有查詢包括錯誤的語句都會記錄在內。
profile是乙個session級別的配置，關閉會話或者set profiling=0 就關閉了。（如果將profiling_history_size引數設定為0，同樣具有關閉mysql的profiling效果。）
show profiles
show profile for query n 查詢每個階段所消耗的時間
5.5之後使用performance_schma
SQL查詢速度的體會 時間範圍的影響
寫了個查詢軟體,要求的功能比較大,所以設計了兩個資料庫,多個表之間的運算,都通過,在開發的電腦上,查詢乙個月內的資料都是很快的速度出來,但拿到現場測試,發現如果查詢多個月的資料,沒有資料出來,偶爾會有一兩次資料出來.因為測試時間,是伺服器忙時,就是很多使用者同時在使用另外乙個查詢軟體在工作,所以伺服...
sql查詢語句速度
查詢一張百萬資料量的資料庫表，已經建立了索引 flowno。因為匯出日誌備份需要，要求根據flowno的值取出資料。即，select部分的語句如下 對比了以下三種where查詢子句的執行速度 1.where t.flowno between 2017031400 and 2017031410 查詢1...
SQL優化 加快查詢速度
建檢視的時候，盡量避免檢視中呼叫檢視，直接使用表更快些 盡量避免 select from 表名 這種語法，查那個欄位就直接寫哪個字段，如 select id,code from 表名 因為這個 代表的字段可能會很多，你如果不需要也查出來，既浪費時間，有沒用 可以建乙個讀的表，乙個寫的表，定時將實時表...