标签: query-optimization

考虑以下2个表:

Table A:
id
event_time

Table B
id
start_time
end_time

表A中的每个记录都映射到表B中的恰好1个记录.这意味着表B没有重叠的句点.表A中的许多记录可以映射到表B中的相同记录.

我需要一个返回所有A.id,B.id对的查询.就像是:

SELECT A.id, B.id 
FROM A, B 
WHERE A.event_time BETWEEN B.start_time AND B.end_time

我正在使用MySQL,我无法优化此查询.表A中有约980条记录,表B中有130.000条,这需要永远.我知道这必须执行980个查询,但是在一台强壮的机器上花费超过15分钟是很奇怪的.有什么建议？

PS我无法更改数据库架构,但我可以添加索引.但是,时间字段上的索引(带有1或2个字段)无济于事.

当我优化我的2个单个查询以在不到0.02秒内运行然后UNION它们时,生成的查询需要超过1秒才能运行.此外,UNION ALL比UNION DISTINCT需要更长的时间.我认为允许重复会使查询运行得更快,而不是更慢.我真的最好分开运行2个查询吗？我更愿意使用UNION.

我目前正在尝试提高MySQL表的SELECTS速度,并希望了解有关改进它的方法的任何建议.

表中有超过3亿条记录,表中有结构标记,日期,值.主键是标签和日期的组合键.该表包含大约600个唯一标签的信息,这些标签大多数包含平均约400,000行但可以在2000到超过1,100万行的范围内.

针对表运行的查询是:

  SELECT date,
         value 
    FROM table 
   WHERE tag = "a" 
     AND date BETWEEN 'x' and 'y' 
ORDER BY date

....如果有任何插入,很少.

我已经尝试按标签将数据划分为不同数量的分区,但这似乎没有增加速度.

当我对我的查询做一个解释时

我看到它在第一行的"Extra"下面有"Using temporary; Using filesort".我知道这很糟糕,但我不知道它究竟是什么意思或如何解决它.

如果你想查看我的查询,这里是一个更普遍的问题,我问同一个查询:MySQL查询优化和一个菜鸟的EXPLAIN.作为参考,查询涉及24个表和23个连接.

我现在的问题是:

• "使用临时"和"使用filesort"是什么意思？
• 假设它们很糟糕,我该如何摆脱它们？

我有两种方法从数据库中选择一组条目:

  SELECT ... WHERE `level` IN (1,2,4,8) LIMIT ...;  

要么

  SELECT ... WHERE `level` & mask LIMIT ...;

总共有4个'级别',编号为1,2,4,8(因为其他地方也可以使用相同的面具).两者的括号IN()或mask可以包含任何一组的一个或多个的4个级别的.该列已编入索引.查询仍然比舒适更长,我们正在努力优化速度.

昨天一个人说决定使用天真的IN()导致最多四次比较,而我应该使用位掩码代替.今天我听说位掩码将完全阻止列上索引的优势,并且会慢得多.

你能告诉我哪种方法会更快吗？

在查询优化期间,我包含了sql server(Sql Server 2008 R2 Enterprise)的奇怪行为.我在表上创建了几个索引,以及一些索引视图.我有两个查询,例如:

select top 10 N0."Oid",N1."ObjectType",N1."OptimisticLockField" from ((("dbo"."Issue" N0
 inner join "dbo"."Article" N1 on (N0."Oid" = N1."Oid"))
 inner join "dbo"."ProductLink" N2 on (N1."ProductLink" = N2."Oid"))
 inner join "dbo"."Technology" N3 on (N2."Technology" = N3."Oid"))
where (N1."GCRecord" is null and (N0."IsPrivate" = 0) and ((N0."HasMarkedAnswers" = 0) or N0."HasMarkedAnswers" is null) and (N3."Name" = N'Discussions'))
order by N1."ModifiedOn" desc

和

