mysql優(yōu)化總結(jié)1定長(zhǎng)與變長(zhǎng)分離如idint占4字節(jié)char4 4個(gè)字符

1idint4個(gè)字節(jié)，char(4)4個(gè)字符長(zhǎng)度，也是定長(zhǎng)==》即每一231對(duì)多，需要關(guān)聯(lián)同級(jí)的字段上，添加冗余字段1：字段類型優(yōu)先級(jí)：整型比如：timyint1,2,3,4,5《==char(1)a,b,c,d1時(shí)不方便例如：where>”2015-10-12”Char（排序）Varchar不定長(zhǎng)2：夠用就行，不要：原因==》大的字段浪費(fèi)內(nèi)存，影響速以timyintunsignednotnull,可以255歲，足夠了，但是用int浪費(fèi)要花費(fèi)的內(nèi)存3原因：NULLmysql5.5null顯1：索引類型==》btree索引、hashB-treebtree有不同。Btree的內(nèi)容可以理解為：Hashmemory表（內(nèi)存引擎）hashHash的原理hash得到位置，直接就找到了hashhash索引？IDID的增長(zhǎng)，ID3btree中，field列的值“oworld”，并hash中（o）和（oworld）地址內(nèi)容452：btreewhere查詢的話查詢的話前面加上 possible_keys是指可能會(huì)用到的索引，keysql使用到的索引，key_len是Myisam引擎（非聚簇索引）innodb(聚簇索引InnodbInnodb用Myium中，主索引和次索引，都指向物理行（磁盤位置注意：innodb1、主鍵索引即索引值，又在葉子中行的數(shù)2Uniquekey3uniquerowid劣勢(shì)==》如果碰到不規(guī)則數(shù)據(jù)插入時(shí)，造成頻繁的頁(yè)，影響速度“setprofiling=1”==>性能分析工具showprofiles;顯示性能2：倒序：例如 》 前面基本相同 ,這樣查詢的話，添加的索引字段太hashurlcrc33.1多列索引的考慮因素==（注意一定要結(jié)合實(shí)際業(yè)務(wù)場(chǎng)景 2擎，如果按某索引字段排序，如ID，但取出的字段中，有未索引字段，如goods_name，myium的做法不是索引--》回行、索引==》回行，而是先取1個(gè)列或者順序相同的的幾個(gè)列，建立了多個(gè)索引。稱為重2Tag-->artidSelecttagfromt1whereSelectartidfromt1whereArtid查--tag==>indexartid(artid)Tag--查artid==》indextag(tag)2Index indexusingindex這兩個(gè)索引，列有，但順序不一樣，稱為“冗余索引”，冗余索引常nop操作（不產(chǎn)生對(duì)數(shù)據(jù)實(shí)質(zhì)性影響的操作），來(lái)修改表比如：表的引擎為innodb，可以alter tablexxxengine optimizetable表名，也可以修復(fù)Sql1：sql語(yǔ)句的時(shí)間花在那里？2：sql語(yǔ)句的執(zhí)行時(shí)間，又花在那里了？ 》聯(lián)合索引的順序，區(qū)分度，長(zhǎng)100001000分解查詢：按邏輯把奪標(biāo)查詢分成多個(gè)簡(jiǎn)單的3:sql 前三個(gè)月統(tǒng)計(jì)的每天數(shù)，用程序來(lái)估算般取列表10-30條左右select*fromtableAselect*fromtableA,tableBA,B答：用exin來(lái)分析下面的截圖是下面的截圖是 in后，里面的對(duì)應(yīng)的查詢內(nèi)Type列：是指查詢的方式，非常重要，是分析“查數(shù)據(jù)過(guò)程”的重要依據(jù)Inde==>all性能稍好點(diǎn)詞）indexindex_all（為了便于理解，造Select fromgoodsorderbygoos_idwhere條件，就得取所有索引節(jié)點(diǎn)，同時(shí)又沒(méi)有回行，只Ref:通過(guò)索引，可以直接到某些數(shù)據(jù)行Const,system,null這三個(gè)分別指查詢優(yōu)化到常量級(jí)別，甚至不需要查找時(shí)間從all===>null Ref列：（指查詢時(shí)，表之間的字段關(guān)系RowsUsingwherewhereUsingtempory是指用上了臨時(shí)表，groupby與orderbygroupbyorderby別的表的列（用上的話，就不太妙了Usingfilesort：文件排序（文件可能在磁盤，也可能在內(nèi)存）例如：selectsum(shop_price)fromgoodsgroupbycat_id(這句話用到了臨時(shí)表和文件排序)In招暑假工保安50人： ExistsFromMinmaxmyium，innodbmin（ID），IDMin（ID）pid上面沒(méi)3113min（ID），Selectmin（ID）fromit_treawhereID是有序的（默認(rèn)的是索引升序排列），ID的索引方向pid=69IDIDSelectID it_treauseindex(primary)wherepid=69limitmyisam對(duì)行數(shù)進(jìn)行了。一但有條件的查詢，速度就不再快了，尤其是where條件3：groupN多重1-->N連接時(shí)，欄目---->商品表，將會(huì)產(chǎn)groupby去重效率很低GroupbyOrderby的列要和group 的一致，否則也會(huì)引起臨時(shí)（原因是因?yàn)間roupby和orderby 者的列不一致，那必須經(jīng)過(guò)至少一次排序）2： AB表連接為例，主要查詢A表的那么groupby,orderby 明為A的列：SelectA.id,A.cat_idfromAinnerjoinBgroupbyA.cat_idorderbyA.cat_id4:unionUnion1unicon的子句條件要盡量具體，即==all之后，不需要去重，uniconall,可以在代碼中去重復(fù)LimitLimitoffsetNoffset的增大，查詢翻頁(yè)速度越慢辦法：不允許翻過(guò)100頁(yè)，以為例，一般能翻頁(yè)到70頁(yè)左例：selectid,name Selectid,namefrom whereid>