问题标签 [query-tuning]

我正在运行一个查询 -

第一次执行时，需要 1 分钟。但在 3 分钟内执行相同的查询需要 3 分钟。

为什么会这样？

我也发现与其他查询相同的行为。

如果需要，请提供详细信息：
我的机器有 4 GB RAM
Mysql 5.5 版本。
key_buffer_size = 350M。

这张表有 1.4 亿条记录，有 10 个分区。

谢谢你。

我有一个非常简单的查询

其中有 508,000 行。当我第一次运行上述查询时，返回结果大约需要 53 秒。如果我再次重新运行查询，则返回结果需要几毫秒。

我相信 SQL Server 正在缓存查询/结果？我是否可以告诉 SQL Server 不要缓存查询/结果，或者以某种方式清除缓存/结果？

在我的应用程序中，我正在尝试进行一些性能调整，但上述问题对我没有帮助。

我在下面有一个用于搜索功能的 oracle SQL 查询，它包含在存储过程中。

它运行得很慢。

打开 p_cursor FOR SELECT TableA.*, TB_S.someColumn, TB_S.SomeColumn ..

数据库专家可以帮助我如何调整上述查询吗？

谢谢你。

我需要向临时表添加正确的索引以加快查询速度。根据 msdn，我检查菜单“包括实际执行计划”并在 SSMC 中运行查询，执行后我可以看到查询计划，但没有关于要创建的索引的指示。

在@Tax 表中，字段 l1,l2....l10 标识了元素在层次结构中的位置：

样本中的虚拟数据表示以下结构：

有了巨大的查询，我需要从最前面的 ex 中提取每条记录的所有父项的列表：

这是查询的结果（省略某些字段对示例不感兴趣） idleaf,description,node_path

询问：

如何从下面的查询中以更有效和优雅的方式获取 MY_LATEST_INSERTED_NUMBER_BASING_ON_MY_DATE_COLUMN_FOR_ID_CONTEXT ？

要求：按年和省创建的计费记录数。

数据库： DB2 9.5

下面是用于获取详细信息的查询，它需要大量时间，超过 1 小时并且超时。

每个表中的记录数如下。计费：900 万覆盖：100 万客户：300 万地址：400 万。

Created 是一个时间戳列。

由于查询中没有where子句，查询变慢了。请让我知道是否有任何方法可以优化查询。

我有一张HISTORY有 900 万条记录的表。我需要找到按年、按月创建的记录。我正在使用查询 1，但是它超时了几次。

我决定添加where year(created)，这次查询需要 30 分钟（是的，需要很长时间）才能执行。

我打算在created时间戳列上添加一个索引，但是在这样做之前，我需要意见（因为索引这么大的表需要很长时间）。

created(timestamp)考虑到列上使用了年份函数，在列上添加索引会提高性能吗？

我正在使用带有一个小图的 Neo4j 1.9.7 数据库：

我已经通过 Sail 导入了这些数据，以使用 SPARQL 插件来执行一些查询。我的图表有 3 个实体，BusinessProcess、ApplicationProcess、Database 链接如下

我将 neo4j 作为服务器运行并通过Advanced Rest Client for Chrome执行 localhost 查询，因为我仅将数据库用于读取数据。当我执行前 3 个查询时，一切正常。例如这个 sparql 查询

返回

这对我来说是可以接受的（我不需要真实的案例场景，只是一个 Neo4j 解决方案和 MySQL 上的相同数据库之间的比较，所以我不需要对两者进行完美的调整，只需要人类的耐心一个 =） )

我遇到了这个查询的问题

这应该说明哪些业务流程与特定的业务流程共享相同的数据库（示例中为 BusinessProcess9）。在这里，我的数据库似乎没有在可接受的人类时间内得出答案（它超过了一个小时而没有得出结论）。阅读手册和其他类似问题我认为这个查询不应该有那么大的问题。我试着稍微调整一下数据库，但情况并没有改善，所以我决定寻求帮助。

店铺详情：

使用

neo4j.properties

neo4j-wrapper.conf

如您所见，我保留了映射的默认配置（因为我的图表似乎适合它们）并且我将堆更改为 128M - 512M（根据手册应该可以工作）我注意到只有一个 CPU 内核在充分使用在查询期间，但据我所知，这是正常的，因为遍历一次只能在一个核心上发生。同样使用 jvisualvm 我注意到该过程从未达到完整的堆使用量（在一个小时内，我离开它的时间更长）。GC 似乎不是问题，因为它的活跃度约为 1.4/1.6%。CPU 使用率约为 20%

如果我在 Cypher 中运行查询，也会遇到同样的问题

是硬件问题吗（我的笔记本电脑不是我所知道的最好的），我应该尝试使用更多 RAM 来增加堆的东西（我可以在笔记本电脑开始使用交换之前将它提升到 1Gb）还是在那里'还有一些曲调可以做更多的事情吗？或者可能是查询问题？

编辑

在我写完之后，我尝试在密码查询中插入一个不同的子句并执行它 cia shell（阅读这个答案我想我可能会遇到类似的问题）。查询在 83118 毫秒后完成，结果为 374K+。所以我认为这不是数据库的调优问题，而是 SPARQL 查询写得不好。

编辑 Cypher 查询

结果（摘录）：

我有两张表，例如：table1 和 table2 如下表 Table1(id, desc) Table2(id, col1, col2.. col10 .....)

表 2 中的 col1 到 col10 可以与表 1 中的 id 字段链接。

我编写了一个查询，它有 10 个 table1 实例（每个实例将 col1 链接到 table2 的 col10）

此查询位于 Sp 内部，当我尝试在 SSMS 中执行 Sp 时，它可以正常工作。

但是，当我的 Web 应用程序运行时，查询适用于少数 where 子句值并挂起。

我检查了查询的成本，并在 table2 中用这 10 列创建了一个非聚集索引。发现连接的成本降低到 0。但是，我仍然看到查询挂起

表 1 有 500 行，表 2 有 700 行。任何人都可以帮助。

我在处理这个查询时遇到了问题。执行需要 10 个小时。

解释计划显示如下：

我尝试使用索引：

GCCOM_DELIVERY_NOTE 上的索引 IDX_GCCOM_DELIVERY_NOTE_30("ID_CONTRACTED_SERVICE",TO_CHAR("FORECAST_BILLING_DATE",'YYYYMM'))

GCCOM_DELIVERY_NOTE 上的索引 IDX_GCCOM_DELIVERY_NOTE_31("ID_CONTRACTED_SERVICE","DELIVERY_NOTE_STATUS","IND_SIMULATED",TO_CHAR("FORECAST_BILLING_DATE",'YYYYMM'));

GCCOM_LOST_HISTORY_SS 上的索引 IDX_GCCOMLOSTHISTORYSS_02("ID_SECTOR_SUPPLY","END_DATE","COD_VALUE");

但是解释计划并没有显示出很大的改进：

我正在比较应用索引前后的解释计划。

我看到访问路径发生了一些变化，但总体结果是相同的。

那么查询有什么改进吗？

这些是 TABLE ACCESS FULL，我必须在它们上创建索引吗？

我没有考虑用 GATHER_TABLE_STATS 的提示执行查询，让我试试！！

我带着结果回来了！！