前言

事情是這樣的：線上環(huán)境有個(gè)單表，數(shù)據(jù)才3000多筆，每次按條件過(guò)濾都要2秒左右，簡(jiǎn)直無(wú)法理解。抱著好奇心，我決定研究一下到底是什么情況。

索引分析

explain select * from **** ，發(fā)現(xiàn)并沒(méi)有走索引。

將索引加上之后，速度從2秒變成0.1秒不到。

但是呢，正常情況下3000筆數(shù)據(jù)就算不走索引，查詢也應(yīng)該是毫秒級(jí)響應(yīng)，所以繼續(xù)排查其他原因

表結(jié)構(gòu)分析

查看該表的字段，發(fā)現(xiàn)有個(gè) LongText 類型的字段 props，存儲(chǔ)了大量JSON數(shù)據(jù)和BASE64的圖片（不要問(wèn)我為什么這樣存，有些項(xiàng)目就是這么的匪夷所思！！！！）此外，整張表雖然才3000多筆數(shù)據(jù)，但是占用空間達(dá)到了2G，就是拜LongText字段所賜。

我們將 props 字段從 select 返回的字段中移除，發(fā)現(xiàn)速度飛快，但是這個(gè)字段又是必須的，那怎么解決呢？

解決方案

方案一： 根據(jù)where條件創(chuàng)建索引，上面演示過(guò)了

方案二：把 props 字段放到單獨(dú)的表，先把對(duì)應(yīng)的 id 都查出來(lái)，再去這張表取出需要的 props 數(shù)據(jù)，可以大大地減少 LongText 字段的掃描次數(shù)。

總結(jié)

以上是生活随笔為你收集整理的问题排查：单表3000笔数据查询竟然要2秒？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。