SQL in可以用什么替换或者优化？

[吃瓜日常]

就是现在有一个查询语句是SELECT * FROM A WHERE ID IN (1,2,3,4,6,)这样，但是后面的ID数量非常大，导致查询效率低下，有没有可以替换IN的或者优化一下的语句

[吃瓜日常]

引用 1 楼 lich2005 的回复:

可以考虑用临时表做，然后用 join 来查，A表和临时表的ID 最好都加上主键。
类似

SELECT *
FROM A
JOIN TMP ON A.ID = TMP.ID


一般说来 join 的速度比 in 要快一些，但这个有点老思维了，具体还得看SQL实际执行计划怎么工作的。
考虑的ID的数量很多，就不推荐 EXISTS 了，不过依然值得试试，看下效果。

那如果A表没有那种ID一类的的自增长的标识列呢

[吃瓜日常]

引用 2 楼 吃瓜日常 的回复:

[quote=引用 1 楼 lich2005 的回复:]
可以考虑用临时表做，然后用 join 来查，A表和临时表的ID 最好都加上主键。
类似

SELECT *
FROM A
JOIN TMP ON A.ID = TMP.ID


一般说来 join 的速度比 in 要快一些，但这个有点老思维了，具体还得看SQL实际执行计划怎么工作的。
考虑的ID的数量很多，就不推荐 EXISTS 了，不过依然值得试试，看下效果。

那如果A表没有那种ID一类的的自增长的标识列呢[/quote]而且实际情况的话本身就有两三个表多表连接，再JOIN这个数据表可以嘛

[吉普赛的歌]

非常多是多少？几百、几千、几万？ 少一点用表变量，太多了用临时表。 另外， in的数量如果到一定程度（比如几十万）， 用什么都快不了， 还是要做分页， 不限制输出数量不行。

[吃瓜日常]

引用 4 楼 吉普赛的歌 的回复:

非常多是多少？几百、几千、几万？
少一点用表变量，太多了用临时表。

另外， in的数量如果到一定程度（比如几十万）， 用什么都快不了， 还是要做分页， 不限制输出数量不行。

大概10万左右，分页已经做了，但是查询语句没有分页，应该属于假分页

[lich2005]

可以考虑用临时表做，然后用 join 来查，A表和临时表的ID 最好都加上主键。
类似

SELECT *
FROM A
JOIN TMP ON A.ID = TMP.ID


一般说来 join 的速度比 in 要快一些，但这个有点老思维了，具体还得看SQL实际执行计划怎么工作的。
考虑的ID的数量很多，就不推荐 EXISTS 了，不过依然值得试试，看下效果。

[吉普赛的歌]

引用 5 楼 吃瓜日常 的回复:

[quote=引用 4 楼 吉普赛的歌 的回复:] 非常多是多少？几百、几千、几万？ 少一点用表变量，太多了用临时表。 另外， in的数量如果到一定程度（比如几十万）， 用什么都快不了， 还是要做分页， 不限制输出数量不行。

大概10万左右，分页已经做了，但是查询语句没有分页，应该属于假分页[/quote] 那就把重点放在真分页上吧

[吃瓜日常]

额，但是这个问题比分页还严重，我试着后面sql in三万条数据的时候，就算只查前十条都会卡死，按理说真分页应该也就是一次查询少量数据条数显示出来吧，既然sql in后面大量数据的时候查前十条都不行，那就算真分页应该也是无用的，不知道我理解的对不对

[zjcxc]

通常 JOIN 比 IN 好

[吃瓜日常]

引用 8 楼 zjcxc--个人微信公共号同名 的回复:

通常 JOIN 比 IN 好

是比in好，我现在in后面是一个变量，但是现在把in后面的数据变量存入临时表出现了问题，临时表一个字段无法一次存入大量的数据，也就是说join这条路走不通啊

[吉普赛的歌]

引用 9 楼 吃瓜日常 的回复:

引用 8 楼 zjcxc--个人微信公共号同名 的回复:

通常 JOIN 比 IN 好

是比in好，我现在in后面是一个变量，但是现在把in后面的数据变量存入临时表出现了问题，临时表一个字段无法一次存入大量的数据，也就是说join这条路走不通啊

