問(wèn)題描述

1，背景描述我有一個(gè)user表，表結(jié)構(gòu)如下：索引如下：表中數(shù)據(jù)如下：

可以看到表中數(shù)據(jù)是按lastname排序的，這是因?yàn)樵趌astname, familyname, city上有一個(gè)多列索引，userid上的主鍵（索引）是后加的，所以u(píng)serid是無(wú)序的。mysql當(dāng)中有沒(méi)有一種方法可以重新生成（或組織）索引，讓select userid, lastname from user這條語(yǔ)句的查詢(xún)結(jié)果默認(rèn)是按userid排序？

注意：不是強(qiáng)制使用索引select userid, lastname, from user force index(primary)，而是重新生成或組織索引(reorganize)。

4月29日更新

其實(shí)，我這里是想問(wèn)mysql是不是有某個(gè)命令可以對(duì)表中已有的索引進(jìn)行重新組織，就是在表經(jīng)過(guò)一段時(shí)間的更新、刪除、插入操作后，數(shù)據(jù)會(huì)發(fā)生變化（結(jié)構(gòu)不變），那么表的索引也就相應(yīng)的會(huì)發(fā)生各種變化（比如底層的碎片等），那么是不是有一種方法可以對(duì)這些索引重新組織或者重新生成，再不然就只能刪除索引再重建索引。

5月2日更新我把最初提問(wèn)的問(wèn)題增加了刪除線，開(kāi)始的提問(wèn)有些問(wèn)題，特別是這兒的描述是錯(cuò)誤的：“可以看到表中數(shù)據(jù)是按lastname排序的，這是因?yàn)樵趌astname, familyname, city上有一個(gè)多列索引，userid上的主鍵（索引）是后加的，所以u(píng)serid是無(wú)序的可以看到表中數(shù)據(jù)是按lastname排序的，這是因?yàn)樵趌astname, familyname, city上有一個(gè)多列索引，userid上的主鍵（索引）是后加的，所以u(píng)serid是無(wú)序的”，至于為什么是無(wú)序的，@clcx_1315已經(jīng)回答了，而且他也指出即便重新組織(生成)索引，這句select userid, lastname from user也是無(wú)法實(shí)現(xiàn)讓userid有序的。我百度了下，mysql當(dāng)中好像沒(méi)有專(zhuān)門(mén)用于重新生成或組織索引的命令，sql server數(shù)據(jù)庫(kù)倒是有，感興趣的朋友百度吧。

問(wèn)題解答

mysql有optimize table的用法，但是同時(shí)也把表重組了。如果系統(tǒng)有明顯的業(yè)務(wù)低峰期，刪掉索引重建也是可以的。

這種情況是因?yàn)槟阒麈I外的其他列是一個(gè)復(fù)合索引，你查詢(xún)的時(shí)候mysql就直接走索引表找到你的所有數(shù)據(jù)（mysql innodb普通索引會(huì)將主鍵信息一并存儲(chǔ)），所以就是按照你索引首字段排序檢索，他并不是按照錄入磁盤(pán)順序讀取全表的，而主鍵則是按照磁盤(pán)錄入順序添加的，因此在磁盤(pán)上是順序的，但是你讀取的時(shí)候讀的是索引表才會(huì)是不連續(xù)的要改變這種狀況的話(huà)你重建表也是一樣的，仍然會(huì)按lastname得索引排序，除非你按照l(shuí)astname的順序錄入另外一個(gè)辦法就是添加一個(gè)冗余字段，這時(shí)候再select全表的時(shí)候就不會(huì)走你的覆蓋索引查詢(xún)而是走全表掃描，當(dāng)然就會(huì)主鍵漸順序排列了。

我記得mysql也會(huì)根據(jù)你的索引情況自動(dòng)對(duì)索引進(jìn)行重建，具體根據(jù)什么也沒(méi)查到。留待有緣人解答