問(wèn)題描述

一個(gè)表，1.5w條數(shù)據(jù)，字段: id,name,content,last_update_timeid，自定義主鍵name，varchar類型content是longtext類型，last_update_time為datetime類型，不為空

content當(dāng)中是文本和代碼等，平均長(zhǎng)度在20k+。

case1： select id, name from t order by last_update_time limit 10000, 10

當(dāng)content當(dāng)中有大量的文本時(shí)，case1的效率極慢。

及時(shí)給 last_update_time 加上btree索引, 效率有提升，但是依然慢

把content一列刪掉，效率很高。毫秒級(jí)別。

使用explain：有content時(shí)結(jié)果：

mysql> explain select id, name, last_update_time from t order by last_update_time desc limit 11120, 11;+----+-------------+-----------+-------+---------------+----------------------+---------+------+-------+-------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+-----------+-------+---------------+----------------------+---------+------+-------+-------+| 1 | SIMPLE | t | index | NULL | idx_last_update_time | 8 | NULL | 11131 | NULL |+----+-------------+-----------+-------+---------------+----------------------+---------+------+-------+-------+

無(wú)content列的結(jié)果：

+----+-------------+----------------+------+---------------+------+---------+------+-------+----------------+| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |+----+-------------+----------------+------+---------------+------+---------+------+-------+----------------+| 1 | SIMPLE | t2 | ALL | NULL | NULL | NULL | NULL | 15544 | Using filesort |+----+-------------+----------------+------+---------------+------+---------+------+-------+----------------+1 row in set (0.00 sec)

請(qǐng)大神請(qǐng)教，是什么問(wèn)題？該怎么優(yōu)化？

問(wèn)題解答

無(wú)content的時(shí)候，查詢走的是idx_last_update_time，我猜測(cè)這個(gè)索引中包含了id,name字段，因此僅通過(guò)索引就可以獲取到所需的數(shù)據(jù)，因此速度很快。有content的時(shí)候，因?yàn)橛衛(wèi)imit 10000的語(yǔ)句，且無(wú)法從索引中獲取content字段的內(nèi)容，因此采用的全表掃描的方法。建議改寫sql語(yǔ)句，讓數(shù)據(jù)庫(kù)的執(zhí)行計(jì)劃更充分使用索引，假設(shè)id是主鍵：

select id, name, content from twhere id in ( select id from t order by last_update_time limit 10000, 10)回答2：

content當(dāng)中是文本和代碼等，平均長(zhǎng)度在20k+。

這種應(yīng)該建立全文索引（FUNLLTEXT INDEX）吧。簡(jiǎn)單的索引不適合這種超長(zhǎng)文本的字段。

我覺(jué)得，主要跟你的分頁(yè)查詢的方式有關(guān)，limit 10000,10 這個(gè)意思是掃描滿足條件的10010條數(shù)據(jù)，扔掉前面的10000行，返回最后的10行，在加上你的表中有個(gè)，非常大的字段，這樣必然增加數(shù)據(jù)庫(kù)查詢的i/o時(shí)間，查詢優(yōu)化你可以參照 @邢愛明 的SELECT id,title,content FROM items WHERE id IN (SELECT id FROM items ORDER BY last_update_time limit 10000, 10); 還有一種優(yōu)化方式：你可以記錄最后的last_update_time 每次最后的值。然后查詢可以這樣寫：SELECT * FROM items WHERE last_update_time > '最后記錄的值' order by last_update_time limit 0,10;

這兩種方式你可以執(zhí)行看看那個(gè)效率高，希望對(duì)你有幫助。。