Help us learn about your current experience with the documentation. Take the survey.
查询性能指南
本文档介绍了优化 SQL 查询时需要遵循的各种指南。
在优化 SQL 查询时，需要注意两个维度：
- 查询执行时间。这至关重要，因为它反映了用户使用 GitLab 的体验。
- 查询计划。优化查询计划对于让查询能够独立随时间扩展很重要。认识到索引在表增长到查询性能下降之前能保持查询良好性能，就是我们分析这些计划的原因之一。
查询时间指南
| 查询类型 | 最大查询时间 | 说明 |
|---|---|---|
| 常规查询 | 100ms |
这不是一个硬性限制，但如果查询时间超过这个值，就需要花时间理解为什么可以或不能优化它。 |
| 迁移中的查询 | 100ms |
这与总的 迁移时间 不同。 |
| 迁移中的并发操作 | 5min |
并发操作不会阻塞数据库，但会阻塞 GitLab 更新。这包括诸如 add_concurrent_index、add_concurrent_foreign_key 和验证约束（例如通过 add_text_limit 添加文本限制）等操作。 |
| 迁移后的并发操作 | 20min |
并发操作不会阻塞数据库，但会阻塞 GitLab 后更新进程。这包括诸如 add_concurrent_index、add_concurrent_foreign_key 和验证约束（例如通过 add_text_limit 添加文本限制）等操作。如果索引创建超过 20 分钟，请考虑 异步索引创建。 |
| 后台迁移 | 1s |
|
| Service Ping | 1s |
更多详情请参见 Metrics Instrumentation 文档。 |
- 分析查询性能时，请注意看到的时间是 冷缓存还是热缓存。这些指南适用于两种缓存类型。
- 使用批量查询时，更改范围和批量大小，以查看它如何影响查询时间和缓存。
- 如果现有查询性能不佳，请努力改进它。如果它太复杂或会阻碍开发，请创建后续任务以便及时解决。您总是可以向数据库审查者或维护者寻求帮助和指导。
冷缓存和热缓存
评估查询性能时，理解冷缓存查询和热缓存查询之间的差异很重要。
第一次执行查询时，是在"冷缓存"上进行的。这意味着需要从磁盘读取数据。如果再次运行查询，数据可以从缓存中读取，也就是 PostgreSQL 所说的共享缓冲区。这就是"热缓存"查询。
分析 EXPLAIN 计划 时，您不仅可以在时间上看到差异，还可以通过使用 EXPLAIN(analyze, buffers) 运行 explain 来查看 Buffers 的输出。 Database Lab 会自动包含这些选项。
如果您正在执行热缓存查询，只会看到 shared hits。
例如，使用 Database Lab：
Shared buffers:
- hits: 36467 (~284.90 MiB) from the buffer pool
- reads: 0 from the OS file cache, including disk I/O或者在 psql 的 explain 计划中：
Buffers: shared hit=7323如果是冷缓存，您还会看到 reads。
使用 Database Lab：
Shared buffers:
- hits: 17204 (~134.40 MiB) from the buffer pool
- reads: 15229 (~119.00 MiB) from the OS file cache, including disk I/O在 psql 中：
Buffers: shared hit=7202 read=121慢速列表视图和 API
我们经常在 GitLab 中构建需要多种不同过滤和排序选项的过滤列表视图和 API。所有这些选项通常都封装在 finders 中，并通过 API/GraphQL 参数暴露。虽然我们有许多可能的 分页性能优化，但通常无法使所有排序和过滤的组合都高效。
尝试使许多选项高效可能涉及 添加过多索引，这会牺牲我们主数据库的性能。这仅适用于常见用例，不应被视为使所有过滤和排序排列都高效的方法。实际上，这意味着当应用某些排序或过滤选项时，可能会有过滤视图和 API 请求超时。我们仍然允许团队在特定过滤/排序组合对某些客户有益的情况下添加它们，但我们需要接受它们会对某些用户超时的事实。