建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
【Mysql】查詢(xún)優(yōu)化——減少回表操作
??聚集索引：數(shù)據(jù)行的物理順序與列值（一般是主鍵的那一列）的邏輯順序相同，一個(gè)表中只能擁有一個(gè)聚集索引。 葉子結(jié)點(diǎn)存儲(chǔ)索引和行記錄，聚簇索引查詢(xún)會(huì)很快，因?yàn)榭梢灾苯佣ㄎ坏叫杏涗洝?/p>
創(chuàng)新互聯(lián)成立于2013年，是專(zhuān)業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目網(wǎng)站制作、做網(wǎng)站網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命，1280元西鄉(xiāng)做網(wǎng)站,已為上家服務(wù),為西鄉(xiāng)各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:18982081108
??非聚集索引：該索引中索引的邏輯順序與磁盤(pán)上行的物理存儲(chǔ)順序不同，一個(gè)表中可以擁有多個(gè)非聚集索引。 葉子節(jié)點(diǎn)存儲(chǔ)聚簇索引值（主鍵id），需要掃碼兩遍索引樹(shù)，先通過(guò)普通索引定位到主鍵值id，再通過(guò)聚集索引定位到行記錄。
??回表查詢(xún)可以理解為普通索引的查詢(xún)，先定位主鍵值，再定位行記錄，它的性能較掃一遍索引樹(shù)更低。
??索引覆蓋，即將查詢(xún)sql中的字段添加到聯(lián)合索引里面，只要保證查詢(xún)語(yǔ)句里面的字段都在索引文件中，就無(wú)需進(jìn)行回表查詢(xún)；
??實(shí)際開(kāi)發(fā)中，不可能把所有字段建立到聯(lián)合索引，可根據(jù)實(shí)際業(yè)務(wù)場(chǎng)景，把經(jīng)常需要查詢(xún)的字段建立到聯(lián)合索引中。
?? 在Mysql5.6的版本上推出，用于優(yōu)化查詢(xún)。 在索引遍歷過(guò)程中，對(duì)索引中包含的字段先做判斷，直接過(guò)濾掉不滿足條件的記錄，減少回表次數(shù)。
?? 優(yōu)化超多分頁(yè)場(chǎng)景。 查詢(xún)條件放到子查詢(xún)中，子查詢(xún)只查主鍵id，然后使用子查詢(xún)中確定的主鍵關(guān)聯(lián)查詢(xún)其他的屬性字段。
2020-07-12：什么是索引回表，如何避免？
通過(guò)索引查數(shù)據(jù)其實(shí)是分兩步：
1、通過(guò)索引字段查到數(shù)據(jù)的主鍵ID
2、通過(guò)主鍵ID查詢(xún)?nèi)繑?shù)據(jù)
其中第二步就是索引回表，要避免索引回表，就要保證查詢(xún)的數(shù)據(jù)只包含主鍵和索引字段本身，這樣第二步就可以省了
數(shù)據(jù)庫(kù)回表
一張用于用戶(hù)登錄的user表：id、userName、Password三個(gè)字段
再根據(jù)查出來(lái)的user信息去對(duì)比密碼是否正確
這時(shí)你發(fā)現(xiàn)username字段是唯一的又經(jīng)常作為where條件所以可以給username字段建一個(gè)索引，于是就給username建了一個(gè)普通的B+Tree索引。這時(shí)候就出問(wèn)題的，因?yàn)镸ySQL的InnoDB使用聚簇索引，具體的數(shù)據(jù)只和主鍵索引放在一起，其他的索引只存儲(chǔ)了數(shù)據(jù)的地址（主鍵id）。比如上面的例子中，我根據(jù)username索引找到的只是一個(gè)username為admin這條數(shù)據(jù)的id而不是這條數(shù)據(jù)信息，所以要找到整條數(shù)據(jù)信息要根據(jù)得到的id再去找?？赐晟厦娴牧鞒?，你應(yīng)該已經(jīng)發(fā)現(xiàn)問(wèn)題了，我要通過(guò)username找到id，再根據(jù)id找整條數(shù)據(jù)，這里有兩個(gè)查找過(guò)程，這是影響效率的。就像上面的兩個(gè)查找過(guò)程就是回表了。
解決辦法
使用覆蓋索引可以解決上面所說(shuō)的回表的問(wèn)題。還是拿上面上面登錄的例子來(lái)說(shuō)，其實(shí)登錄只需要判斷用戶(hù)名和密碼，如果user表中有其他用戶(hù)信息也是不需要的，那我們能不能只查詢(xún)一次就找到這個(gè)用戶(hù)名對(duì)應(yīng)的密碼呢。這個(gè)是可以的，上面所說(shuō)的分兩步查找，第一步根據(jù)username查找是肯定不能少的，那我們只要把password和索引username放到一起就可以了。我們可以建立一個(gè)（username、password）的組合索引，這里username一定要放在前面，然后我們把sql語(yǔ)句改一下
這樣建立組合索引后根據(jù)username查找password，只要一步查找就可以查找到，因?yàn)閜assword已經(jīng)是username索引的一部分了，直接可以查出來(lái)，不再需要通過(guò)id找對(duì)應(yīng)的整條數(shù)據(jù)。覆蓋索引就是覆蓋了多個(gè)列（字段）的索引。
那我們應(yīng)該如何避免回表，因?yàn)槿绻玫搅嘶乇?，就需要二次查?xún)的過(guò)程，效率肯定更慢，很簡(jiǎn)單，回表是因?yàn)橐樵?xún)的字段在非聚集索引里沒(méi)有，所以在滿足需求的情況下，我們盡量使非聚集索引里有要查詢(xún)的索引字段。
在查詢(xún)時(shí)，可以盡量用聚集索引來(lái)查（也就是用主鍵來(lái)查詢(xún)），或者根據(jù)業(yè)務(wù)需求，建好的索引，滿足索引查詢(xún)字段。但是實(shí)際業(yè)務(wù)中，很難建立一個(gè)索引就能滿足所有查詢(xún)要求，所以，正常情況，回表也沒(méi)事，只要能用到索引也能大大加快查詢(xún)速度。
阿里三面：MySQL回表的性能傷害有多大？
無(wú)論單列索引 or 聯(lián)合索引，一個(gè)索引就對(duì)應(yīng)一個(gè)獨(dú)立的B+索引樹(shù)，索引樹(shù)節(jié)點(diǎn)僅包含：
即使根據(jù)索引樹(shù)按條件找到所需數(shù)據(jù)，也僅是索引里的幾個(gè)字段的值和主鍵值，萬(wàn)一你搞個(gè)select *，那就還得其他字段，就需回表，根據(jù)主鍵到聚簇索引里找，聚簇索引的葉節(jié)點(diǎn)是數(shù)據(jù)頁(yè)，找到數(shù)據(jù)頁(yè)才能把一行數(shù)據(jù)所有字段值讀出來(lái)。
所以類(lèi)似
得從聯(lián)合索引的索引樹(shù)里按序取出所有數(shù)據(jù)，接著對(duì)每條數(shù)據(jù)都走一個(gè)主鍵的聚簇索引查找，性能不高。
有時(shí)MySQL執(zhí)行引擎可能認(rèn)為，你要是類(lèi)似
相當(dāng)于得把聯(lián)合索引和聚簇索引，兩個(gè)索引的所有數(shù)據(jù)都掃描一遍，那還不如不走聯(lián)合索引，直接全表掃描得了，這樣就只需掃描一個(gè)主鍵索引。
但若形如：
那執(zhí)行引擎就知道你先掃描聯(lián)合索引的索引樹(shù)，拿到10條數(shù)據(jù)，接著對(duì)10條數(shù)據(jù)在聚簇索引里查找10次即可，那就還是會(huì)走聯(lián)合索引。
覆蓋索引不是一種索引，只是一種基于索引查詢(xún)的方式，即針對(duì)類(lèi)似
僅需聯(lián)合索引里的幾個(gè)字段的值，那就只需掃描聯(lián)合索引的索引樹(shù)，無(wú)需回表找其它字段，這種查詢(xún)方式就是覆蓋索引。
所以當(dāng)你使用聯(lián)合索引時(shí)，注意是否可能會(huì)導(dǎo)致大量回表到聚簇索引，若回表聚簇索引的次數(shù)太多，可能就直接給你做成全表掃描而不走聯(lián)合索引了。
盡可能還是在SQL里指定你僅需要的字段，而不要暴力select *，最好直接走覆蓋索引。
即使無(wú)可避免地要回表，你也盡可能用limit、 where限定一下回表的次數(shù)，就從聯(lián)合索引里篩選少數(shù)數(shù)據(jù)，再回表，這樣性能好一點(diǎn)。
網(wǎng)站名稱(chēng)：mysql回表怎么避免,mysql 回表 什么意思
標(biāo)題路徑：http://www.dlmjj.cn/article/dsggdgp.html
