如何探討select in 在postgresql的效率問題，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

10年積累的成都網(wǎng)站建設(shè)、網(wǎng)站建設(shè)經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識你，你也不認(rèn)識我。但先制作網(wǎng)站后付款的網(wǎng)站建設(shè)流程，更有平順免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

在知乎上看到這樣一個問題：

MySQL 查詢 select * from table where id in (幾百或幾千個 id) 如何提高效率？修改

電商網(wǎng)站，一個商品屬性表，幾十萬條記錄，80M，索引只有主鍵id，做這樣的查詢?nèi)绾翁岣咝剩?/p>

select * from table where id in (幾百或幾千個id)

這些id沒啥規(guī)律，分散的。。。。

看了一下答案，感覺有好多不靠譜的，但是口說無憑，所以在我的電腦上寫了幾個查詢測試一下。我用的是Postgresql9.4，但感覺mysql應(yīng)該也差不多，首先創(chuàng)建一個簡單表，只有簡單的3列，在這個問題的下面好多人提到了需要看表的大小，其實這個問題和表大小無關(guān)，只和index的大小有關(guān)，因為是index是建立在int上的，所以只和紀(jì)錄數(shù)目有關(guān)。

Table "public.t9"Column | Type | Modifiers--------+----------------+-----------c1 | integer |c2 | character(100) |c3 | character(200) |Indexes:"i1" UNIQUE, btree (c1)insert into t9 values(generate_series(1000,500000,1),repeat('a',90),repeat('b',180));

之后生成一些隨機(jī)數(shù)，Mac上用jot，Linux上用shuf

for ((i=0;i<100000;i++))dojot -r 1 1000 600000 >>rand.filedone

然后根據(jù)rand.file 生成查詢語句：

select * from t9 where c1 in (494613,575087,363588,527650,251670,343456,426858,202886,254037,...1);

分別生成3個sql文件，in內(nèi)變量的數(shù)目分別是100，1000和10000個，執(zhí)行這3個sql文件，看看時間

try psql study -f test_100.sql -o /dev/nullLOG: duration: 2.879 mstry psql study -f test_1000.sql -o /dev/nullLOG: duration: 11.974 mstry psql study -f test_10000.sql -o /dev/nullLOG: duration: 355.689 ms

可以看到只有在in內(nèi)數(shù)據(jù)到了10，000個的時候數(shù)據(jù)時間會有比較大的變化，但也不過是在300多ms內(nèi)完成。

那如果按照有些回答那樣，先建一個臨時表，然后用in subquery，并且希望這時候可以兩表join呢？為了簡單我直接用兩表join了

drop table t_tmp;create table t_tmp(id int);insert into t_tmp (id) values(494613),(575087),(363588),(345980),...(1);select t9.* from t9, t_tmpwhere t9.c1 = t_tmp.id;

時間如何呢？

try psql study -f test_create_10000.sql -o /dev/nullLOG: duration: 2.078 msLOG: duration: 1.233 msLOG: duration: 224.112 msLOG: duration: 322.108 ms

除去drop和create的時間，依然花費(fèi)了500+的時間，這里的前提還是我用的ssd盤，所以寫LOG的時間會快很多。為什么會這么慢呢？用explain看一下，這時候數(shù)據(jù)量較大，直接走M(jìn)erge join 了

那1000行數(shù)據(jù)的效率如何呢？

try psql study -f test_create_1000.sql -o exp.outLOG: duration: 2.476 msLOG: duration: 0.967 msLOG: duration: 2.391 msLOG: duration: 8.780 ms

100行的數(shù)據(jù)如下：

try psql study -f test_create_100.sql -o /dev/nullLOG: duration: 2.020 msLOG: duration: 1.028 msLOG: duration: 1.074 msLOG: duration: 1.912 ms

可以看到在100個值和1000個值的情況下create table的方式不會比直接在in里面寫所有的變量好多少，explain看的話是在用NLJ了。但在數(shù)據(jù)量更大（按照原問題，這里in的數(shù)量其實無法預(yù)知）的情況下效率只會更低，再加上額外的表維護(hù)成本和多余的SQL語句，DBA肯定不喜歡的，還是相信數(shù)據(jù)庫，放心大膽直接用in list來搞定這些問題吧。

看完上述內(nèi)容，你們掌握如何探討select in 在postgresql的效率問題的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！