数据库性能优化目标

从数据库性能优化的场景来区分，可以将性能优化分为如下三种形式：
从来没达到过性能要求的数据库优化。该类故障一般出现在压力测试或者业务系统刚上线时，可能需要通过修改应用架构，大规模优化SQL语句来进行改进，此类优化难度最大，耗时也最长。
量变引起质变的数据库优化。该类故障通常是由数据库并发加大，数据量增多引起的，优化难度一般，但代价可能较高。在国内，很多客户都是通过增加硬件投入来解决该类性能问题的。
突发性的数据库性能故障优化。该类故障优化的难度最低，但时间紧迫性更强，需要DBA能够快速解决问题。
从数据库性能优化的时间点来分，又分以下2点：
事前优化，指的是业务系统上线前的优化。在事前优化过程中，系统设计、开发、产品优化、平台优化的全过程都很重要。实践经验表明，事前优化对于系统的平稳运行有着根本性的影响，而且优化代价也最低。
事后优化，指的是业务系统上线后的优化。由于事后优化受到宕机时间、代码版本控制、代码内核不容易更改等因素影响，所以事后优化往往只能缓减系统性能下降的症状，治标不治本。系统上线之后，如果爆发出大规模的性能问题，那通常都会是灾难性的，任何容灾在这时都起不了作用。
数据库性能优化并没有统一的标准步骤，“不管黑猫白猫，捉到老鼠就是好猫”，这句话在性能优化领域也同样适用。一个性能优化项目的目标如下：
增大数据库吞吐量。如通过数据库优化增加每秒执行的事务数。
高效利用服务器硬件资源。如开启并行充分利用CPU资源和存储I/O资源加快执行速度。
提示：千万别将数据库的优化全部寄托于系统的参数优化和硬件升级上。
数据库性能优化的成果也可以用两种方式表示。一种是技术成果，通常用反映数据库性能的统计值来直观地表示数据库性能的状态。另外一种是用户体验，通常以用户的使用感觉来表示数据库性能的状态。及时听取用户的反馈比追求性能指标更为重要。在性能优化时，只要达到了用户的要求就能终止优化，而不是反复优化。需要注意的是，由于要考虑优化成本收益比，任何优化都只是针对目前系统状态的一种资源重组，都不可能是绝对彻底的优化。很多DBA在性能优化时经常过分听取用户的使用反馈或者患有“数据库优化强迫综合征”。即喜欢做无止境的优化工作。殊不知这不仅会使优化成本越来越高，而且，任何一个优化动作都可能导致数据库的不稳定。