问题标签 [query-performance]

我需要找到托运货物中每件货物的最新位置。我们主要通过查看为托运选择的路线然后找到针对该路线的节点输入的最新（最大）时间来做到这一点。例如，如果一条路线有 5 个节点，并且我们输入了针对前 3 个节点的时间，那么最新的时间（最大时间）将告诉我们它在 3 个节点中的位置。
我真的被困在这个关于性能问题的查询上。即使在几百行上，也需要超过 2 分钟。请建议我如何改进这个查询或我应该获得的任何替代方法？

注：ATA = 实际到达时间 ATD = 实际出发时间

我在 SQL Server 2008 Express SP2 数据库上有一个大存储过程，大约每 200 毫秒运行一次。正常执行时间约为 50ms。我看到的是在这个运行时存在很大的不一致。它将执行一段时间，例如预期的 40-60 毫秒 50-100 次，然后似乎随机相同的存储过程将花费更长的时间，例如 900 毫秒或 1.5 秒来运行。有时，连续多次调用同一过程也会花费更长的时间。

似乎有些东西导致 sql server 每分钟左右都急剧变慢，但我不知道是什么。发生之间没有时间模式。

我在两台不同的计算机上安装了相同的设置，其中一台是干净的 XP Pro 加载，没有病毒检查，除了 SQL 服务器之外什么都没有安装。

此外，所有数据库的恢复选项都设置为“简单”。

假设我对数据库表有两个查询。

查询是根据查询中使用的字段定义的：

Query1：取决于 f1、f2 和 f3

Query2：取决于 f1、f2、f3 和 f4

我记得在某处读到 SQL 查询引擎（在本例中为 mySQL）从索引中最左侧的字段开始解析索引树。

如果这是正确的，那么我假设不是像这样在表上定义两个索引：

我可以简单地定义一个索引，其中包含两个查询中使用的键的联合——即

我只需要定义这个索引：

我有两个问题：

1. 我的假设正确吗？即我可以简单地定义一个索引（the_idx）而不是前两个吗？

2. 这种索引行为是否也适用于 PostgreSQL 查询引擎？

就服务器负载而言，是否有更快的方法来执行这个最简单的查询？除了这种方法，我认为我从未尝试过任何其他方法：

有什么办法可以改善这一点？

我在 SQL Server 数据库中有一个包含 10+ 百万条记录的大表。该表包含美国所有 50 个州的某些类型的数据。因此，如果我从这个表中创建 50 个视图，每个状态一个，从我的应用程序进行查询的性能会得到改善吗？其他建议？

我有一个导致性能问题的 T-SQL 查询。它很笨重，但似乎导致问题的部分是一个简单的 LEFT JOIN。

这可以通过删除左连接并在选择中使用子查询来解决，但这对我来说似乎并不令人满意，因为我看不出为什么一个工作得很快，另一个工作得不好。

涉及的数据不多，并且所有连接列上都有键/索引。我唯一想知道的另一件事是关于数据库的统计信息以及它们是否会影响性能。

例如（Nb 这只是一个更复杂的查询的简化

慢的

快速地

SELECT A.1, A.2, (SELECT B.3 FROM B WHERE B.ID = A.ID) FROM A

为了争论，假设它是针对 SQL 2005/8 的。我了解当您在表上放置索引以调整SELECT语句时，这些索引需要在INSERT//操作期间维护UPDATE。DELETE

我的主要问题是：

SQL Server 何时维护表的索引？

我有很多后续问题：

我天真地假设它会在命令执行后这样做。假设您要插入 20 行，它会在插入并提交 20 行后维护索引。

• 如果脚本具有针对表的多个语句，但在其他方面是不同的语句，会发生什么情况？

• 服务器是否具有在执行所有语句后维护索引的智能，还是每个语句都执行此操作？

我见过在大型/许多INSERT/UPDATE操作之后删除并重新创建索引的情况。

• 即使您只更改少数行，这可能会导致重建整个表的索引？

• 与进行许多较小的插入相比，尝试整理INSERT和 UPDATE操作成更大的批次（例如通过收集行以插入到临时表中）是否会带来性能优势？

• 如何整理上面的行以防止删除索引而不是进行维护？

很抱歉问题泛滥 - 这是我一直都知道要注意的事情，但是在尝试调整脚本以获得平衡时，我发现我实际上不知道何时进行索引维护。

编辑：我知道性能问题很大程度上取决于插入/更新期间的数据量和索引数量。再次为了争论，我有两种情况：

• 为选择调整的索引重表。
• 索引灯台 (PK)。

这两种情况都会有一个大的插入/更新批次，比如 10k+ 行。

编辑 2：我知道能够在数据集上分析给定脚本。但是，分析并不能告诉我为什么给定的方法比另一种更快。我对索引背后的理论以及性能问题的根源更感兴趣，而不是确定的“这比那个更快”的答案。

谢谢。

我遇到了 MySQL 的奇怪行为。查询执行（即explain [QUERY] 所示的索引的使用）和执行所需的时间取决于where 子句的元素。

这是出现问题的查询：

对应的解释输出为：

如您所见，单列索引与其所属的列具有相同的名称。我还添加了一些无用的索引以及使用的索引，只是为了查看它们是否会更改执行（它们不会）。

执行大约需要 4.5 秒。

当我将列 entl1.name 添加到选择部分（没有其他更改）时，el1 中的索引 fk_ent 不能再使用：

现在执行大约需要 8.5 秒。

我一直认为查询的选择部分不会影响引擎对索引的使用，也不会以这种方式影响性能。

省略属性不是解决方案，我必须选择更多属性。更糟糕的是，使用形式的查询更加复杂，这使得性能问题成为一个大问题。

所以我的问题是：1）这种奇怪行为的原因是什么？2）如何解决性能问题？

谢谢你的帮助！格雷德

我有一个偶尔会抛出这个错误的网络应用程序......

异常消息：超时已过期。在操作完成之前超时时间已过或服务器没有响应。

当我这样做时，即使通过管理工作室，我也无法连接到 SQL 服务器，它说服务器超时并且无法连接。

一旦我重置 iis，它就会立即恢复。所以这显然意味着我的代码中的某些东西导致了这种情况。我有一个 MVC 站点，它使用 Linq to SQL 和 SQL 缓存依赖项并启用了服务代理。

我在整个代码中彻底使用了 using 语句，所以我确定它不是泄漏连接。阅读服务器日志会使事情变得更加混乱，因为有很多信息和警告事件，我不是系统管理员，所以很难知道发生了什么。

首先是我收到 ASP.net 4.xxxxx 事件 ID 1309 异常消息：超时已过期。在操作完成之前超时时间已过或服务器没有响应。错误

我想我上次在我以前的服务器上通过重新启动 IIS 来解决它，当这个错误弹出时，这是我不想在这个新服务器上求助的东西。

所以我的问题是，我可以采取哪些步骤来尝试减少但理想情况下消除此超时错误？

非常感谢任何帮助

特鲁吉利

全部，

当我在性能方面运行查询时，我看到了一些非常奇怪的行为，即在使用开始时设置的变量与实际使用该值作为查询中的常量之间。

我看到的是

跑得比我跑时快得多

这显然是实际查询的一个更简单的版本，但有谁知道 SQL Server 2005 中的已知问题，它解析可以解释这种行为的查询的方式。我的原始查询在两种方法之间从 13 秒到 8 分钟。

谢谢，阿希什