亚洲精品久久久中文字幕-亚洲精品久久片久久-亚洲精品久久青草-亚洲精品久久婷婷爱久久婷婷-亚洲精品久久午夜香蕉

您的位置:首頁技術文章
文章詳情頁

mysql中longtext存在大量數據時,會導致查詢很慢?

瀏覽:126日期:2022-06-16 18:07:22

問題描述

一個表,1.5w條數據,字段: id,name,content,last_update_timeid,自定義主鍵name,varchar類型content是longtext類型,last_update_time為datetime類型,不為空

content當中是文本和代碼等,平均長度在20k+。

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

當content當中有大量的文本時,case1的效率極慢。

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

把content一列刪掉,效率很高。毫秒級別。

使用explain:有content時結果:

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 |+----+-------------+-----------+-------+---------------+----------------------+---------+------+-------+-------+

無content列的結果:

+----+-------------+----------------+------+---------------+------+---------+------+-------+----------------+| 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)

請大神請教,是什么問題?該怎么優化?

問題解答

回答1:

無content的時候,查詢走的是idx_last_update_time,我猜測這個索引中包含了id,name字段,因此僅通過索引就可以獲取到所需的數據,因此速度很快。有content的時候,因為有limit 10000的語句,且無法從索引中獲取content字段的內容,因此采用的全表掃描的方法。建議改寫sql語句,讓數據庫的執行計劃更充分使用索引,假設id是主鍵:

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

content當中是文本和代碼等,平均長度在20k+。

這種應該建立全文索引(FUNLLTEXT INDEX)吧。簡單的索引不適合這種超長文本的字段。

回答3:

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

這兩種方式你可以執行看看那個效率高,希望對你有幫助。。

主站蜘蛛池模板: 中国美女黄色一级片 | 大陆老太交xxxxxhd在线 | 成人国产在线24小时播放视频 | 亚洲精品久久久久久久网站 | 久草精品视频 | 成人人观看的免费毛片 | 欧美亚洲国产精品久久久久 | 国产国拍亚洲精品av | 欧美草比| 国拍在线精品视频免费观看 | 久久天天躁狠狠躁夜夜中文字幕 | julia一区二区中文字幕 | 国产又黄又免费aaaa视频 | 久爱www免费人成福利播放 | 初女破苞国语在线观看免费 | 一本久道热中字伊人 | 国产在线一区在线视频 | 久久综合色之久久综合 | 日韩版码免费福利视频 | 欧美日韩不卡中文字幕在线 | 久久精品网站免费观看 | 青青青青手机在线视频观看国产 | 精品国产中文一级毛片在线看 | 尤物视频在线观看入口 | 欧美日韩在线网站 | 97视频在线免费播放 | 亚洲图片一区 | 91精品国产综合久久久久久 | 91破解版在线 | 亚洲 | 激情爱爱的免费视频 | 免费jizz在线播放视频 | 色在线免费 | 国产精品第二页在线播放 | 美国a级黄色片 | 99国产精品免费视频观看 | 手机国产精品一区二区 | 国产uv1区二区三区 国产va免费精品观看 | 1000部啪啪未满十八勿入中国 | 狠狠做久久深爱婷婷97动漫 | 在线看国产 | 成年做羞羞免费观看视频网站 |