相关疑难解决方法(0)

关于LIKE查询数据库中特定表的响应时间,我看到了相当大的变化.有时我会在200-400毫秒内得到结果(非常可接受),但有时候返回结果可能需要30秒.

我知道LIKE查询是非常耗费资源的,但我只是不明白为什么响应时间会有这么大的差异.我已经在该owner1字段上构建了一个btree索引,但我认为这对LIKE查询没有帮助.有人有主意吗？

示例SQL:

SELECT gid, owner1 FORM parcels
WHERE owner1 ILIKE '%someones name%' LIMIT 10

我也尝试过:

SELECT gid, owner1 FROM parcels
WHERE lower(owner1) LIKE lower('%someones name%') LIMIT 10

和:

SELECT gid, owner1 FROM parcels
WHERE lower(owner1) LIKE lower('someones name%') LIMIT 10

有类似的结果.
表行数:约95,000.

在Microsoft SQL Server中,可以指定"重音不敏感"排序规则(对于数据库,表或列),这意味着可以进行类似的查询

SELECT * FROM users WHERE name LIKE 'João'

找到一个带有Joao名字的行.

我知道可以使用unaccent_string contrib函数从PostgreSQL中删除字符串中的重音符号,但我想知道PostgreSQL是否支持这些"重音不敏感"排序规则,以便SELECT上述方法可行.

使用PostgreSQL 8.4.9,我对查询的PostgreSQL性能有一个奇怪的问题.此查询正在选择3D卷中的一组点,使用a LEFT OUTER JOIN添加相关ID列,其中存在相关ID.x范围的微小变化可能导致PostgreSQL选择不同的查询计划,执行时间从0.01秒到50秒.这是有问题的查询:

SELECT treenode.id AS id,
       treenode.parent_id AS parentid,
       (treenode.location).x AS x,
       (treenode.location).y AS y,
       (treenode.location).z AS z,
       treenode.confidence AS confidence,
       treenode.user_id AS user_id,
       treenode.radius AS radius,
       ((treenode.location).z - 50) AS z_diff,
       treenode_class_instance.class_instance_id AS skeleton_id
  FROM treenode LEFT OUTER JOIN
         (treenode_class_instance INNER JOIN
          class_instance ON treenode_class_instance.class_instance_id
                                                  = class_instance.id
                            AND class_instance.class_id = 7828307)
       ON (treenode_class_instance.treenode_id = treenode.id
           AND treenode_class_instance.relation_id = 7828321)
  WHERE treenode.project_id = 4
    AND (treenode.location).x >= 8000
    AND (treenode.location).x <= (8000 + 4736) …

我有一个下表结构.

USERS

PROPERTY_VALUE

PROPERTY_NAME

USER_PROPERTY_MAP

我正在尝试从users表中检索具有匹配属性的用户property_value.

单个用户可以拥有多个属性.这里的示例数据有2个用户'1'的属性,但是可以有2个以上.我想在WHERE子句中使用所有这些用户属性.

如果用户具有单个属性但是对于多于1个属性失败,则此查询有效:

SELECT * FROM users u
INNER JOIN user_property_map upm ON u.id = upm.user_id
INNER JOIN property_value pv ON upm.property_value_id = pv.id
INNER JOIN property_name pn ON pv.property_name_id = pn.id
WHERE (pn.id = 1 AND pv.id IN (SELECT id FROM property_value WHERE value like '101')
AND pn.id = 2 AND pv.id IN (SELECT id FROM property_value WHERE value like '102')) and u.user_name = 'user1' and u.city = …

SELECT DISTINCT options.id, options.foo_option_id, options.description
FROM vehicles 
INNER JOIN vehicle_options     ON vehicle_options.vehicle_id = vehicles.id 
INNER JOIN options             ON options.id = vehicle_options.option_id 
INNER JOIN discounted_vehicles ON vehicles.id = discounted_vehicles.vehicle_id 
WHERE discounted_vehicles.discount_id = 4;

上面的查询返回 2067 行，它在 1.7 秒内在本地运行。我想知道它是否尽可能快，或者我是否可以以某种方式进一步调整它，因为这个数据集会随着时间的推移而快速增长。

我在速度不变的情况下尝试过的事情：

1 - 更改连接顺序，从最小的表连接到最大的表。

2 - 向discounted_vehicles.discount_id 添加索引。