導(dǎo)讀:1建站知識前端時間跟一個DB相關(guān)的項目，alanc反饋有一個查詢，使用索引比不使用索引慢很多倍，有點(diǎn)毀三觀。所以跟進(jìn)了一下，用explain，看了看2個查詢不同的結(jié)果。 網(wǎng)站seo優(yōu)化軟件網(wǎng)站優(yōu)化seo培訓(xùn)。

前端時間跟一個DB相關(guān)的項目，alanc反饋有一個查詢，使用索引比不使用索引慢很多倍，有點(diǎn)毀三觀。所以跟進(jìn)了一下，用explain，看了看2個查詢不同的結(jié)果。    不用索引的查詢的時候結(jié)果如下，實際查詢中速度比較塊。  復(fù)制代碼 代碼如下:     mysql> explain select * from rosterusers limit 10000,3 ;      +----+-------------+-------------+------+---------------+------+---------+------+---------+-------+  | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |  +----+-------------+-------------+------+---------------+------+---------+------+---------+-------+  | 1 | SIMPLE | rosterusers | ALL | NULL | NULL | NULL | NULL | 2010066 | |  +----+-------------+-------------+------+---------------+------+---------+------+---------+-------+    而使用索引order by的查詢結(jié)果如下，速度反而慢的驚人。  mysql> explain select * from rosterusers order by username limit 10000,3 ;  +----+-------------+-------------+------+---------------+------+---------+------+---------+----------------+  | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |  +----+-------------+-------------+------+---------------+------+---------+------+---------+----------------+  | 1 | SIMPLE | rosterusers | ALL | NULL | NULL | NULL | NULL | 2010087 | Using filesort |  +----+-------------+-------------+------+---------------+------+---------+------+---------+----------------+    區(qū)別在于，使用索引查詢的Extra變成了，Using filesort。居然用了使用外部文件進(jìn)行排序。這個當(dāng)然慢了。   但數(shù)據(jù)表上在username，的確是有索引的。怎么會反而要Using filesort?  看了一下數(shù)據(jù)表定義seo網(wǎng)站優(yōu)化。是一個開源聊天服務(wù)器ejabberd的一張表。初看以為主鍵i_rosteru_user_jid是username，和jid的聯(lián)合索引，那么使用order by username時應(yīng)該是可以使用到索引才對呀？  復(fù)制代碼 代碼如下:     CREATE TABLE `rosterusers` (  `username` varchar(250) NOT NULL,  `jid` varchar(250) NOT NULL,  UNIQUE KEY `i_rosteru_user_jid` (`username`(75),`jid`(75)),  KEY `i_rosteru_jid` (`jid`)  ) EN網(wǎng)站seo優(yōu)化診斷工具GINE=InnoDB DEFAULT CHARSET=utf8;      仔細(xì)檢查突然發(fā)現(xiàn)其主鍵定義，不是定義的完整的主鍵名稱，而跟了一個75的長度描述，稍稍一愣，原來用的是前綴索引，而不是整個字段都是索引。（我的記憶里面網(wǎng)站建設(shè)多少錢InnoDB還不支持這玩意，估計是4.0后什么版本加入的），前綴索引就是將數(shù)據(jù)字段中前面N個字節(jié)作為索引的一種方式。    發(fā)現(xiàn)了這個問題后，我們開始懷疑慢查詢和這個索引有關(guān)，前綴索引的主要用途在于有時字段過程，而MySQL支持的很多索引長度是有限制的。  首先不帶order by 的limit 這種查詢，本質(zhì)可能還是和主鍵相關(guān)的，因為MySQL 的INNODB的操作實際都是依靠主鍵的（即使你沒有建立，系統(tǒng)也會有一個默認(rèn)的），而limit這種查詢，使用主鍵是可以加快速度，（explain返回的rows 應(yīng)該是一個參考值），雖然我沒有看見什么文檔明確的說明過這個問題，但從不帶order by 的limit 查詢的返回結(jié)果基本可以證明這點(diǎn)。    但當(dāng)我們使用order by username的時候，由于希望使用的是username的排序，而不是username（75）的排序，但實際索引是前綴索引，不是完整字段的索引。所以反而導(dǎo)致了order by的時候完全無法利用索引了。（我在SQL語句里面增加強(qiáng)制使用索引i_rosteru_user_jid也不起作用）。而其實使用中，表中的字段username 連75個都用不到，何況定義的250的長度。完全是自己折騰導(dǎo)致的麻煩。由于這是其他產(chǎn)品的表格，我們無法更改，暫時只能先將就用不不帶排序的查詢講究。    總結(jié)：  •前綴索引，并不是一個萬能藥，他的確可以幫助我們對一個寫過長的字段上建立索引。但也會導(dǎo)致排序（order by ，group by）查詢上都是無法使用前綴索引的。  •任何時候，對于DB Schema定義，合理的規(guī)劃自己的字段長度，字段類型都是首要的事情。  相關(guān)網(wǎng)站seo優(yōu)化軟件網(wǎng)站優(yōu)化seo培訓(xùn)。

關(guān)鍵詞標(biāo)簽: 索引 SQL 前綴