重写以下 SQL 查询以使其更高效/改进其执行及其原因

Posted 2023-04-14

【中文标题】重写以下 SQL 查询以使其更高效/改进其执行及其原因

【英文标题】：Rewrite the following SQL query to turn it more efficient/improve its execution and the reasons for that

【发布时间】：2019-05-13 14:56:50

【问题描述】：

关系架构：

City(cityID, nameCity, nbInhabitants)
Company(companyID, companyName, nbEmployees, cityID) cityID: FK(City)

鉴于以下统计数据： • City 包含 4 000 个元组，每页 20 个元组 • 公司包含 200 000 个元组，每页 15 个元组

现在重写以下查询以改进其执行以及获得这些好处的原因：

SELECT DISTINCT companyID
FROM City NATURAL JOIN Company
WHERE nbEmployees >= 5000
AND nameCity = 'Lisboa'

非常感谢

【参考方案1】：

首先，我认为不需要select distinct。为什么companyId 会在company 表中重复？另外，我希望join 只引入一个城市。

避免使用natural join。这只是等待发生的错误。您不知道正在使用什么连接键，甚至没有使用正确声明的外键关系。

假设这是您的查询：

select c.CompanyId
from Company c join
     City ci
     on c.cityId = ci.cityId
where c.nbEmployees >= 5000 and ci.nameCity = 'Lisboa';

您有两种优化方法。我首先建议在Company(nbEmployees, cityId) 和City(cityId, 'Lisboa') 上建立索引。

如果您有很多公司拥有超过 5,000 名员工，而里斯本的公司很少，那么替代索引策略是 city(nameCity, cityId)、company(cityId, nbEmployees, companyId)。

【讨论】：

我忘了说 cityID 是 City 的 PK，companyID 是 Company 的 PK。这是否会改变您的答案？非常感谢！

关于您的第二个观察：如果我们假设员工人数大于 10 000 的公司经常通过 SQL 查询访问，该怎么办。考虑到关系 Company 的元组数量非常大（200 000），您会在这种情况下使用哪种模式调整机制来加快速度！谢谢！

@UserFriendly 。 . .如果这些是主键，则不需要 select distinct。我希望第一组索引没问题。至于你的第二个问题，你可能想问一个新问题。

所以即使考虑到主键，您会认为您重写的查询是该场景的最佳优化？非常感谢

@UserFriendly 。 . .查询本身在性能方面与您相似。优化的好处来自于索引。