我拥有的表数据大约有 200 万行，目前我正在运行的查询只是从表中选择所有数据 (select *)。
这是一个非常天真的查询优化案例，但我想了解的真正意图是解释分析。
这是开启计时的解释分析的输出。
查询计划
Seq Scan on sample (cost=0.00..37929.83 rows=2185783 width=26) (actual time=0.065..348.752 rows=2185712 loops=1)
Planning time: 0.102 ms
Execution time: 463.020 ms
(3 rows)
因此，最大执行时间为0.3秒。
问题
- 这个时间估计有多现实？我在 Pgadmin 上运行以在行上执行 select * 并且需要 30 秒。这是有道理的，因为它需要在屏幕上打印出整个数据。但这是否意味着数据库端的优化部分已经完成并且我们通常面临的问题是打印数据
- 我正在使用 JDBC 打印数据。获取和打印数据大约需要 45 秒。假设 0.3 秒是实际数据库时间，其余时间由 Java 程序打印出来？我在同一系统上运行，因此排除了网络 I/O。
我是数据库优化的新手，我只是想了解如何理解 postgres 中的 explain analyze 以及如何实际估计查询运行时间以及如何确定是否需要在数据库方面进行任何改进？
最佳答案
EXPLAIN ANALYZE 显示的实际时间是真实的。您可以信任它，因为您想要优化数据库执行而不是其他因素，例如 - 在 Java 中提取它，从中创建对象，打印它，IOPS 等。时间也会根据当时在您的计算机上运行的其他进程而有所不同机器。
比较原始计划和优化计划总能给你更现实的见解。
大多数时候查询执行时间是问题所在。其他因素非常标准。
如何决定是否需要查询优化: 如果您的查询计划中有这些东西，那么您的查询很可能需要优化:
- 大量循环。
- 如果您有堆扫描。
- 如果筛选的行数非常多。
- 对大表进行顺序扫描。
- 您有索引，但规划器没有使用它们。
- 大部分查询执行不是通过仅索引或索引扫描。
我使用这两种工具来可视化我的计划:
关于sql - 如何理解postgres解释分析？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32180550/