零.索引簡介
1. 索引是什么
①MySQL官方對索引的定義是：索引(Index)是幫助MySQL高效獲取數(shù)據(jù)的數(shù)據(jù)結構螃成。
②可以簡單的理解為“排好序的快速查找數(shù)據(jù)結構”。
③除了數(shù)據(jù)本身之外督惰，數(shù)據(jù)庫還維護著一個滿足特定查找算法的數(shù)據(jù)結構采呐，這種數(shù)據(jù)結構以某種方式指向數(shù)據(jù)沛婴，這樣就可以在這些數(shù)據(jù)結構的基礎上實現(xiàn)高級查找算法吼畏，這種數(shù)據(jù)結構就是索引。
④一般來說索引本身也很大嘁灯，不可能全部存儲在內(nèi)存中泻蚊，因此索引往往以索引文件的形式存儲在磁盤上。
⑤我們平常所說的索引丑婿，如果沒有特別說明性雄，都是值B+樹結構組織的索引。其中聚集索引羹奉，稀疏索引秒旋、覆蓋索引、復合索引诀拭、前綴索引迁筛、唯一索引，默認都使用B+樹索引耕挨，統(tǒng)稱索引细卧。當然除了B+樹之外還有哈希索引、BitMap索引等筒占。
2.索引的優(yōu)勢
①類似圖書的目錄索引贪庙，提高了數(shù)據(jù)檢索的效率，降低數(shù)據(jù)庫的IO成本翰苫。
②通過索引對數(shù)據(jù)進行排序止邮，降低數(shù)據(jù)排序的成本这橙，降低了CPU的消耗。
3.索引的劣勢
①實際上索引也是一張表导披，該表保存了主鍵與索引字段屈扎，并指向實體表的記錄，所以索引也是要占用空間的撩匕。
②雖然索引大大提高了查詢速度助隧，同時卻會降低更新表的數(shù)據(jù)，如對表進行INSERT滑沧、UPDATE、DELETE巍实。因為更新表時滓技，MySQL不僅要保存數(shù)據(jù)，還要保存一下索引文件棚潦；每次更新添加了索引列的字段令漂，都會調(diào)整因為更新所帶來的鍵值變化后的索引信息。
③索引只是提高效率的一個因素丸边，如果你的MySQL有大數(shù)據(jù)量的表叠必，就需要花費時間研究建立最優(yōu)的索引∶媒眩或者優(yōu)化查詢語句纬朝。
4.索引的分類
①單值索引：一個索引包含單個列，一個表可以有多個單列索引骄呼。
②唯一索引：索引列的值必須唯一共苛，但允許有空值。
③復合索引：一個索引包含多個列蜓萄。
一.使用二叉查找樹作為索引存在的問題
二叉查找樹（Binary Search Tree）隅茎，（又：二叉搜索樹，二叉排序樹）它或者是一棵空樹嫉沽，或者是具有下列性質的二叉樹： 若它的左子樹不空辟犀，則左子樹上所有結點的值均小于它的根結點的值； 若它的右子樹不空绸硕，則右子樹上所有結點的值均大于它的根結點的值堂竟； 它的左、右子樹也分別為二叉排序樹臣咖。
如上面的圖所示跃捣，它存在的問題如下：
①如果數(shù)據(jù)太多而且大量數(shù)據(jù)單調(diào)，那么二叉搜索樹就會在一條分支上一直進行延伸夺蛇，這樣基本就由二叉搜索樹變成了線性表疚漆，搜索效率就會大大下降。
②一個節(jié)點只能存儲一個值，數(shù)據(jù)量太大的時候就會一顆高度特別高的二叉樹娶聘，這樣搜索效率就會出現(xiàn)大幅下降闻镶。
③使用平衡二叉搜索樹，雖然可以防止編程線性表丸升，但是每次更新索引都會樹的旋轉铆农，這樣就會消耗特別大的性能，而且一個節(jié)點還是只能保存一個值狡耻，無法解決樹過高的問題墩剖。
二.使用B樹作為索引存在的問題
一棵m階B樹(balanced tree of order m)是一棵平衡的m路搜索樹。它或者是空樹夷狰，或者是滿足下列性質的樹：
1岭皂、根結點至少有兩個子女；
2沼头、每個非根節(jié)點所包含的關鍵字個數(shù) j 滿足：┌m/2┐ - 1 <= j <= m - 1爷绘；
3、除根結點以外的所有結點（不包括葉子結點）的度數(shù)正好是關鍵字總數(shù)加1进倍，故內(nèi)部子樹個數(shù) k 滿足：┌m/2┐ <= k <= m 土至；
4、所有的葉子結點都位于同一層猾昆。
在B-樹中陶因，每個結點中關鍵字從小到大排列，并且當該結點的孩子是非葉子結點時毡庆，該k-1個關鍵字正好是k個孩子包含的關鍵字的值域的分劃坑赡。
①相比二叉樹，他一個節(jié)點可以容納多個節(jié)點么抗，可以降低樹的高度毅否，增加查找效率。
②但是一層能容納的數(shù)量還是太少蝇刀，數(shù)據(jù)量一大樹的高度也會變得很高螟加，搜索效率一樣會進行大幅度的下降。
③一個節(jié)點能存放的數(shù)據(jù)要比指針少一吞琐，數(shù)據(jù)保存率太低
三.使用B+樹作為索引
B+ 樹是一種樹數(shù)據(jù)結構捆探，通常用于數(shù)據(jù)庫和操作系統(tǒng)的文件系統(tǒng)中。B+ 樹的特點是能夠保持數(shù)據(jù)穩(wěn)定有序站粟，其插入與修改擁有較穩(wěn)定的對數(shù)時間復雜度黍图。B+ 樹元素自底向上插入，這與二叉樹恰好相反奴烙。
B+ 樹在節(jié)點訪問時間遠遠超過節(jié)點內(nèi)部訪問時間的時候助被，比可作為替代的實現(xiàn)有著實在的優(yōu)勢剖张。這通常在多數(shù)節(jié)點在次級存儲比如硬盤中的時候出現(xiàn)。通過最大化在每個內(nèi)部節(jié)點內(nèi)的子節(jié)點的數(shù)目減少樹的高度揩环，平衡操作不經(jīng)常發(fā)生搔弄，而且效率增加了蚊逢。這種價值得以確立通常需要每個節(jié)點在次級存儲中占據(jù)完整的磁盤塊或近似的大小卵皂。
如圖是一個B+樹，這時候如果我們要查詢46這個節(jié)點绿贞，那么只需要在第一節(jié)點中進行查找褒墨，發(fā)現(xiàn)46在45和67之間炫刷，然后如何就走第二個節(jié)點，走到了（45,48,63）這個節(jié)點郁妈，然后發(fā)現(xiàn)46在45-48之間柬唯，走第一個節(jié)點，如何遍歷圃庭，就找到了46。
①使用B+樹失晴，一個節(jié)點可以存儲的值和它指向一下個節(jié)點的指針一樣多剧腻，可以多存儲數(shù)據(jù)。
②所有父節(jié)點的數(shù)據(jù)同時也保存在子節(jié)點之中涂屁，這樣所有數(shù)據(jù)都在一起书在，比較連續(xù)。
③葉子節(jié)點的所有值由一個鏈表進行連接拆又，這樣如果進行范圍查詢就非常簡單儒旬，只需順著鏈表往下走就行。
四.Hash和BitMap索引
1.Hash索引
Hash索引是指帖族，將要創(chuàng)建索引的字段值進行hash栈源，按照hash值為key，數(shù)據(jù)地址為value竖般，保存成為一個HashMap結構甚垦，如果一個hash值對應多個行數(shù)據(jù)，就進行鏈表存儲涣雕。
①使用hash只需要進行一次hash就可以查找到值艰亮，不需要進行像二叉樹一樣的逐層查找，效率高挣郭。
②由于數(shù)據(jù)是進行hash之后進行保存的迄埃，所以原數(shù)據(jù)在里面是沒有順序的，所以僅僅能滿足 “=” 兑障、“IN”這樣的操作侄非，不能使用范圍查詢 蕉汪。
③無法被用來避免數(shù)據(jù)的排序操作，因為不像B+樹彩库，它的存儲是有順序的肤无，是按照索引值進行排序的，然后hash索引是hash后的數(shù)據(jù)骇钦，所以無法避免排序宛渐。
④不能利用部分索引鍵查詢，在B+樹中眯搭，多個字段的索引是通過按照字段一次排序進行存儲的窥翩，所以如果創(chuàng)建了(A,B,C)三個字段的聯(lián)合索引，那么可以使用部分索引例如A鳞仙，(A,B)寇蚊，但是hash的聯(lián)合索引是所有字段一起進行hash的結果去映射的，所以部分字段無法使用棍好。
⑤不能避免全表掃描仗岸。因為查詢出來的數(shù)據(jù)還是存在buckets中的，還是要進行表的遍歷借笙。
⑥遇到大量hash值相等的情況后扒怖，也就是出現(xiàn)大量的hash碰撞后，鏈表就會非常長业稼，變成線性結構盗痒，查詢效率并不一定會比B+-Tree高。
2.BitMap索引
BitMap索引使用不同的值進行分組低散，然后每組數(shù)據(jù)中將相同的值的位置標位1俯邓，不同的值的位置標為0，這樣就會形成很多個不同的二進制串熔号。
①BitMap是對數(shù)據(jù)進行位圖存儲稽鞭，所以查詢會很快。
②由于每個值都需要一個位圖去保存引镊，所以只適用于值的種類比較少的情況川慌，比如性別這樣的字段。
③進行數(shù)據(jù)的統(tǒng)計速度快祠乃。
④鎖的力度大梦重，因為進行增刪改的時候，位圖的值的位置會發(fā)生變化亮瓷，所以會鎖住整個位圖的對象琴拧。
五.密集索引和稀疏索引和覆蓋索引
1.密集索引
①在InnoDB引擎中，數(shù)據(jù)本身就是索引文件嘱支，其表數(shù)據(jù)文件本身就是B+樹組織的一個索引結構蚓胸，樹的葉節(jié)點data域保存了完整的數(shù)據(jù)記錄挣饥。這個索引的key是數(shù)據(jù)表的主鍵，因此InnoDB表數(shù)據(jù)文件本身就是主索引沛膳。這種索引被稱為"聚集索引(或者聚族索引)"扔枫。
②MyISAM引擎的索引不是聚集索引。
③InnoDB有且只有一個聚集索引锹安，選取規(guī)則如下：
A：如果定義了主鍵短荐，那么該主鍵就作為密集索引。
B: 如果沒有定義主鍵叹哭，則選擇該表的第一個唯一非空索引作為密集索引忍宋。
C：如果上面都不滿足，InnoDB會在內(nèi)部生成一個六字節(jié)的自增值作為隱藏主鍵风罩，來作為密集索引糠排。
④密集索引文件中的每個搜索碼值都對應一個索引值。
⑤密集索引決定了數(shù)據(jù)的物理存放順序超升，一個文件只能有一個物理存放順序入宦，所以只能有一個密集索引。
⑥密集索引的葉子節(jié)點之間存放的該行數(shù)據(jù)室琢。
2.稀疏索引
①MyISAM引擎的所有索引都是稀疏索引云石。
②稀疏索引文件只為搜索碼的某些值建立索引。
③葉子節(jié)點只保留了數(shù)據(jù)的地址或者主鍵研乒，獲取到了之后還要跟地址或者主鍵去再次進行查找。
3.覆蓋索引
如果一個索引包含(或者說覆蓋)所有需要查詢的字段的值淋硝，那么這個索引就是"覆蓋索引"雹熬。
①覆蓋索引會把要查詢出來的列和索引進行對應，查詢時不會進行回表操作(不會進行二次查詢)谣膳。
六.InnoDB和MyISAM的區(qū)別
①數(shù)據(jù)的物理存放不同竿报。
InnoDB在文件存放中會存在兩個文件，一個frm結尾的文件保存了這個表的定義文件继谚，數(shù)據(jù)和索引都存放在一個以ibd結尾的文件中烈菌。
MyISAM在文件存放中存在三個文件，一個frm結尾的文件保存了這個表的定義文件花履，索引存放在一個以MYI結尾的文件中芽世，數(shù)據(jù)存放在一個以MYD結尾的文件中。
②索引不同
InnoDB存在一個密集索引诡壁，葉子節(jié)點保存的該列的所有值济瓢；MyISAM所有的索引都是稀疏索引，葉子節(jié)點保存的是數(shù)據(jù)的地址妹卿；InnoDB稀疏索引的葉子節(jié)點存放的是主鍵旺矾。
③MyISAM緩存有表meta-data(行數(shù)等信息)蔑鹦，所以在進行count(*)的時候會很快，InnoDB沒有箕宙。
④MyISAM強調(diào)的是性能嚎朽，每次查詢具有原子性，其執(zhí)行速度比InnoDB類型更快柬帕。
⑤MyISAM不支持事務操作哟忍。InnoDB支持事務。
⑥MyISAM不支持外鍵雕崩，二InnoDB支持魁索。
七.索引的創(chuàng)建條件
1.需要創(chuàng)建索引的情況
①主鍵自動建立唯一索引。
②頻繁作為查詢條件的字段應該創(chuàng)建索引盼铁。
③查詢中與其他表關聯(lián)的字段粗蔚，外鍵等應該建立索引。
④頻繁更新的字段不適合創(chuàng)建索引饶火。
⑤where條件里用不到的字段不創(chuàng)建索引鹏控。
⑥在單值索引和復合索引之間，優(yōu)先選擇復合索引肤寝。
⑦查詢中排序的字段当辐，應該建立索引。
⑧查詢中進行統(tǒng)計或者分組的字段應該建立索引鲤看。
2.不需創(chuàng)建索引的情況
①表記錄太少的情況缘揪。
②經(jīng)常進行增刪改的表。
③數(shù)據(jù)重復且分布均勻的表字段义桂。
八.explain指令
1.能干什么
使用explain關鍵字可以模擬優(yōu)化器執(zhí)行SQL查詢語句找筝，從而知道MySQL是如何處理你的SQL語句的，分析你的查詢語句或是表結構的性能瓶頸慷吊。
通過explain關鍵字可以查看如下的一些信息袖裕。
①表的讀取順序。
②數(shù)據(jù)讀取操作的操作類型溉瓶。
③那些索引可以使用急鳄。
④那些索引實際被使用。
⑤表之間的引用關系堰酿。
⑥每張表有多少行被執(zhí)行器查詢疾宏。
2.怎么用
在SQL語句前面加入explain 關鍵字，執(zhí)行該語句就可以獲取信息触创。
①id
select查詢的序號列灾锯，包含一組數(shù)字，表示查詢中執(zhí)行select子句或操作表的順序嗅榕。
A : id相同顺饮，表示順序由上而下執(zhí)行吵聪。
B : id不同，如果是子查詢兼雄，id的序號會遞增吟逝，id值越大優(yōu)先級越高，越先被執(zhí)行赦肋。
C : id相同不同块攒，同時存在。
②select_type
查詢的類型佃乘，主要用于區(qū)別 普通查詢囱井、聯(lián)合查詢、子查詢等的復雜查詢趣避。有下面幾種值：
A ：SIMPLE 簡單的select語句庞呕，查詢中不包含子查詢或者union。
B : PRIMARY 查詢中若包含任何復雜的子查詢程帕，最外層查詢則被標記為PRIMARY.
C : SUBQUERY 在select或者where列表中包含子查詢住练，會被標記為SUBQUERY。
D : DERIVED 在from列表中包含的子查詢被標記為DERIVED(衍生),mysql會遞歸執(zhí)行這些子查詢愁拭，把結果放在臨時表里讲逛。
E : UNION 若第二個select出現(xiàn)在union之后，則被標記為union岭埠，若union包含在from子句的子查詢中盏混，外層select被標記為DERIVED。
F : UNION RESULT 從UNION表獲取結果的select惜论。
③table
顯示這一行的數(shù)據(jù)是關于那張表的许赃。
④type
顯示查詢使用了何種類型，從走好到最差依次是下面順序来涨。
A : system :表示只有一行記錄，這是const類型的特例启盛，平時不會出現(xiàn)蹦掐，這個可以忽略不計。
B : const : 表示通過索引一次就找到了僵闯，const用于表示primary key或者unique索引卧抗。因為只匹配一行數(shù)據(jù)，所以很快鳖粟。
C : eq_ref :唯一性索引掃描社裆，對應每個索引鍵，表中只有一條記錄與之匹配向图。常見于主鍵或唯一索引掃描泳秀。
D : ref :非唯一索引掃描标沪，返回匹配某個單獨值的所有行；本質上也是一種索引訪問嗜傅，它返回所有匹配某個單獨值的行金句，然而，它可能會找到很多個符合條件的行吕嘀，所以他應該屬于查找和掃描的混合體违寞。
E : range :只檢索給定范圍的值，使用一個索引選擇行偶房。key列顯示使用了那個索引趁曼，一般就是在where語句中出現(xiàn)了between、<棕洋、>挡闰、in等的查詢。這種范圍掃描索引比全表掃描要好拍冠，因為它只需要開始于索引的某一點尿这，而結束于另一點，不用掃描全部索引庆杜。
F : index :Full Index Scan,index與All的區(qū)別為index類型只遍歷索引樹射众。這通常比All快，因為索引文件通常比數(shù)據(jù)文件少晃财。也就是說雖然All和Index都是讀全表叨橱，但index是從索引里面讀，而all是從硬盤里面讀断盛。
G : all :Full Table Scan,將遍歷全表找到匹配的行罗洗。
一般來說，得保證查詢至少達到range級別钢猛，最好達到ref級別伙菜。
⑤possible_keys
顯示可能在這張表表中的索引，一個或多個命迈。查詢涉及到的字段上若存在索引贩绕，則該索引被列出，但不一定被查詢實際使用.
⑥key
實際使用到的索引壶愤，如果為null淑倾，則表示沒有使用索引。查詢中若使用覆蓋索引征椒，則索引和查詢的select字段重疊娇哆。
⑦key_len
表示索引中使用的字節(jié)數(shù)，可以通過該列計算查詢中使用的索引的長度，在不損失精確性的情況下碍讨，長度越短越好治力。 key_len顯示的值為索引字段的最大可能長度，并非實際使用長度垄开，即key_len使根據(jù)表定義計算而得的琴许，不是通過表內(nèi)檢索出來的。
⑧ref
顯示索引的哪一列被使用了溉躲，如果可能的話榜田，是一個常數(shù)，那些列或常量被用于查詢索引上面的值锻梳。
⑨rows
根據(jù)表統(tǒng)計信息及索引選用情況箭券，大致估算出找到所需記錄需要讀取的行數(shù)。
⑩Extra
包含不合適在其他列中顯示但十分重要的額外信息疑枯。有下面的一些取值：
①Using filesort ： 說明mysql 會對數(shù)據(jù)使用一個外部排序辩块，而不是按照表內(nèi)的索引順序就行排序。MYSQL中無法利用索引完成的排序操作成為"文件排序"荆永。
②Using temporary :使用了臨時表保存中間結果废亭，mysql在對查詢結果排序時使用臨時表。常見于排序order by和分組查詢group by.具钥。
③Using index : 表示相應的select操作中使用了覆蓋索引豆村，避免訪問了表的數(shù)據(jù)行，效率不錯骂删；如果同時出現(xiàn)using where 掌动，表明索引被用來執(zhí)行索引鍵值的查找；如果沒有同時出現(xiàn)using where宁玫，表明索引用來讀取數(shù)據(jù)而非執(zhí)行查找動作粗恢。
④Using where : 表明使用了where過濾。
⑤Using join buffer :表明使用了連接緩存欧瘪。
⑥impossible where ：where子句的值總是false眷射，不能用來獲取任何元組。
⑦select tables optimized away :在沒有group by子句的情況下佛掖，基于索引優(yōu)化MIN/MAX操作或者對于MyISAM存儲引擎優(yōu)化count(*)操作妖碉，不必等到執(zhí)行階段再進行計算，查詢執(zhí)行計劃生成的階段即完成優(yōu)化苦囱。
⑧distinct :優(yōu)化distinct操作嗅绸，在找到第一匹配的元組后即停止找同樣值的動作脾猛。
九.索引失效
①復合索引全值匹配最好撕彤。
②最左前綴匹配原則。
③不在索引列上做任何操作(計算、函數(shù)羹铅、類型轉換)蚀狰，會導致索引失效而轉向全表掃描。
④存儲引擎不能使用索引范圍中范圍條件右邊的列(比如索引(A,B,C),如果查詢條件為A=xxx and B > xx and C = xxx,則只會使用索引A职员，B使用了范圍查詢麻蹋，不會使用C)。
⑤盡量使用覆蓋索引焊切，減少select *扮授。
⑥mysql 在使用不等于(!= 或者 <>)的時候無法使用索引會導致全表掃描。
⑦is null专肪、is not null也無法使用索引刹勃。
⑧l(xiāng)ike以通配符開頭('%abc')mysql會使用全表掃描。
⑨字符串不加單引號索引失效嚎尤。
⑩少用or荔仁，用它來連接會導致索引失效。
建議
①對于單值索引芽死，盡量選擇針對當前query過濾性更好的索引乏梁。
②在選擇組合索引的時候，當前query中過濾性最好的字段在索引字段順序中关贵，位置越靠前越好遇骑。
③在選擇組合索引的時候，盡量選擇可以能夠包含當前query中的where子句中更多字段的索引坪哄。
④盡可能通過分析統(tǒng)計信息和調(diào)整query的寫法來達到選擇合適索引的目的质蕉。
十.最左前綴匹配原則
①mysql會一直向右匹配直到遇到范圍查詢(>、<翩肌、between模暗、like)就停止匹配，比如 a=3 and b=4 and c>5 and d=6,如果建立(a,b,c,d)順序的索引念祭，d就用不到索引兑宇；如果建立(a,b,d,c)的索引則都可以用到，a,b,d的順序是可以隨意調(diào)整的粱坤。這就是最左匹配原則隶糕。
②= 和 in 是可以亂序的，比如 a=1 and b=2 and c=3,建立(a,b,c)索引可以任意順序站玄，mysql查詢優(yōu)化器水幫助我們調(diào)整順序枚驻。
③為什么？
因為mysql對于聯(lián)合索引的處理是株旷，首先根據(jù)第一個字段進行排序再登，然后在排序的基礎上再根據(jù)第二個字段進行排序尔邓，類似于group by 對多個字段進行排序，所以對于第一個字段(最左)來說是絕對有序的锉矢，但是對于后面的字段來說就是無序的了梯嗽。這就是最左匹配原則的成因。
十一.查詢優(yōu)化
1.用于小表驅動大表沽损。
①驅動表的定義
當進行多表連接查詢時灯节， [驅動表] 的定義為：
1）指定了聯(lián)接條件時，滿足查詢條件的記錄行數(shù)少的表為[驅動表]绵估。
2）未指定聯(lián)接條件時炎疆，行數(shù)少的表為[驅動表]（Important!）。
②為什么国裳？
可以使用嵌套循環(huán)來進行類比
for(int i=5;.......)
{
for(int j=1000;......)
{}
}
如果小的循環(huán)在外層磷雇，對于數(shù)據(jù)庫連接來說就只連接5次，進行5000次操作躏救，如果1000在外唯笙，則需要進行1000次數(shù)據(jù)庫連接，從而浪費資源盒使，增加消耗崩掘。這就是為什么要小表驅動大表。
③怎么做
下面結論都是針對in或exists的少办。
in后面跟的是小表苞慢，exists后面跟的是大表。
對于exists
select .....from table where exists(subquery);
可以理解為：將主查詢的數(shù)據(jù)放入子查詢中做條件驗證英妓，根據(jù)驗證結果（true或false）來決定主查詢的數(shù)據(jù)是否得以保留挽放。
2.order by關鍵字優(yōu)化
①order by子句，盡量使用index方式排序蔓纠，避免使用filesort排序辑畦。
②盡可能在索引列上完成排序操作，遵照索引建的最佳左前綴原則腿倚。
③如果不在索引列上纯出，filesort有兩種算法：mysql會啟用雙路排序和單路排序。
A : 雙路排序：mysql4.1之前使用雙路排序敷燎，字面意思就是兩次掃描磁盤暂筝，最終得到數(shù)據(jù)，讀取
行指針和order by列硬贯，對他們進行排序焕襟，然后掃描已經(jīng)排序好的列表，按照列表中的值重新從列表中讀取對應的數(shù)據(jù)輸出饭豹。簡單來說就是：從磁盤取排序字段鸵赖，然后在buffer中進行排序畏吓，再從磁盤取其它字段。
B : 從磁盤中讀取查詢需要的所有列卫漫，按照order by列在buffer對它們進行排序，然后掃描排序后的列表進行輸出肾砂，它的效率要快一些列赎，避免了第二次讀取數(shù)據(jù)，并且把隨機IO變成了順序IO镐确，但它會使用更多的空間包吝。
④優(yōu)化策略
- 增大sort_offset_size 參數(shù)的設置。
- 增大max_length_for_sort_data 參數(shù)的設置源葫。
3.group by優(yōu)化
①group by實質是先排序再進行分組诗越，遵照索引建的最佳左前綴原則。
②當無法使用索引列息堂，增大max_length_for_sort_data參數(shù)的設置+增大sort_buffer_size參數(shù)的設置嚷狞。
③where高于having，能寫在where限定的條件就不要去having限定了荣堰。