你弄个测试的数据库， 只保留需要的表， 备份后放在百度云盘， 大家帮你也有个测试环境吧。

[吃瓜日常]

引用 10 楼 吉普赛的歌 的回复:

引用 9 楼 吃瓜日常 的回复:

[quote=引用 8 楼 zjcxc--个人微信公共号同名 的回复:]
通常 JOIN 比 IN 好

是比in好，我现在in后面是一个变量，但是现在把in后面的数据变量存入临时表出现了问题，临时表一个字段无法一次存入大量的数据，也就是说join这条路走不通啊

你弄个测试的数据库， 只保留需要的表， 备份后放在百度云盘， 大家帮你也有个测试环境吧。[/quote]额，测试的话不太行的通，涉及到的表挺多的，谢谢大家的帮助，我再想想其他办法吧

[zjcxc]

引用 9 楼 吃瓜日常 的回复:

引用 8 楼 zjcxc--个人微信公共号同名 的回复:

通常 JOIN 比 IN 好

是比in好，我现在in后面是一个变量，但是现在把in后面的数据变量存入临时表出现了问题，临时表一个字段无法一次存入大量的数据，也就是说join这条路走不通啊

为什么是存入一个字段？不是一个值 一条记录么？

[吃瓜日常]

引用 12 楼 zjcxc--个人微信公共号同名 的回复:

引用 9 楼 吃瓜日常 的回复:

[quote=引用 8 楼 zjcxc--个人微信公共号同名 的回复:]
通常 JOIN 比 IN 好

是比in好，我现在in后面是一个变量，但是现在把in后面的数据变量存入临时表出现了问题，临时表一个字段无法一次存入大量的数据，也就是说join这条路走不通啊

为什么是存入一个字段？不是一个值 一条记录么？[/quote]就是相当于把一列数据存入一个临时表，而这个临时表就一个字段，也只有一列值，就这样，这一列数据的数据量非常大

[吃瓜日常]

引用 10 楼 吉普赛的歌 的回复:

引用 9 楼 吃瓜日常 的回复:

[quote=引用 8 楼 zjcxc--个人微信公共号同名 的回复:]
通常 JOIN 比 IN 好

是比in好，我现在in后面是一个变量，但是现在把in后面的数据变量存入临时表出现了问题，临时表一个字段无法一次存入大量的数据，也就是说join这条路走不通啊

你弄个测试的数据库， 只保留需要的表， 备份后放在百度云盘， 大家帮你也有个测试环境吧。[/quote]真分頁做了，一次查詢30條數據，sql in後面改為JOIN表，可是還是不行，真分頁對速度有提升，但是提升很有限，sql in join表後面查詢速度不知道，但是插入數據的時候特別慢，還不如原有效果

[plutoppppp]

要用到in的情况，一般join做了就没什么意义了吧？光插入就要耗费很多时间。如果是少量的in一下时间也会在可接受范围内，如果多了并且是数字类型的时候可以考虑将id按桶的思想处理下，比如要查询1,2,3,4,6 可以where (1<=id and id<=4)or id=6，如果要排序分页！这种方式不如交给数据库服务器处理，毕竟少一步数据传输。

[吉普赛的歌]

引用 11 楼 吃瓜日常 的回复:

引用 10 楼 吉普赛的歌 的回复:

[quote=引用 9 楼 吃瓜日常 的回复:]
[quote=引用 8 楼 zjcxc--个人微信公共号同名 的回复:]
通常 JOIN 比 IN 好

是比in好，我现在in后面是一个变量，但是现在把in后面的数据变量存入临时表出现了问题，临时表一个字段无法一次存入大量的数据，也就是说join这条路走不通啊

你弄个测试的数据库， 只保留需要的表， 备份后放在百度云盘， 大家帮你也有个测试环境吧。[/quote]额，测试的话不太行的通，涉及到的表挺多的，谢谢大家的帮助，我再想想其他办法吧[/quote]
表多能有多少个？十个二十个？
多也不怕， 把敏感数据更改一下就可以了。

你实在不愿意也行。把你的原始sql发出来， 把表的大小、相关索引贴出来再说吧。
凭空想象， 对DBA来说是没有办法优化的。