第七色在线视频,2021少妇久久久久久久久久,亚洲欧洲精品成人久久av18,亚洲国产精品特色大片观看完整版,孙宇晨将参加特朗普的晚宴

為了賬號安全,請及時(shí)綁定郵箱和手機(jī)立即綁定
已解決430363個(gè)問題,去搜搜看,總會有你想問的

MySQL limit對效率的影響

MySQL limit對效率的影響

慕勒3428872 2019-04-21 20:41:59
有一張很老的數(shù)據(jù)表,時(shí)間戳格式為varchar,字段如下:idbigintnamevarchar(200)create_timevarchar(200)//索引KEY`IDX_CREATED`(`create_time`),數(shù)據(jù)約500多萬,現(xiàn)在引出發(fā)現(xiàn)的問題,一條sql語句效率非常的低:selectid,namefromtwherecreate_time>1434115807296orderbycreate_timelimit1000;本機(jī)測試200s,執(zhí)行計(jì)劃:>explainselectid,namefromtwherecreate_time>1434115807296orderbycreate_timelimit1000;+----+-------------+-------+-------+---------------+---------------+---------+------+------+-------------+|id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra|+----+-------------+-------+-------+---------------+---------------+---------+------+------+-------------+|1|SIMPLE|User|index|IDX_CREATED|IDX_CREATED|63|NULL|1000|Usingwhere|+----+-------------+-------+-------+---------------+---------------+---------+------+------+-------------+1rowinset(0.00sec)如果去掉limit:selectid,namefromtwherecreate_time>1434115807296orderbycreate_time執(zhí)行時(shí)間5s,執(zhí)行計(jì)劃:>explainselectid,namefromtwherecreate_time>1434115807296orderbycreate_time+----+-------------+-------+------+---------------+------+---------+------+---------+-----------------------------+|id|select_type|table|type|possible_keys|key|key_len|ref|rows|Extra|+----+-------------+-------+------+---------------+------+---------+------+---------+-----------------------------+|1|SIMPLE|User|ALL|IDX_CREATED|NULL|NULL|NULL|4858500|Usingwhere;Usingfilesort|+----+-------------+-------+------+---------------+------+---------+------+---------+-----------------------------+1rowinset(0.00sec)一個(gè)index查詢竟然比ALL&filesort查詢慢這么多?請MySQL達(dá)人指教
查看完整描述

2 回答

?
九州編程

TA貢獻(xiàn)1785條經(jīng)驗(yàn) 獲得超4個(gè)贊

看執(zhí)行計(jì)劃,這兩個(gè)差別主要在于是否使用了IDX_CREATED的索引,以及filesort。
前者用上了索引,所以你前面where條件的查詢速度會有很大提高,但是很奇怪沒有用到filesort,所以在后面的orderby階段會消耗了很大的時(shí)間。
后者就是直接簡單的查詢,沒有使用索引,并進(jìn)行了正常的文件排序。
可以考慮強(qiáng)制不使用索引Ignoreindex來優(yōu)化此句的性能。
建議你用profile跟蹤再詳細(xì)看一下每個(gè)階段的時(shí)間消耗,這樣會更為準(zhǔn)確。
                            
查看完整回答
反對 回復(fù) 2019-04-21
?
楊魅力

TA貢獻(xiàn)1811條經(jīng)驗(yàn) 獲得超6個(gè)贊

create_timevarchar(200)
改為
create_timeint(11)
你是用laravel框架自動(dòng)生成的吧?傻!
另外,你這樣對比不公平?。YSQL分頁慢加速器解決方案MYSQL分頁優(yōu)化MYSQL分頁解決方案LIMIT優(yōu)化
                            
查看完整回答
反對 回復(fù) 2019-04-21
  • 2 回答
  • 0 關(guān)注
  • 310 瀏覽
慕課專欄
更多

添加回答

舉報(bào)

0/150
提交
取消
微信客服

購課補(bǔ)貼
聯(lián)系客服咨詢優(yōu)惠詳情

幫助反饋 APP下載

慕課網(wǎng)APP
您的移動(dòng)學(xué)習(xí)伙伴

公眾號

掃描二維碼
關(guān)注慕課網(wǎng)微信公眾號