連接查詢時沒走索引

沒走索引的情況有很多，一般看下執行計划，都能找到問題所在。

這里講下我所遇到的問題，由於  字段類型，字符集，排序規則等不一致，造成的。改成一樣即可。連接字段d.id  ,w.bussiness_id。

多人合作開發一定要制定相關開發規范，不然就會出現這類問題。

 

 

 

 

 

 

 

 

 

 

1.utf8與utf8mb4（utf8 most bytes 4）

• MySQL 5.5.3之后增加了utfmb4字符編碼
• 支持BMP（Basic Multilingual Plane，基本多文種平面）和補充字符
• 最多使用四個字節存儲字符

utf8mb4是utf8的超集並完全兼容utf8，能夠用四個字節存儲更多的字符。

標准的UTF-8字符集編碼是可以使用1-4個字節去編碼21位字符，這幾乎包含了世界上所有能看見的語言。
MySQL里面實現的utf8最長使用3個字符，包含了大多數字符但並不是所有。例如emoji和一些不常用的漢字，如“墅”，這些需要四個字節才能編碼的就不支持。

2.字符集、連接字符集、排序字符集

utf8mb4對應的排序字符集有utf8mb4_unicode_ci、utf8mb4_general_ci.

utf8mb4_unicode_ci和utf8mb4_general_ci的對比：

• 准確性：
  • utf8mb4_unicode_ci是基於標准的Unicode來排序和比較，能夠在各種語言之間精確排序
  • utf8mb4_general_ci沒有實現Unicode排序規則，在遇到某些特殊語言或者字符集，排序結果可能不一致。
  • 但是，在絕大多數情況下，這些特殊字符的順序並不需要那么精確。
• 性能
  • utf8mb4_general_ci在比較和排序的時候更快
  • utf8mb4_unicode_ci在特殊情況下，Unicode排序規則為了能夠處理特殊字符的情況，實現了略微復雜的排序算法。
  • 但是在絕大多數情況下發，不會發生此類復雜比較。相比選擇哪一種collation，使用者更應該關心字符集與排序規則在db里需要統一。

 

 

什么時候用索引？

索引是建立在數據庫表中的某些列的上面。在創建索引的時候，應該考慮在哪些列上可以創建索引，在哪些列上不能創建索引。一般來說，應該在這些列上創建索引：

在經常需要搜索的列上，可以加快搜索的速度；

在作為  主鍵的列上，強制該列的唯一性和組織表中數據的排列結構；

在經常用在連接的列上，這些列主要是一些  外鍵，可以加快連接的速度；在經常需要根據范圍進行搜索的列上創建索引，因為索引已經排序，其指定的范圍是連續的；

在經常需要排序的列上創建索引，因為索引已經排序，這樣查詢可以利用索引的排序，加快排序查詢時間；

在經常使用在WHERE子句中的列上面創建  索引，加快條件的判斷速度。

 

同樣，對於有些列不應該創建索引。一般來說，不應該創建索引的這些列具有下列特點：

第一，對於那些在查詢中很少使用或者參考的列不應該創建索引。這是因為，既然這些列很少使用到，因此有索引或者無索引，並不能提高查詢速度。相反，由於增加了索引，反而降低了系統的維護速度和增大了空間需求。

第二，對於那些只有很少數據值的列也不應該增加索引。這是因為，由於這些列的取值很少，例如人事表的性別列，在查詢的結果中，  結果集的數據行占了表中數據行的很大比例，即需要在表中搜索的數據行的比例很大。增加  索引，並不能明顯加快檢索速度。

第三，對於那些定義為text, image和  bit數據類型的列不應該增加索引。這是因為，這些列的數據量要么相當大，要么取值很少,不利於使用索引。

第四，當修改性能遠遠大於檢索性能時，不應該創建索引。這是因為，修改性能和檢索性能是互相矛盾的。當增加索引時，會提高檢索性能，但是會降低修改性能。當減少索引時，會提高修改性能，降低檢索性能。因此，當修改操作遠遠多於檢索操作時，不應該創建索引。

 

 

EXPLAIN簡介

　　EXPLAIN 命令是查看查詢優化器如何決定執行查詢的主要方法,使用EXPLAIN,只需要在查詢中的SELECT關鍵字之前增加EXPLAIN這個詞即可,MYSQL會在查詢上設置一個標記,當執行查詢時,這個標記會使其返回關於在執行計划中每一步的信息,而不是執行它,它會返回一行或多行信息,顯示出執行計划中的每一部分和執行的次序,從而可以從分析結果中找到查詢語句或是表結構的性能瓶頸。

EXPLAIN能干嘛

1. 分析出表的讀取順序
2. 數據讀取操作的操作類型
3. 哪些索引可以使用
4. 哪些索引被實際使用
5. 表之間的引用
6. 每張表有多少行被優化器查詢    

EXPLAIN如何用

Explain + SQL語句即可,如下:

explain select * from tbl_dept; 

EXPLAIN結果參數含義

1.id:  id代表執行select子句或操作表的順序,例如,上述的執行結果代表只有一次執行而且執行順序是第一(因為只有一個id為1的執行結果),id分別有三種不同的執行結果,分別如下:

• id相同,執行順序由上至下

• id不同,如果是子查詢,id的序號會遞增,id值越大,優先級越高,越先被執行

• id相同和不同,同時存在,遵從優先級高的優先執行,優先級相同的按照由上至下的順序執行

2.select_type
　　查詢的類型,主要用於區別普通查詢,聯合查詢,子查詢等復雜查詢

