我有一个与5个表联合起来的查询,它以大约0.2秒的时间执行,从我的数据库中检索36条记录。下面是对解释计划的分析,因为您可以看到即使那些已经附带索引的表仍然可以进行全表访问。
无论如何,如果有必要微调查询如下?
SELECT
CASE WHEN DS.NAME = 'InteractiveCustomer' THEN 'NA' ELSE CUS.SOURCE_SYSTEM END AS SOURCE_SYSTEM,
OU.ORGUNIT_CODE AS ORGANIZATION_UNITS,
SUM(
CASE WHEN WS.NAME = 'Pending Autoclosure' THEN 1 ELSE 0 END
) AS PENDING_AUTOCLOSURE,
SUM(
CASE WHEN WS.NAME = 'New' THEN 1 ELSE 0 END
) AS NEW,
SUM(
CASE WHEN WS.NAME = 'Under Investigation' THEN 1 ELSE 0 END
) AS UNDER_INVESTIGATION,
SUM(
CASE WHEN WS.NAME = 'Escalated' THEN 1 ELSE 0 END
) AS ESCALATED,
SUM(
CASE WHEN WS.NAME = 'Recommend True Positive' THEN 1 ELSE 0 END
) AS RECOMMEND_TRUE_POSITIVE,
SUM(
CASE WHEN WS.NAME = 'Reopen Under Investigation' THEN 1 ELSE 0 END
) AS REOPEN_UNDER_INVESTIGATION
FROM
WORKFLOW_STATUSES WS
JOIN WORKFLOW_WORKITEM WW ON WS.ID = WW.STATUS_ID
JOIN WLM_ALERT_HEADER WAH ON WW.ENTITY_KEY = WAH.ALERT_KEY
INNER JOIN ORGANIZATION_UNITS OU ON OU.ID = WAH.CUSTOMER_ORGUNIT_ID
LEFT JOIN CUSTOMERS CUS ON CUS.CUSTOMER_ID = WAH.CUSTOMER_ID
INNER JOIN DATA_SOURCE DS ON WAH.AT_DATASOURCE_ID = DS.ID
WHERE
WW.ENTITY_NAME = 'WLM Alert'
GROUP BY
OU.ORGUNIT_CODE,
CUS.SOURCE_SYSTEM,
DS.NAME;
答案 0 :(得分:2)
对于具有索引的表,仍然可能发生全表访问,即使查询使用索引列只是因为查询优化器可能认为如果更快将整个表数据放入内存而不是打扰去往索引,查找相关行,然后将它们从磁盘中取出
全表扫描不一定是坏事,但如果查询长时间无法接受并且怀疑是由于非常大的表上的FTS引起的,那么它可能是一个好的起点。在小桌子上,完整扫描是非常微不足道的
你问是否有必要对查询进行微调 - 我个人对此的看法是“不,不是现阶段” - 根据我的评论,将相关数据表提升一百万行,并再次运行了解它将如何扩展。你可能会得到一个完全不同的计划。即使它最终运行5秒钟,也可以平衡这个数据在生产中要求的次数 - 如果它是每10秒一次,那么确定,做一些事情。如果帐户女孩发出发票每月一次,即使需要一分钟,也不要打扰它
“过早优化是所有邪恶的根源”