我的应用程序将 JPA 与 Hibernate 结合使用，我发现 Hibernate 在我的日志文件中生成了一些有趣的 SQL 查询，其中包含大量连接。该应用程序目前没有很多用户，我担心 hibernate 生成的一些查询会在数据库规模增长时引起问题。
我已经通过 EXPLAIN 命令运行了一些由 hibernate 生成的 sql 查询，以查看生成的查询计划。
EXPLAIN 的输出是否取决于数据库的大小？当我的数据库变大时，查询规划器会为相同的 SQL 查询生成不同的计划吗？
我应该在开发/部署周期的什么时候查看由休眠生成的 SQL 查询的 SQL 查询计划？什么时候使用 EXPLAIN 比较合适。
当数据库非常小以至于每个查询(无论看起来多么复杂)都在 0.5 秒内运行时，explain 的输出如何用于确定查询是否会成为问题？
我正在使用 Postgres 9.1 作为我的应用程序的数据库，但我对上述问题的一般答案很感兴趣。
最佳答案
实际上，@ams 你的评论是对的——使用解释和少量数据通常是没有意义的。
如果一个表只有 10 行，那么它很可能全部在一页中，并且读取一行的成本(大致)与读取所有 10 行的成本相同。首先访问索引然后获取页面比仅读取更昂贵大量阅读并忽略您不想要的内容。 PostgreSQL 的规划器有 configured costs对于索引读取、表读取、磁盘访问与缓存访问、排序等。它根据表的(近似)大小和 distribution of values 调整这些大小。在他们之中。它不做的(从待定的 9.2 版本开始)是考虑跨列或跨表相关性。它也不提供让您覆盖计划器选择的手动提示(与 MS-SQL 或 Oracle 不同)。
每个 RDBMS 的规划器都有不同的优点和缺点，但我认为可以公平地说 MySQL 的规划器是最弱的(尤其是在旧版本中)。
因此 - 如果您想知道您的系统在 100 个并发用户和数十亿行的情况下将如何执行，您将需要生成测试数据并加载其中相当大的一部分。更糟糕的是，您还希望具有大致相同的值分布。如果大多数客户有大约 10 张发票，但少数客户有 1000 张，那么您的测试数据需要反射(reflect)这一点。如果您需要跨多个 RDBMS 保持性能，则对所有 RDBMS 重复测试。
当然，这完全与系统的整体性能无关，后者取决于服务器的大小和功能及其所需的负载。一个系统可以应对负载的稳定增加，然后突然间您会看到性能迅速下降，因为超过了缓存大小等。
HTH
关于mysql - SQL 查询解释的结果是否取决于数据库的大小？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12313732/