问题标签 [database-performance]

这是我发现自己所处的场景。

我有一个相当大的表，我需要从中查询最新记录。这是查询的基本列的创建：

ID 列是主键，并且 VehicleID 和 TimeStamp 上有一个非聚集索引

我正在优化我的查询的表有超过 2300 万行，并且只是查询需要操作的大小的十分之一。

我需要返回每个 VehicleID 的最新行。

我一直在 StackOverflow 上查看对这个问题的回答，并且我已经做了一些谷歌搜索，在 SQL Server 2005 及更高版本上似乎有 3 或 4 种常见的方法来执行此操作。

到目前为止，我发现的最快方法是以下查询：

使用表中的当前数据量，执行大约需要 6 秒，这在合理的范围内，但是随着表将包含在实时环境中的数据量，查询开始执行太慢。

查看执行计划，我关心的是 SQL Server 为返回行所做的工作。

我无法发布执行计划图像，因为我的 Reputation 不够高，但索引扫描正在解析表中的每一行，这大大减慢了查询速度。

我尝试使用几种不同的方法重写查询，包括使用 SQL 2005 Partition 方法，如下所示：

但是该查询的性能甚至差很多。

我尝试过像这样重新构建查询，但结果速度和查询执行计划几乎相同：

我在表结构方面有一些灵活性（尽管程度有限），所以我可以向数据库添加索引、索引视图等，甚至可以添加额外的表。

我将非常感谢这里的任何帮助。

编辑添加了执行计划图像的链接。

一些基础知识

我有两张表，一张保存用户，一张保存登录日志。用户表包含大约 15000 多个用户，登录表正在增长并达到 150000 多个帖子。该数据库建立在 SQL Server（不是 express）之上。

为了管理用户，我得到了一个从 ObjectDatasource 填充的 gridview（来自 Devexpress 的 ASPxGridView）。

在总结用户的登录次数时，我应该知道哪些一般的注意事项。

事情变得异常缓慢。

这是一张显示相关表格的图片。

我已经尝试了几件事。

执行时间：01:29.316（1分29秒）

执行时间：01:18.410（1分18秒）

执行时间：01:15.821（1分15秒）

提供最佳性能的模型实际上是字典。但是，您知道我想听到的任何选项，以及在处理如此大量的数据时这种编码是否存在“不好”的地方。

谢谢

==================================================== ======

根据 BrokenGlass 示例更新了模型

执行时间：02:01.135（2分1秒）

除此之外，我创建了一个存储一个简单类的列表

并在总结方法中

执行时间：00:36.841（36秒）

到目前为止的结论，用 linq 总结很慢，但我到了那里！

我正在实现一个应用程序来跟踪查看帖子的次数。但我想保持一种“智能”的跟踪方式。这意味着，我不想仅仅因为用户刷新他的浏览器而增加查看计数器。

所以我决定只在 IP 和用户代理（浏览器）是唯一的情况下增加查看计数器。到目前为止，这是有效的。

但后来我想。如果 Youtube 是这样做的，他们有几个视频有数千甚至数百万的观看次数。这意味着他们在数据库中的视图表将被过度填充 IP 和用户代理......

这让我假设他们的视频表有一个用于视图的计数器缓存（即views_count）。这意味着，当用户点击视频时，会存储 IP 和用户代理。另外，增加了视频表中的计数器缓存列。

每次点击视频。Youtube 需要查询视图表并计算条目数。这不会严重影响性能吗？

他们是这样做的吗？或者，还有更好的方法？

为什么位图索引操作需要权衡高 CPU 限制？

我正在开发一个越来越受欢迎的移动网站，这导致一些关键数据库表的增长——我们在访问这些表时开始看到一些性能问题。我们不是数据库专家（现阶段也没有钱聘请任何人），我们正在努力了解导致性能问题的原因。我们的表不是那么大，所以 SQL Server 应该能够很好地处理它们，并且我们已经完成了我们在优化查询方面所做的一切。所以这是（伪）表结构：

我们预计这些行数会大幅增长（尤其是 user、content_group 和 content 表）。是的，用户表有很多列——我们已经确定了一些可以移动到其他表中的列。我们还对受影响的表应用了一堆索引，这些索引很有帮助。

