使查询运行得更快 - 它没有加入答案

【问题标题】：Make query run faster - IT HAS NO JOIN使查询运行得更快 - 它没有加入
【发布时间】：2018-04-06 15:51:27
【问题描述】：

我得到了非常大量的数据，这些数据过去常常在任何地方加入以获得它（因为团队决定将它们全部收集到一个表中真的很慢），但现在即使它们确实是正确的一张表（无需连接）。

还是那么慢。进行一天的范围过滤器事件会导致超时（超过 10 秒，是的，这很糟糕）。

我应该向我的 DBA 提出什么建议？

【问题讨论】：

cough 索引 cough
和查询优化，尽可能避免全表扫描。
事实上，您的 DBA 应该向您推荐一些东西（如果他的薪水值得）。
你在过滤什么？如果你正在寻找？其中一列中的文本或其他内容？
What should I suggest to my DBA? plus ... the team decided to gather it all into one table 告诉您的 DBA 忽略团队，并且不要 DENORMALIZE，相反，他应该创建/维护正确的键/索引结构。

【解决方案1】：

什么是“选择性”？也就是说，您的选择期望检索多少行？ 100% 的行？ 1% 的行？ 0.01% 的行？

1.选择性低

如果选择性低（即小于 5%，理想情况下小于 0.5%），那么良好的索引是最佳做法。

如果是这样，where 子句（过滤列）中的哪些列具有最佳（最低）选择性？在索引中首先添加这些列。

一旦确定了最佳索引，您就可以使用该索引将表设为“聚集索引”表。这样，堆将由索引列进行预排序（快速查找），以改进 io，因为磁盘块将按顺序查找。

2。高选择性

如果选择性很高（20% 或更多），那么您无能为力（开发）。您仍然可以通过以下方式获得一些改进：

3.否则

您拥有的数据量大大超过了您拥有的数据库资源。您对此无能为力，只能将这一现实告诉客户，并且：

4.终于

如果您不了解选择性、全表扫描、索引、数据库资源、堆、磁盘块等术语，我建议您学习它们。我很确定你现在需要完全理解它们！

【讨论】：

【解决方案2】：

正如其他人所说，您需要一个索引。但是，如果它真的很大，您可以对数据进行分区。

这允许您在不使用耗时删除的情况下删除部分数据。例如，如果您正在处理某种历史数据并希望保留 3 个月的价值，您可以按月分区，然后每个月删除最旧的分区。

但是，一般来说，采用慢速多表查询并将其全部组合在一起以提高性能并不是一个好主意。你真正需要的是找出慢查询的问题并修复它。

这是您的 DBA 的工作。

【讨论】：