随着数据量的增加,确保数据库性能

监测。 使用一些工具来监控性能,以及CPU、内存和I/O的饱和。绘制趋势线,以便在到达那里之前知道下一个瓶颈在哪里。

创建模拟数据,以便在测试服务器上有1000万行 对应用程序中的查询进行基准测试,并查看它们在数据量增加时的性能。你可能会惊讶于什么首先发生了故障,或者它可能会完全按照预期进行。关键是你可以 找出 .

维修 确保您的应用程序和基础架构支持一定的停机时间,因为这总是必要的。您可能需要对索引进行碎片整理和重建。您可能需要重构一些表结构。您可能必须升级服务器软件或应用修补程序。要在不中断连续操作的情况下执行此操作,您需要在设计中内置一些冗余。

研究 找到你正在使用的数据库品牌的最佳期刊和博客,并阅读它们(例如。 http://www.mysqlperformanceblog.com 如果您使用MySQL)。你可以问一些很好的问题,比如你在这里问的问题,但也可以阅读其他人在问什么,以及他们被建议做什么。你可以学习解决你还没有解决的问题,这样 有了它们,你就有了一些策略。

另外,您如何知道到目前为止所做的工作是否会导致较大数据集的性能不佳?您是否使用大量测试数据测试了当前的优化?

根据RDBMS的不同,下一种解决方案很简单:让硬件更大、更强大。更多的RAM,更多的磁盘,更多的CPU。

你走在正确的道路上:

2) DBMS选项优化(内存缓存、缓冲区、内部线程控制等)
查询优化(特别是记录慢速查询,然后对其进行优化/重写)
4) 要优化查询和索引,您可能需要研究查询执行计划
5)
考虑一下客户端应用程序向数据库发送的查询。它们总是必要的吗?你需要你要求的所有数据吗?可以缓存一些数据吗?

对于一个有100000行的数据库,索引优化可能会使您获得1000万行所需的99%。留意系统中大型表上的表扫描或索引范围扫描。在较小的桌子上,它们很好,在某些情况下甚至是最优的。

一种可能的优化方法是将报告转移到单独的服务器上。这将减轻服务器的负担-当在操作系统上运行时,报告通常是非常反社会的,因为模式往往没有得到很好的优化。

您可以使用数据库复制来执行此操作,也可以创建用于报告的数据集市。复制更容易实现,但报告的效率会降低,不会比生产系统上的报告更高。构建星型模式数据集市将更有效地进行报告,但需要额外的开发工作。