我们都知道数据库的性能调整相当重要，但难度也较大。数据库管理员只有认真分析数据库运行过程当中出现的各种性能问题，才能保证数据库高效稳定地运行。然而，数据库的性能调整是一个系统工程，涉及的方面很多，不能仅仅根据一个时间点的情况就断定数据库运行性能的好与坏。数据库管理员需要经过反反复复的过程才能进行有效地调整。这些都需要在大量的实践工作中不断地积累经验，从而更好地进行数据库的调优。然而调整也需要确定方向，今天我们就来讨论一下你最需要知道的五大数据库性能指标。
关键业务流程
在我们的印象中，应用的关键业务能够提供真正的用户行为洞察——他们捕捉实时性能数据，展现真实用户在交互时的用户体验。衡量一个关键业务的性能包括捕捉交易的整体响应时间以及测量其不同层面的响应时间。这些时间都可以满足你业务需要的基准做比较。
如果你只想测量应用的某个方面，关键业务流程是最佳选择。虽然容器指标可以提供丰富的信息，可以帮助你确定何时自动缩放您的环境，但业务流程交易还是决定着你的应用性能最终效果。不管你作为什么规模公司的程序“猿”，都应该首先关心你的用户是否可以完成他们的关键业务流程。
一旦你定义了整个关键业务，性能好坏就是衡量整个应用生态系统的最好标准。我们需要设定低于平均关键业务响应时间的交易为异常行为，这样就能更好的观察应用的性能了，如下图所示。
那么问题来了，怎么设定关键业务的标准呢？
这里提供一个简单的方法供大家参考：假设关键业务在周三13：00~14:00是一个常见的高峰，那么选择这个时段平均响应时间作为标准，等到下周三的同一个时段，再将这周的这个时段的所有关键业务平均响应时间与前一周相比得到一个平均值，如此循环。通过这个机制，应用可以随时间而发展，而原始的关键业务数据也变得更有意义。关键业务的监测是用户体验中最具反思性的测量方法，因此它们是能捕捉到的最重要的指标之一。
查询的性能
这里可能要用一句比较绕口的话开场：查询的性能低下表现最为明显的地方就是查询本身。这可能是每一个程序员都会遇到的问题，它会导致SQL查询缓慢和数据返回时间过长。那么我们要怎么解决它呢？下面的这些问题是需要注意的：
1、选用了更多的数据：查询返回的列太多的话会导致在选择行和检索数据时造成缓慢。最好的解决办法是列出所需的列，而不是用SELECT*。此外，在结果中列出所需的列，减少数据传输，也有利于性能的提升。
2、只通过索引访问数据：有些时候，我们只是访问表中的几个字段，并且字段内容较少，我们可以为这几个字段单独建立一个组合索引，这样就可以直接只通过访问索引得到数据，一般索引占用的磁盘空间比表小很多，所以这种方式可以大大减少磁盘IO开销。
3、优化SQL执行计划：SQL执行计划是关系型数据库最核心的技术之一，它表示SQL执行时的数据访问算法。当业务需求越来越复杂，表数据量越来越大，SQL也需要支持非常复杂的业务逻辑，但SQL的性能还需要提高，因此，优秀的关系型数据库除了需要支持复杂的SQL语法及更多函数外，还需要有一套优秀的算法库来提高SQL性能。
多用户与查询之间的冲突
数据库一般都允许多用户的存在，多个用户同时活动必然会导致冲突，然而正常工作中这种情况又无法避免，我们如何解决这个问题？
1、页/行锁定：当一个用户试图读取另一个用户正在修改的数据，或修改另一个用户正在读取的数据时，又或者尝试修改另一个事务正在尝试修改的数据时，就会出现并发问题。这时候资源就会被锁定。
可以锁定的资源在粒度（granularity）上差异很大。从细（行）到粗（数据库）。细粒度锁允许更大的数据库并发，因为用户能对某些未锁定的行执行查询。然而，每个由SQL Server产生的锁都需要内存，所以数以千计独立的行级别的锁也会影响SQL Server的性能。粗粒度的锁降低了并发性，同时消耗的资源也较少。
2、死锁：死锁是数据库性能的重量级杀手之一，然而死锁却是不同事务之间抢占数据资源造成的。死锁耗时耗资源，然而在大型数据库中，高并发带来的死锁是不可避免的，所以我们只能让其变的更少。
①按照同一顺序访问数据库资源
②保持事务的简短，尽量不要让一个事务处理过于复杂的读写操作。事务过于复杂，占用资源会增多，处理时间增长，容易与其它事务冲突，提升死锁概率。
③尽量不要在事务中要求用户响应，比如修改新增数据之后再完成整个事务的提交，这样延长事务占用资源的时间，也会提升死锁概率。
④尽量减少数据库的并发量。
⑤尽可能使用分区表，分区视图，把数据放置在不同的磁盘和文件组中，分散访问保存在不同分区的数据，减少因为表中放置锁而造成的其它事务长时间等待。
⑥避免占用时间很长并且关系表复杂的数据操作。
⑦使用较低的隔离级别，使用较低的隔离级别比使用较高的隔离级别持有共享锁的时间更短。这样就减少了锁争用。
3、为在线用户提供足够的资源：读取大量的数据或生产复杂的分析报告时通常都是在批量操作。这些操作是资源密集型，可能会影响在线用户的性能。想要解决这个问题需要确保在线用户是在低负载下进行操作的，如在夜间；或使用单独的数据库的来处理和分析报告。
硬件
然而并不是所有的数据库性能问题都是来自数据库本身，我们日常工作中最常见的另一个情景就是数据库的硬件有若干问题，这里我们简单的介绍一下可能会出现的情况，毕竟市面上有已经有很多工具可以监测这些问题了。
1、没有足够的CPU或CPU速度太慢：更多的CPU可以分担服务器的负载，从而提高性能。
2、慢的磁盘没有足够的IOPS：磁盘性能可以描述为每秒输入/输出操作（IOPS），它表示每秒磁盘的吞吐量。
3、配置不正确的磁盘：数据库需要效果明显的磁盘访问，配置不正确的磁盘会造成相当大的性能影响。
4、没有足够的内存：受限或不好的物理内存影响数据库性能，可用的内存越多，性能越好。
开通听云Sys即可看到服务器的各项数据指标：https://account.tingyun.com/cas/login?service=https%3A%2F%2Fsaas.tingyun.com%2Fj_acegi_cas_security_check%3FloginView%3DcasLoginTingyun
NoSQL数据库
NoSQL发展到今天，已经有了很大的吸引力，因为它处理大规模数据和高并发的能力非常显著。然而，NoSQL并不一定适合所有情况，为什么呢？我们可以找到四个原因：
1、复杂的数据库：NoSQL的支持者们往往都在称赞它的简洁，有效，速度，然而所有这些特性都表现在数据库任务很简单的时候。当数据库变得更复杂，NoSQL开始崩溃。同时相比于NoSQL的群魔乱舞， SQL已经成熟，有行业标准接口，所以每一个NoSQL都是独一无二的存在。
2、灵活的Schema设计：在以前的数据库模型中，程序员必须考虑他们所需要的列，以照顾所有的潜在的可能性和每行中的数据项。当使用NoSQL时，各种各样的字符串都能实现，这种灵活性使得程序员能够快速地提高应用的速度。然而，当有几个小组在同一个项目上工作，或者当新的开发团队接手某个项目时，这可能是个问题。
3、价格：NoSQL数据库相比关系型数据库通常更多的是资源密集型。它们需要更多的内存和内存分配。出于这个原因，大多数主机托管公司不提供NoSQL，你必须使用VPS或专用服务器。另一方面，随着数据库的需求增加，硬件也必须扩展，一个拥有巨大容量的单台服务器要比一个更小的服务器昂贵得多。
4、监控困难：相对于已经成熟的SQL，NoSQL现在的监控可以说是比较困难的，国内也只有听云一家公司能够支持主流的Memcached, MongoDB, Redis等非关系型数据库服务，这条路仍然很长。
开通听云Server立即查看NoSQL的数据指标：https://saas.tingyun.com/product/productList?ptype=2
（新闻稿 2016-01-11）