最大的性能问题是我们用于搜索用户的存储过程（包括在 content_group_id 字段上连接到内容表）。我们尝试使用各种不同的方法来修改WHEREandAND子句，我们认为我们已经尽可能地完善了它们，但仍然太慢了。

我们尝试的另一件事没有帮助是在用户和内容表上放置一个索引视图。当我们这样做时没有明显的性能提升，所以我们放弃了这个想法，因为拥有视图层固有的额外复杂性。

那么，我们有哪些选择呢？我们可以想到一些，但都有优点和缺点：

表结构的非规范化

在用户表和内容表之间添加多个直接外键约束 - 因此每个内容子类型的内容表会有不同的外键。

优点：

• 通过使用其主键加入内容表将更加优化。

缺点：

• 我们现有的存储过程和网站代码会有很多变化。
• 维护多达 8 个额外的外键（更实际地，我们将只使用其中的 2 个）不会像当前的单个键那样容易。

表结构的更多非规范化

只需将我们需要的字段从内容表中直接复制到用户表中即可。

优点：

• 不再连接内容表 - 这大大减少了 SQL 必须做的工作。

缺点

• 同上：需要在用户表中维护的额外字段、对 SQL 和网站代码的更改。

创建中间层索引层

使用 Lucene.NET 之类的东西，我们会在数据库之上放置一个索引层。从理论上讲，这将提高所有搜索的性能，同时减少服务器上的负载。

优点：

• 这是一个很好的长期解决方案。Lucene 的存在是为了提高搜索引擎的性能。

缺点：

• 短期内会有更大的开发成本——我们需要尽快解决这个问题。

所以这些是我们想出的东西，在这个阶段，我们认为第二种选择是最好的——我知道非规范化有它的问题，但有时最好牺牲架构纯度以获得性能提升，所以我们准备支付这笔费用。

还有其他方法可能对我们有用吗？我上面概述的方法是否有任何其他优点和/或缺点可能会影响我们的决定？

我想知道使用表变量是否比使用内部联接（选择）的性能更高或更低
示例：

对于大型查询，如果您必须多次进行相同的连接，第一个更易于维护，但性能最高的是什么？

问候

我有一个站点和一个包含 500 万行的数据库，它的运行就像一个魅力。但是，我每小时运行一次清理 cronjob，将旧数据放入“日志”表并删除旧数据，此时服务器响应非常慢。是否可以通过 PHP 或 MySQL 降低该工作的优先级？

情况是我必须加入 10 多个不同的表。在 SQL 中，我加入同一个表 5 次。查询看起来像这样。

这个 Tab10 加入 5 次的原因是根据参数得到不同的值。是否可以以更好的方式重写 Tab10 连接？我还注意到由于这个 Tab10 加入，性能很差。

我在运行 MySQL 5.0.77 的应用程序中有一个快速增长的大型日志表。我正在尝试找到根据消息类型优化在过去 X 天内对实例进行计数的查询的最佳方法：

对于这个测试集，表中有 668521 行。我要优化的查询是：

目前，该查询需要 3-5 秒，估计如下：

删除 created_at 索引后，它看起来像这样：

（是的，由于某种原因，行估计大于表中的行数。）

因此，显然，该索引没有意义。

真的没有更好的方法来做到这一点吗？我尝试将该列作为时间戳，但结果却变慢了。

编辑：我发现将查询更改为使用间隔而不是特定日期最终会使用索引，将行估计减少到上述查询的 20% 左右：

我不完全确定为什么会发生这种情况，但我相当有信心，如果我理解了它，那么这个问题通常会更有意义。

我网站的主页有一个复杂的查询，如下所示：

我不会用确切的细节让你厌烦，而是做一个简短的解释：基本上这是系统中发生的事件列表，有点像流。一个事件可以有多种类型，并且根据其类型，它需要加入来自各种表的特定数据。

目前，此查询需要 2 秒才能运行，但随着条目数量的增加，它会随着时间的推移而变慢。因此，我正在寻求优化它。这是MYSQL解释的输出：

我对 EXPLAIN 的理解太有限，无法理解这一点。我宁愿保持这个查询原样（而不是对其进行非规范化），但要使用适当的索引或其他快速获胜来提高其性能。根据这个解释输出，你有什么可以跟进的吗？

编辑：根据要求特此定义 karmalog 表：