我目前正在进行性能调整练习。该应用程序是数据库密集型的，处理逻辑很少。性能调优是围绕数据库调用的方式和数据库本身进行的。
我们进行了查询调优，我们放置了缺失的索引，我们尽可能减少或消除了数据库调用。该应用程序运行良好，一切正常。
使用较小的数据量（比如多达 100,000 条记录），性能非常出色。我的问题是，需要做些什么来确保在更高数据量下的良好性能？ 预计数据量将达到1000万条记录。
我可以想到表和索引分区，建议为数据库存储和定期归档优化文件系统以控制行数。我想知道还能做什么。任何提示/策略/模式都会非常有帮助。
【问题讨论】：
标签： database performance
监控。使用一些工具来监控性能以及 CPU、内存和 I/O 的饱和度。制作趋势线，以便在到达之前知道下一个瓶颈在哪里。
测试。 创建模拟数据，以便您今天在测试服务器上拥有 1000 万行。 对您的应用程序中的查询进行基准测试，看看它们作为数据量增加。您可能会对首先发生故障的情况感到惊讶，或者它可能完全按照预期进行。关键是你可以找出。
维护。确保您的应用程序和基础架构支持一些停机时间，因为这始终是必要的。您可能必须对索引进行碎片整理和重建。您可能需要重构一些表结构。您可能必须升级服务器软件或应用补丁。要在不中断连续运行的情况下做到这一点，您需要在设计中内置一些冗余。
研究。为您正在使用的数据库品牌找到最好的期刊和博客，然后阅读它们（例如，http://www.mysqlperformanceblog.com，如果您使用 MySQL）。你可以问像你在这里问的那样好的问题，但也可以阅读其他人在问什么，以及他们被建议做些什么。你可以学习解决你甚至还没有解决的问题，以便当你有它们时，你就会有一些策略可以使用。
【讨论】：
不同的数据库需要以不同的方式进行调整。你用的是什么关系型数据库？
另外，您如何知道到目前为止所做的事情是否会导致较大数据集的性能不佳？您是否使用大量测试数据测试了当前的优化？
当您这样做时，性能有何变化？如果您能够调整数据库以便它使用现有数据执行，那么没有理由认为您的方法不适用于更大的数据集。
根据 RDBMS，下一种解决方案很简单：获得更大、更强大的硬件。更多 RAM、更多磁盘、更多 CPU。
【讨论】：
您的方法正确：
1) 正确的索引
2) DBMS 选项调整（内存缓存、缓冲区、内部线程控制等on)
3) 查询调优（尤其是记录慢速查询，然后调优/重写它们）
4) 要调优查询和索引，您可能需要研究您的查询执行计划
5) 强大的专用服务器
6) 考虑您的客户端应用程序发送到数据库的查询。它们总是必要的吗？您需要您要求的所有数据吗？是否可以缓存一些数据？
【讨论】：
1000 万条记录可能太小而无法进行分区。通常，只有当您的数据量比这大一个数量级或数量级时，分区才会有意义。
对具有 100,000 行的数据库进行索引调整可能会为您提供 1000 万行所需的 99%。注意系统中大型表的表扫描或索引范围扫描。在较小的桌子上它们很好，在某些情况下甚至是最佳的。
归档旧数据可能会有所帮助，但对于 1000 万行来说这可能有点过头了。
一种可能的优化是将报告转移到单独的服务器上。这将减轻服务器的负担 - 报告在操作系统上运行时通常非常反社会，因为架构往往没有针对它进行很好的优化。
您可以使用数据库复制来执行此操作或创建数据集市以进行报告。复制更容易实现，但报告的效率会降低，不会比生产系统上的效率高。构建星型数据集市的报告效率更高，但需要额外的开发工作。
【讨论】：