select top 30 N0."Oid",N1."ObjectType",N1."OptimisticLockField" from ((("dbo"."Issue" N0
 inner join "dbo"."Article" N1 on (N0."Oid" = N1."Oid"))
 inner join "dbo"."ProductLink" …

我想知道这些运营商的差异,主要是他们的性能差异.

我在SQL中查看了<>和!=之间的区别,它没有与性能相关的信息.

然后我在dba-oracle.com上发现了这一点,它表明在10.2以后性能可能会有很大不同.

我想知道为什么？不!=总是有更好的表现,然后<>？

注意:我们的测试和实时系统的性能显示,从更改<>到!=对查询返回的时间有很大影响.我在这里问为什么会发生这种情况,而不是它们是否相同.我在语义上知道它们,但实际上它们是不同的.

所以我有一个有趣的问题,我不确定是否被视为'黑客'.我查看了一些问题,但没有找到重复,所以在这里.基本上,我需要知道这是不可靠还是被认为是不好的做法.

我有一个非常简单的表,具有唯一的自动递增ID和created_at时间戳.(我的问题的简化版本,以澄清有问题的概念)

+-----------+--------------------+
| id        |created_at          |
+-----------+--------------------+
| 1         |2012-12-11 20:35:19 |
| 2         |2012-12-12 20:35:19 |
| 3         |2012-12-13 20:35:19 |
| 4         |2012-12-14 20:35:19 |
+-----------+--------------------+

这两个列都是动态添加的,因此可以说新的'insert' 总是具有更大的id并且总是有更大的日期.

目标 - 非常简单地按降序抓取created_at排序的结果

SOLUTION ONE - 按日期降序排序的查询

SELECT * FROM tablename
ORDER BY created_at DESC

解决方案两 - 按ID按降序排序的查询

SELECT * FROM tablename
ORDER BY id DESC

解决方案二被视为不良做法吗？或解决方案二是正确的做事方式.任何对你的推理的解释都会非常有用,因为我试图理解这个概念,而不仅仅是简单地得到答案.提前致谢.

我有这个查询(在postgresql中):

SELECT "table_1".* FROM "table_1"
INNER JOIN "join_table"
  ON "table_1"."id" = "join_table"."table_1_id"
WHERE "join_table"."table_2_id" = 650727
ORDER BY table_1.created_at DESC
LIMIT 1

返回1个结果,但执行时间约为250-300毫秒

还有btree索引table_1.created_at,以及join_table.table_1_id和join_table.table_2_id

当我只LIMIT 1从查询中删除时,执行时间下降到~13ms.此特定查询当前仅返回一个结果(没有LIMIT),但是在WHERE中还有其他值可能返回更多(这就是LIMIT是必要的原因).

为什么在一个只返回单个结果的查询中添加一个LIMIT,这会导致执行时间过多？

这是解释计划LIMIT 1(这些对我来说很难完全理解......):http://explain.depesz.com/s/rOy

这是没有LIMIT 1的解释计划:http://explain.depesz.com/s/q3d7

此外,如果我保留LIMIT 1,但将顺序更改为ASC,则查询也会降至13毫秒.如果我更改LIMIT为LIMIT 20(但保持ORDER BY DESC)它只需要22毫秒... wtf!？

所以它与组合有关ORDER BY DESC,并且LIMIT 1(确切地说是1)

我有简单但很长的查询,它计算结果的内容大约需要14秒.主表上的计数本身不到一秒钟,但在多次加入后,延迟太高,如下所示

Select  Count(Distinct visits.id) As Count_id
    From  visits
    Left Join  clients_locations  ON visits.client_location_id = clients_locations.id
    Left Join  clients  ON clients_locations.client_id = clients.id
    Left Join  locations  ON clients_locations.location_id = locations.id
    Left Join  users  ON visits.user_id = users.id
    Left Join  potentialities  ON clients_locations.potentiality = potentialities.id
    Left Join  classes  ON clients_locations.class = classes.id
    Left Join  professions  ON clients.profession_id = professions.id
    Inner Join  specialties  ON clients.specialty_id = specialties.id
    Left Join  districts  ON locations.district_id = districts.id
    Left Join  provinces  ON districts.province_id = provinces.id
    Left Join …