我们的大多数 REDSHIFT 查询都会进行段编译，这会提高我们的查询性能

Question

我们在 redshift 中运行范围受限查询，其中只有 employee_id 和business_date 不断变化。但是我们在 SVL_COMPILE 中不断看到我们的每小时段编译非常高。大多数查询正在编译，这为查询增加了额外的时间。

我们的产品团队不断使用不同的employee_id和business_date范围执行此查询。

1. 每小时点击量：每小时 1500 次查询。

2. business_date字段的日期格式: : yyyy-MM-dd

3. tillTime 是一个时间戳字段，其常量值为 9999-01-01 01:00:00 。我们在查询中保留了tilTime，因为我们在对条目进行里程碑时将tilTime 设置为当前日期。只有活动记录的值为 9999-01-01 01:00:00。

4. 查询正在从部署在的 Spring Boot 应用程序中执行 EC2 的实例数为 10。

5. employee_id：最多可以有 1 到 5 个employee_id。

6. business_date范围从1天到30天

7. 列：表中有 216 列。因此，选择查询中的数据库列是根据用户选择动态的。我们只获取用户请求的那些列。

查询：

Select coulmns from acconts table where   business_date between (?) and (?) and employee_id in (?) and  sysdate >tillTime.

我们的桌子配置是：

Sortkey: (SORTKEY(business_date,employee_id ,snap_type,tillTime))
Diststyle: AUTO(EVEN)

我们的集群配置是：

Node type: ra3.xlplue
Number of nodes: 10

我们尝试了以下方法：

查询：

Select coulmns  from acconts table where business_date between (?) and (?) and  emmployee_id in (?) and 
tillTime='9999-01-01 01:00:00'

仍然没有观察到太大的改善。 任何人都可以在这里指导为什么当 sysdate >tillTime 或tilTime='9999-01-01 01:00:00' 时编译段

Answer 1

这里有很多可能性，所以要提出一些想法来探索。 需要更多信息来缩小关注范围。

我的第一个猜测是，由于选项被发送到 Redshift，编译器算法在运行之间发生了变化。 IN 子句可以根据 IN 子句中有多少个值进行不同的编译。 一些值，这将编译为 OR 条件列表。 许多值和编译器都会使用伪连接结构。 计划不同，决定更改会导致重新编译。

您可能正在寻找这种重大变化。我的猜测只是猜测。 查看重新编译之前和之后的解释计划，看看它们之间有什么变化。 可能需要线索。

您的表定义和元数据有效性状态也很重要。 此信息用于决定使用哪种编译器算法，因此如果它明显过时，决策可能会改变。 您的桌子每小时更换一次吗？ 您多久更新和分析一次？