数据库性能优化是否与数据库或表的大小无关？

Question

如果通过重写一项操作或一段代码，在对一个记录为100,000条的表进行读写的过程中，性能提高了30%，那么如果表增长并将有10,000,000条记录(即仍然是30% )，该优化是否保持不变？

考虑到硬件还没有被修改。

Answer 1

如果开发表(100 K)的抽样与实际prod表保持一致，那么统计数据应该显示相同的查询计划，因此性能的提高应该保持相当一致。但是，这取决于确保硬件是相同的，系统上的负载是相同的。当你说增加30%时，我们说的是查询时间吗？IO读的？CPU时间？在开发时，我总是告诉我的开发人员从读取(设置统计信息IO )的角度来查看性能。CPU和查询时间可能取决于许多因素。但是，在硬件和系统上的任何其他负载中，读取始终保持不变(只需确保查看逻辑读取，而不是物理读取)。

Answer 2

没有确切的答案。这取决于您所执行的数据和更改。

例如，如果您在100,000条记录表中创建了一个索引，那么在许多情况下，它将帮助处理10,000,000条记录表。

但是，如果您有一个游标，并且已经将它重写为基于集合的解决方案，那么对于100,000,000条记录表来说，它就足够了，但是在10,000,000条记录表中却不是很好，因为查询没有支持索引。

最好的做法是监视系统的增长，查看查询是否保持快速运行或降级，并相应地进行修复。

Answer 3

查询计划的生成非常复杂。随着查询的复杂性，可能计划的数量呈指数级增长。每一个可能的计划都是在一个小范围的数据计数和分布范围内的最佳方案。然而，如果改变其中的任何一个，那么另一个计划就会变得最优。假设您添加了一个索引。这可以用于某些计数和分发。对于不同的范围，优化者可能选择不使用索引的计划，所以索引也可能不存在。(实际上，它是通过较慢的插入造成损害的。)这就是为什么总是最好根据实际的生产数据测试代码。

然而，在实践中，大多数开发都是针对“足够大”的数据集进行的，期望所看到的计划与大规模生产数据所产生的计划足够接近，因此差异并不重要。从总体上看，这似乎在实践中站得住脚。然而，在发布当天，可能会有令人讨厌的惊喜。

当然，如果您的代码更改是在过程应用程序中，而不是在被调用的SQL中，那么这将是线性扩展的，而且无论通过多少行，都会看到30%的相对改进。

毕加索工具帮助我可视化了变化统计方面计划的稳定性。