使用数组作为参数时，ANY 运算符会出现严重的性能问题

Question

由于某些参数绑定错误，我开始在查询中使用 'ANY()' 函数而不是 'IN'。目前是这样的。

Select * 
FROM geo_closure_leaf 
WHERE geoId = ANY(:geoIds)

但是对性能影响很大。使用带有 IN 的查询比使用 ANY 快得多。

关于如何绑定字符串参数数组的任何建议都可以在 'IN' 表达式中传递。

我尝试使用

进行临时修复

Select * 
FROM geo_closure_leaf 
WHERE geoId IN (''('' || array_to_string(:geoIds::text[] ,''),('') || '')'')

Select * 
FROM geo_closure_leaf 
WHERE geoId IN (select unnest(:geoIds::text[]))

geoIds = 字符串数组

它是这样工作的。

**public override T Query<T>(string query, IDictionary<string, object> parameters, Func<IDataReader, T> mapper)**
        {
            T Do(NpgsqlCommand command)
            {
                IDataReader reader = null;
                try
                {
                   ** command.CommandText = query;
                    reader = command.AddParameters(parameters).ExecuteReader();**
                    return mapper(reader);
                }
                finally
                {
                    CloseDataReader(reader);
                }
            }

            return Execute(Do);
        }

对象是字符串数组。

预期是：我应该能够做到这一点，而不必在 sql 中添加额外的逻辑。

Select * 
FROM geo_closure_leaf 
WHERE geoId IN (:geoIds)

Answer 1

性能差异不能是 IN 与 = ANY，因为 PostgreSQL 在查询优化期间会将 IN 转换为 = ANY。

区别一定是subselect。如果您使用 unnest，PostgreSQL 将始终估计子查询 returns 100 行，因为那是 unnest 的定义方式。

一定是 100 的估计以某种方式产生了一个不同的执行计划，而该执行计划恰好运行得更好。

我们需要完整的执行计划来说明不确定性。

Answer 2

https://dba.stackexchange.com/questions/125413/index-not-used-with-any-but-used-with-in

发现这个 post 解释了如何在 'ANY' 和 'IN' 的不同构造函数中使用索引。

使用数组作为参数时，ANY 运算符会出现严重的性能问题

ANY operator has significant performance problem when using an array as a parameter

postgresql

query-performance

sql-in