mysql查询性能不高

问题描述：

我有一个查询在过去几天运行了大约2个小时。但在此之前它只需要2到3分钟的时间。我无法找到其突然缓慢的原因。谁可以帮我这个事？请找到下面的查询说明计划[！[在这里输入的形象描述] [1] [1] ...mysql查询性能不高

select 
IFNULL(EMAIL,'') as EMAIL, 
IFNULL(SITE_CD,'') as SITE_CD, 
IFNULL(OPT_TYPE_CD,'') as OPT_TYPE_CD, 
IFNULL(OPT_IN_IND,'') as OPT_IN_IND, 
IFNULL(EVENT_TSP,'') as EVENT_TSP, 
IFNULL(APPLICATION,'') as APPLICATION 
from (
SELECT newsletter_entry.email email, 
     newsletter.site_cd site_cd, 
     REPLACE (newsletter.TYPE, 'OPTIN_','') opt_type_cd, 
     CASE 
     WHEN newsletter_event_temp.post_status = 'SUBSCRIBED' THEN 'Y' 
       WHEN newsletter_event_temp.post_status = 'UNSUBSCRIBED' THEN 
'N' 
      ELSE '' 
     END 
     opt_in_ind, 
     newsletter_event_temp.event_date event_tsp, 
     entry_context.application application 
FROM amg_toolkit.newsletter_entry, 
     amg_toolkit.newsletter, 
    (select NEWSLETTER_EVENT.* from amg_toolkit.NEWSLETTER_EVENT, 
amg_toolkit.entry_context where newsletter_event.EVENT_DATE >= '2017-07-11 
00:01:23' AND newsletter_event.EVENT_DATE < '2017-07-11 01:01:23' and 
newsletter_event.ENTRY_CONTEXT_ID = entry_context.ENTRY_CONTEXT_ID and 
entry_context.APPLICATION != 'feedbackloop') newsletter_event_temp, 
     amg_toolkit.entry_context 
WHERE newsletter_entry.newsletter_id = newsletter.newsletter_id 
     AND newsletter_entry.newsletter_entry_id = 
      newsletter_event_temp.newsletter_entry_id 
     AND newsletter.TYPE IN ('OPTIN_PRIM', 'OPTIN_THRD', 'OPTIN_WRLS') 
     AND newsletter_event_temp.entry_context_id NOT IN 
      (select d.ENTRY_CONTEXT_ID from amg_toolkit.sweepstake a, 
amg_toolkit.sweepstake_entry b, amg_toolkit.user_entry c, 
amg_toolkit.entry_context d where a.exclude_data = 'Y' and 
a.sweepstake_id=b.sweepstake_id and b.USER_ENTRY_ID=c.USER_ENTRY_ID and 
c.ENTRY_CONTEXT_ID = d.ENTRY_CONTEXT_ID) 
     AND newsletter_event_temp.entry_context_id = 
      entry_context.entry_context_id 
     AND newsletter_event_temp.event_date >= '2017-07-11 00:01:23' 
     AND newsletter_event_temp.event_date < '2017-07-11 01:01:23') a;` 




    [1]: https://i.stack.imgur.com/cgsS1.png

如果您不知道DBA，也许是时候找到一个。要么这样做，要么将查询缩小到最小。 – tadman

我是那个DBA，我不知道这个问题的根本原因。你能解释我的解决方案吗？ – saravana

开始从查询中删除东西，直到它不再缓慢，然后添加回来，直到找出导致问题的东西。一如往常。你还需要仔细检查你的指数范围。任何时候，当我看到一个这么大的查询时，我知道它在性能方面的表现会很糟糕。要使这种怪物具有高性能是非常困难的。 – tadman

答

不使用。* 只选择您所使用的数据列的查询。如果你不需要他们

避免嵌套子选择。

我没有看到在此查询需要他们。您以这种方式查询数据3次而不是一次。

步履维艰可以通过低效的查询到巡航能力处理有越来越多的记录表来解释。

“不在”是资源密集型。你能否以更好的方式避免“不在”逻辑？

答

JOINs通常比子查询更快。 NOT IN (SELECT ...)通常可以变成LEFT JOIN ... WHERE id IS NULL。

什么是a.exclude_data的a？看起来像一个语法错误。

这些指标都可能帮助：

newsletter_event: INDEX(ENTRY_CONTEXT_ID, EVENT_DATE) -- in this order

您还需要它newsetter_event_temp，但因为这是不可能的，东西已经给。你运行的是哪个版本的MySQL？也许你可以实际上CREATE TEMPORARY TABLE和ADD INDEX。

mysql查询性能不高

相关推荐