但數(shù)據(jù)表上在username，的確是有索引的。怎么會(huì)反而要Using filesort? 看了一下數(shù)據(jù)表定義。是一個(gè)開源聊天服務(wù)器ejabberd的一張表。初看以為主鍵i_rosteru_user_jid是username，和jid的聯(lián)合索引，那么使用order by username時(shí)應(yīng)該是可以使用到索引才對(duì)呀？
發(fā)現(xiàn)了這個(gè)問題后，我們開始懷疑慢查詢和這個(gè)索引有關(guān)，前綴索引的主要用途在于有時(shí)字段過程，而MySQL支持的很多索引長度是有限制的。 首先不帶order by 的limit 這種查詢，本質(zhì)可能還是和主鍵相關(guān)的，因?yàn)镸ySQL 的INNODB的操作實(shí)際都是依靠主鍵的（即使你沒有建立，系統(tǒng)也會(huì)有一個(gè)默認(rèn)的），而limit這種查詢，使用主鍵是可以加快速度，（explain返回的rows 應(yīng)該是一個(gè)參考值），雖然我沒有看見什么文檔明確的說明過這個(gè)問題，但從不帶order by 的limit 查詢的返回結(jié)果基本可以證明這點(diǎn)。
但當(dāng)我們使用order by username的時(shí)候，由于希望使用的是username的排序，而不是username（75）的排序，但實(shí)際索引是前綴索引，不是完整字段的索引。所以反而導(dǎo)致了order by的時(shí)候完全無法利用索引了。（我在SQL語句里面增加強(qiáng)制使用索引i_rosteru_user_jid也不起作用）。而其實(shí)使用中，表中的字段username 連75個(gè)都用不到，何況定義的250的長度。完全是自己折騰導(dǎo)致的麻煩。由于這是其他產(chǎn)品的表格，我們無法更改，暫時(shí)只能先將就用不不帶排序的查詢講究。
總結(jié)： •前綴索引，并不是一個(gè)萬能藥，他的確可以幫助我們對(duì)一個(gè)寫過長的字段上建立索引。但也會(huì)導(dǎo)致排序（order by ，group by）查詢上都是無法使用前綴索引的。 •任何時(shí)候，對(duì)于DB Schema定義，合理的規(guī)劃自己的字段長度，字段類型都是首要的事情。
