我们正在建立一个模型，在这里我们加入了一个13部分的简介( 01_01_resource_utilization_prepared )每天创建13条记录；这是一个故意的一对多的增长表的大小。
这是一个简单的查询，但我们已经尝试索引，但什么是最好的方式来优化这个查询？
SELECT
a.DATE,
a.RUN_ID,
a.HOURS,
a.HOURS * b.RESOURCE_DISTRIBUTION,
a.SCHEDULE_PROFILE_ID,
a.WEEKDAY_NUMBER,
a.SCHEDULE_DISTRIBUTION,
b.RESOURCE_DISTRIBUTION,
a.LOCATION_DESC,
a.DEPARTMENT_DESC,
a.LANGUAGE_DESC,
a.JOB_TITLE_DESC,
FROM
03_01_schedule a
LEFT JOIN 01_01_resource_utilization_prepared b ON (
a.RESOURCE_PROFILE_ID = b.RESOURCE_PROFILE_ID
AND a.DATE >= b.EFFECTIVE_FROM
AND a.DATE <= b.EFFECTIVE_TO
)
2条答案
按热度按时间webghufk1#
如果没有更多的信息，我不能确切地说，但性能将取决于您正在比较的列的索引。如果没有索引，连接可能必须扫描每一行，即“全表扫描”。
在mysql中，忘记声明外键是很常见的。
03_01_schedule.RESOURCE_PROFILE_ID以及01_01_resource_utilization_prepared.RESOURCE_PROFILE_ID应声明为外键，并将它们编入索引。这将使基本连接更快，并提供引用完整性。03_01_schedule.DATE,01_01_resource_utilization_prepared.EFFECTIVE_FROM，和01_01_resource_utilization_prepared.EFFECTIVE_TO都应该编入索引。这将使使用这些列进行比较更快。ntjbwcob2#
做
01_01参考1月1日？如果是这样的话，我认为这是一个糟糕的数据布局方式。但与此同时。。。在一个范围内检查，其中范围来自另一个表是很难优化的。这些综合指数
b会有一点帮助：是
LEFT需要？如果可以在不破坏语义的情况下删除它，那么就有一个更好的选择。正在删除LEFT会对你有用吗a:（同时，我不明白你在第一段中所说的话的相关性。）