1.2　优化的基本思路

1.2.1　数据库全面健康检查

（1）获取直接用户的使用反馈，确定性能目标和范围。获取性能表现好与坏时的操作系统、数据库、应用统计信息。对数据库做一次全面健康检查。

（2）根据收集到的信息，以及对应用特性的了解，构建性能概念模型，明确性能瓶颈所在，以及导致性能降低的根本原因。首先应该排除由操作系统、硬件资源造成的瓶颈。其次针对数据库系统性能进行分析。必要时还需要检查应用日志，因为系统性能问题也有可能是由应用非SQL部分造成的瓶颈。

（3）提出一系列有针对性的优化措施，并根据它们对性能改善的重要程度排序，然后逐一加以实施。不要一次执行所有的优化措施，必须逐条尝试、逐步对比。

（4）通过获取直接用户的反馈，验证调整是否已经产生了预期的效果。若未产生预期的效果，则需要重新提炼性能概念模型，直到对应用特性的了解能更加准确。

（5）重复上述步骤，直到性能达到目标或由于客观约束无法进一步优化。随着业务的增长，将会有越来越多的业务系统部署到生产环境中，这对数据库的性能优化来说是严峻的挑战。为了解决这些问题，需要定期为数据库做优化工作。优化工作涉及方方面面，包括CPU的使用情况、应用程序的合理性等。

1.2.2　优化阶段设计

只要有可能，就应该从项目第一阶段开始优化，完善设计能够避免很多优化问题。例如，虽然将表完全规格化通常是减少冗余的最好方法，但是这种方法会导致大量的表连接。取消规格化可以大大提高应用程序的性能。

大型数据库一般都支持存储过程，合理地利用存储过程也可以提高系统性能。假如你有一个业务需要将A表的数据加工处理后更新到B表中，但是又不可能通过一条SQL语句来完成，这时你需要以下3个步骤进行操作。

步骤一：将A表数据全部取出到客户端。

步骤二：计算出要更新的数据。

步骤三：将计算结果更新到B表中。

如果采用存储过程你可以将整个业务逻辑封装在存储过程里，然后在客户端直接调用存储过程进行处理，那么这样可以减少网络交互的成本。

当然，存储过程也并不是完美的，存储过程存在以下缺点。

（1）不可移植性，每种数据库的内部编程语法都不尽相同，当你的系统需要兼容多种数据库时最好不要使用存储过程。

（2）学习成本高，DBA一般都擅长写存储过程，但并不是每个程序员都能写好存储过程，除非其团队中有较多的开发人员都擅长写好存储过程，否则在后期系统维护时会产生问题。

（3）为了提高性能，数据库会把存储过程代码编译成中间运行代码（类似于Java的class文件），所以存储过程代码更像是一种静态语言。当存储过程引用的对象（表、视图等）结构改变后，存储过程需要重新编译才能生效，在7×24小时高并发应用场景中，一般都是在线变更结构的，因此在变更结构的同时要编译存储过程，这可能会导致数据库瞬间压力上升，从而引起故障。

1.2.3　数据库配置

即使在SSD固态硬盘上，对性能进行监视也非常重要。应该规划好数据库配置，使数据库恢复时间最短、数据访问最快。

1.2.4　添加新的应用程序

向现有系统中添加新的应用程序时，工作量会发生改变，而当工作量发生任何主要变化时，都应该同时进行性能监视。

数据库访问框架一般都提供了批量提交的接口，Java数据库连接（Java Database Connectivity，JDBC）支持批量的提交处理方法，当用户向一个表中一次性插入1000万条数据时，如果采用普通的处理方式，那么和服务器的交互次数为1000万次，按每秒可以向数据库服务器提交1万次估算，要完成所有工作需要1000秒。如果采用批量提交模式，一次提交1000条数据，那么和服务器的交互次数为1万次，交互次数将大大减少。采用批量操作一般不会减少很多数据库服务器的物理I/O操作，但是会大大减少客户端与服务端的交互次数，从而减少由多次交互引起的网络延时开销，同时也会降低数据库的CPU开销。

1.2.5　运行过程的优化

建议对生产数据库的运行过程进行优化，它可以查找瓶颈，并加以解决。首先使用工具找出性能问题，通过查找数据，可以对造成瓶颈的原因进行假设，其次根据假设开发并实施解决方案，最后对数据库进行测试负载，以确定性能问题是否能够得到解决。

通过优化业务逻辑来提高数据库性能是比较困难的，这需要程序员对所访问的数据及业务流程非常清楚。

例如，某移动公司推出优惠套餐，活动对象为VIP会员且2020年1月、2月、3月平均话费在200元以上的客户，那么检测逻辑如下。

对业务逻辑做以下修改。

通过这样的方式可以减少一些判断vip_flag的开销，平均话费在200元以下的用户就不需要再检测其是否为VIP会员了。如果程序员在分析业务后发现，VIP会员比例为1%，平均话费在200元以上的用户比例为90%，那么可对业务逻辑做如下修改。

这样就只需要检测用户比例为1%的VIP会员的平均话费，大大减少了数据库的交互次数。

以上只是一个简单的示例，实际的业务要复杂得多，因此一般高级程序员更容易做出优化的逻辑，但是也需要具有成本优化的意识。

1.2.6　生产环境中优化的特殊问题

生产系统的优化方法是在用户遇到问题之前解决问题，具体操作过程如下。

• 使用达梦性能监控工具、AWR、DEM等工具来定位瓶颈或潜在的瓶颈。

• 瓶颈通常以等待事件的形式出现，明确等待事件产生的原因。

• 明确等待事件产生的原因后对其予以纠正，这可以调整数据库系统中共享内存的大小。

• 重新运行应用程序，然后使用达梦性能监控工具、AWR、DEM等工具，检查所做的更改是否对生产系统产生了积极的效果。

• 若未达到目标，则重复这个过程。

按照以上过程能够对生产系统进行优化，但在生产系统中重复使用相同的优化方法是浪费时间的。当需要全面检查生产系统和开发系统时，使用这两种系统才更加有利。