• simple: 簡單的select查詢,查詢中不包含子查詢或union查詢
• primary: 查詢中若包含任何復雜的子部分,最外層查詢則被標記為primary
• subquery 在select 或where 列表中包含了子查詢
• derived 在from列表中包含的子查詢被標記為derived,mysql會遞歸這些子查詢,把結果放在臨時表里
• union 做第二個select出現在union之后,則被標記為union,若union包含在from子句的子查詢中,外層select將被標記為derived
• union result 從union表獲取結果的select

3.table
　　顯示一行的數據時關於哪張表的
4.type
　　查詢類型從最好到最差依次是:system>const>eq_ref>ref>range>index>All,一般情況下,得至少保證達到range級別,最好能達到ref

• system:表只有一行記錄,這是const類型的特例,平時不會出現
• const:表示通過索引一次就找到了,const即常量,它用於比較primary key或unique索引,因為只匹配一行數據,所以效率很快,如將主鍵置於where條件中,mysql就能將該查詢轉換為一個常量 

• eq_ref:唯一性索引掃描,對於每個索引鍵,表中只有一條記錄與之匹配,常見於主鍵或唯一索引掃描
• ref:非唯一性索引掃描,返回匹配某個單獨值的行,它可能會找到多個符合條件的行,所以他應該屬於查找和掃描的混合體
• range:只檢索給定范圍的行,使用一個索引來選擇行,如where語句中出現了between,<,>,in等查詢,這種范圍掃描索引比全表掃描要好，因為它只需要開始於索引的某一點，而結束於另一點，不用掃描全部索引。
• index:index類型只遍歷索引樹,這通常比All快,因為索引文件通常比數據文件小,index是從索引中讀取,all從硬盤中讀取
• all:全表掃描,是最差的一種查詢類型

5.possible_keys
　　顯示可能應用在這張表中的索引,一個或多個,查詢到的索引不一定是真正被用到的

6.key
　　實際使用的索引,如果為null,則沒有使用索引,因此會出現possible_keys列有可能被用到的索引,但是key列為null,表示實際沒用索引。

7.key_len
　　表示索引中使用的字節數,而通過該列計算查詢中使用的 索引長度,在不損失精確性的情況下,長度越短越好,key_len顯示的值為索引字段的最大可能長度,並非實際使用長度,即,key_len是根據表定義計算而得么不是通過表內檢索出的

8.ref
　　顯示索引的哪一列被使用了,如果可能的話是一個常數,哪些列或常量被用於查找索引列上的值

9.rows
　　根據表統計信息及索引選用情況,大只估算出找到所需的記錄所需要讀取的行數

10.Extra

• Using filesort:說明mysql會對數據使用一個外部的索引排序,而不是按照表內的索引順序進行讀取,mysql中無法利用索引完成的排序操作稱為"文件排序"
• Using temporary :使用了臨時表保存中間結果,mysql在對查詢結果排序時使用臨時表,常見於order by和分組查詢group by
• Using index:表示相應的select操作中使用了覆蓋索引（Covering Index），避免訪問了表的數據行，效率不錯。如果同時出現using where，表明索引被用來執行索引鍵值的查找；如果沒有同時出現using where，表明索引用來讀取數據而非執行查找動作。 其中的覆蓋索引含義是所查詢的列是和建立的索引字段和個數是一一對應的
• Using where:表明使用了where過濾
• Using join buffer:表明使用了連接緩存,如在查詢的時候會有多次join,則可能會產生臨時表
• impossible where:表示where子句的值總是false,不能用來獲取任何元祖。如下例：

select * from t1 where id='1' and id='2';

• select tables optimized away

在沒有GROUPBY子句的情況下，基於索引優化MIN/MAX操作或者對於MyISAM存儲引擎優化COUNT(*)操作，不必等到執行階段再進行計算，查詢執行計划生成的階段即完成優化。

• distinct：優化distinct操作，在找到第一匹配的元組后即停止找同樣值的動作，即一旦MySQL找到了與行相聯合匹配的行，就不再搜索了。

重點：

　　type：訪問類型，查看SQL到底是以何種類型訪問數據的。

　　key：使用的索引，MySQL用了哪個索引，有時候MySQL用的索引不是最好的，需要force index()。

　　rows：最大掃描的列數。

　　extra：重要的額外信息，特別注意損耗性能的兩個情況，using filesort和using temporary。

 

附出處：https://blog.csdn.net/zh15732621679/article/details/80394790#commentBox

 

mysql的執行順序

一、mySql的執行順序

mysql執行sql的順序從 From 開始，以下是執行的順序流程

1、FROM  table1 left join table2 on 將table1和table2中的數據產生笛卡爾積，生成Temp1

2、JOIN table2  所以先是確定表，再確定關聯條件

3、ON table1.column = table2.columu 確定表的綁定條件 由Temp1產生中間表Temp2

4、WHERE  對中間表Temp2產生的結果進行過濾  產生中間表Temp3

5、GROUP BY 對中間表Temp3進行分組，產生中間表Temp4

6、HAVING  對分組后的記錄進行聚合 產生中間表Temp5

7、SELECT  對中間表Temp5進行列篩選，產生中間表 Temp6

8、DISTINCT 對中間表 Temp6進行去重，產生中間表 Temp7

9、ORDER BY 對Temp7中的數據進行排序，產生中間表Temp8

10、LIMIT 對中間表Temp8進行分頁，產生中間表Temp9

 

https://blog.csdn.net/csndhu/article/details/88176564