当条件的参数从 4 个字符的单词更改为 11 个字符时，如何改进运行缓慢的查询

Question

假设我们有两个表的以下结构：

表：

device_usage

紧密关系

列名称	列类型
成本	数字
设备ID	uuid	外键 - 与 devices 表

表：

devices

列名称	列类型
组织_id	uuid	与组织范围设备的松散关系
类型	varchar	用作枚举字段，并在应用程序级别控制值 - 可能的值：水、电、煤气

我遇到的问题如下：

select
  device_usage.*
from
  device_usage
inner join
  devices on device_usage.device_id = devices.id
where
  devices.organization_id = 'some_uuid'
  and devices.type = 'water'
limit 10

当我使用

devices.type = 'water'

运行查询时，它会在 1 秒内返回 10 条记录。但是，当我将其更改为

devices.type = 'electricity'

时，大约需要 15 秒才能获取相同数量的记录。

顺便说一句，

device_usage

表中有超过 500 万条记录。

所以问题是：

1. 为什么当

   water

   变为

   electricity

   时，性能会有很大差异？
2. 对

   devices.type

   列使用 postgres 枚举而不是

   varchar

   会提高性能吗？
3. 对于这种结构，建议采用什么样的指数组合？

我为

divice_usage.device_id

列添加了索引，它提高了查询性能，但没有解决

electricity

参数运行缓慢的问题。

Answer 1

性能与过滤条件中使用的字符数没有直接关系，可能有几个潜在条件，例如

• 数据分布：

  devices.type

  的值可能不均匀分布。您确实提到两个查询返回相同数量的行，但这是因为它有

  limit

  。您可以不受限制地查看实际数量。例如，如果 devices.type = 'water' 的行数明显多于 devices.type = 'electricity' 的行数，则查询规划器可能具有更高效的水访问路径，但由于与设备匹配的行数较少，因此电的访问路径效率较低。后一种情况。这可能会导致 PostgreSQL 对某些值使用次优的查询计划。检查查询计划。
• 统计和查询计划：PostgreSQL 使用统计来确定最有效的查询计划。如果统计信息过时或不完整，尤其是表频繁更新或删除，可能会误判执行查询的最佳方式。您可以尝试通过VACCUM ANALYZE刷新统计信息。
• 将列类型转换为枚举可能会也可能不会提高性能，尽管枚举内部存储为整数，这与字符串相比可以有效进行比较，但如果存在具有不同类型类型的巨大数据集，这将是有益的。
• 您还可以尝试为organization_id和device_id创建分区