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。

区别必须是子选择。如果您使用的是unnest，则PostgreSQL将始终估计子查询返回100行，因为这是unnest的定义方式。

估计100一定会产生一个不同的执行计划，该计划会更好地工作。

我们需要完整的执行计划来说些不确定的事情。

Answer 2

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

找到这篇文章，说明indeexs如何在'ANY'和'IN'的不同构造函数中使用。

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

2 个答案: