主题

对DB查询时间的长期监视可以揭示某些DB查询的速度变慢——这可能是由许多因素造成的。我们将讨论一些简单的检查，可以帮助缓解这些减速。

影响版本

-这个问题通常会影响Postgres支持的应用程序。所有JFrog产品主hth华体会最新官方网站要使用postgres，除了Artifactory，它是一个选项。

描述

当与索引配对时，数据库查询通常会加速-然而，索引可能会损坏并需要重新索引。

决议

登录Postgres后端(以admin用户)并运行以下查询:SELECT * FROM pg_class, pg_index WHERE pg_index。indisvalid = false AND pg_index。Indexrelid = pg_class.oid;

如果查询返回0行，从这个角度来看，您的索引是好的。但是，如果它返回一些行，这表明有一些索引需要重新索引。' relname '列将显示受影响的索引。第一部分将指示受影响的表。例如，如果列出了node_node_name_idx，则该索引属于nodes表。你可以通过以下方法解决:

可选的验证

旋转一个新的产品实例，由Postgres支持。我们的舵图是一个快速的方法，让这个运行起来。它不需要授权——因为我们正在测试索引的有效性并解释查询，而不是实际的现有数据。在下面的例子中，我正在测试Artifactory，所以我使用“npm-local”，它在我的节点表中没有任何引用:
Artifactory => select * from nodes;
Node_id | node_type | repo | node_path | node_name | depth | created | created_by | modified | modified_by | updated | bin_length | sha1_actual b| sha1_original | md5_actual | md5_original | sha256 |
repo_path_checksum
---------+-----------+------------------------+-----------+-----------+-------+---------------+------------+---------------+-------------+---------------+------------+-------------+---------------+------------+--------------+--------+--------
----------------------------------
1 | 0 |自动垃圾桶|。|。| 0 | 1657736169666 | | 1657736169666 | | 1657736169666 | 0 | | | | | | 3321383
d7f6d80140563c23d3a22d647e20cafb9
2 | 0 | jfrog-support-bundle |。|。| 0 | 1657736169735 | | 1657736169735 | | 1657736169735 | 0 | | | | | | 59c86c2
bf5350c9c8961a57057819bfeeba79617
4 | 0 | artifactory-build-info |。|。| 0 | 1657736169769 | | 1657736169769 | | 1657736169769 | 0 | | | | | | 1d06e7f
a42f6b62e8e8acf2ca0f0aba4d8b9e7ac
6 | 0 | example-repo-local |。|。| 0 | 1657736169777 | | 1657736169777 | | 1657736169777 | 0 | | | | | | ebc8002
cd055a81553b42555dcad19268adfff43
(4行)

选择一个慢速查询，并使用EXPLAIN ANALYZE 测试它是否使用索引。例如，这个查询通常使用索引，每个我的fresh DB实例:

如果node_path = 'somepath' AND node_name = ' someename ';查询计划
---------------------------------------------------------------------------------------------------------------------------
在节点上使用node_node_name_idx进行索引扫描(cost=0.14..8.16 rows=1 width=8)(实际时间=0.015..0.016 rows=0 loops=1)
索引Cond:((node_name)::text = ' someename '::text)
过滤器:(((回购)::文本=“npm-local”::文本)和((node_path)::文本=“somepath”::文本))
规划时间:0.252 ms
执行时间:0.048 ms
(5行)

如果查询计划使用索引扫描，这表明它使用了索引(我们可以在这里看到它使用了node_node_name_idx)。

当索引无效时，运行相同的explain analyze将显示' seq scan ':

如果node_path = 'somepath' AND node_name = ' someename ';
查询计划
---------------------------------------------------------------------------------------------------------------------------------------
对节点进行Seq扫描(成本=0.00..10.35行=1宽度=8)(实际时间=0.013..0.013行=0循环=1)
过滤器:(((回购)::文本=“npm-local”::文本)和((node_path)::文本=“somepath”::文本)和((node_name)::文本=“somename”::文本))
过滤删除的行数:4
规划时间:0.176 ms
执行时间:0.036 ms
(5行)

比较新鲜实例和真实实例之间的两个输出-如果索引扫描匹配，那么索引又开始工作了。