我们经常需要为自己的OLTP（事务/运营）数据库选择适合的RDBMS（关系型数据库管理系统）。虽然通过编写可移植的SQL可以暂时避免进行这样的选择，但迟早要做出这样的选择，至少需要进行这样的尝试（比如，意识到具体的选择不够明确，因此决定选择跨RDB MS的SQL）。
生产环境中选择RDBMS的标准是？
在发起“到底哪个RDBMS最好”的讨论圣战之前，也许需要首先明确一下对于24x7运行的生产级OLTP RDBMS，到底需要具备哪些必不可少的功能。
一、基于锁，或是基于MVCC
考虑到并发性，目前几乎所有RDBMS无外乎基于锁的（Lock-Based），或基于MVCC（多版本并发控制）的。从写负载更重的OLTP处理角度来说，我曾经见到过：
对于读写混合型负载（例如OLTP事务和报表），基于MVCC的RDBMS表现会比基于锁的略好一些。
如果使用高于Read Uncommitted的隔离级别，效果还会更好，最适合用于读取/报表用途。
另一方面，OLTP很少会遇到大量并发读取的情况，如果真的遇到这种情况，通常可通过副本
（Replica）执行此类读取，因此不会造成太严重的问题。
对于大部分情况下以写入为主的OLTP（没有太多报表需要创建），基于锁的RDBMS要比基于MVCC的表现略好一些。然而如果能让OLTP工作负载使用INSERT代替UPDATE，此时MVCC的效率更高。
另外，值得注意的是，如果使用了单一写入连接（Single-write-connection）数据库架构，基于锁和基于MVCC的RDBMS之间的逻辑差异将显得微乎其微（尽管性能略有差别，
但其他方面几乎相同，基于锁的RDBMS通常略微领先一些）。
二、ACID保障
对于OLTP数据库，我们需要为涉及多行和多表的事务提供ACID保障。
如上所述，对于OLTP数据库，我们需要为事务提供全面的ACID保障。更重要的是，需要保障涉及多行和多表的事务具备ACID特性。虽然这一规则也有例外，但这种例外情况实际上极为罕见。
这几乎已自动将MySQL+MyISAM用作OLTP数据库的可能性彻底排除在外。但是也要注意，MySQL+ISAM可能是少数应用（例如作为快递追踪系统或系统监视工具的后端）的好选择，但并不适合涉及某类与金钱有关信息的常规OLTP处理。
此外RDBMS提供的ACID保障差不多等同于意味着需要使用数据库日志，同时也意味着一旦RDBMS崩溃，随后需要通过数据库日志进行自动恢复（并自动前卷Rollforward）。
三、支持24×7运行
作为联机备份的备选方案，可使用异步主从复制（Replication）我们需要的另一系列功能主要与24×7不间断运行有关（例如游戏服务器，总得全天候运行对吧）。这些功能包括：
联机备份。无论做什么都肯定需要备份，24x7不间断运行更是少不了联机备份。
1、通常来说，联机备份意味着需要具备“日志前卷”能力。大部分时候是这样工作的：创建两个数据库，一个作为“主”，一个作为“从”；随后从“主”获取日志文件并发送给“从”，然后在从数据库上进行“前卷"。
此外，有些数据库可以对处于“日志前卷”状态下的“从”数据库执行只读请求（实际上等同于创建了一个只读从副本）。然而其他一些RDBMS不能处理这样的请求（例如需要首先完成“日志前卷”操作才能让从RDBMS能够接受查询操作）。
2、作为联机备份的备选方案，也可以通过异步主从复制获得近乎完全同步的备份副本（这种做法对MySQL+InnoDB是一种尤为有趣的选项）。
需要注意，这样的副本也许可以或无法支持联机备份+前卷那样的“时点”恢复（具体情况请参阅文档）。虽然只在从一些非常糟糕的情况下恢复时需要“时点”恢复（实际生产环境中我从未遇到需要这种恢复的情况），不过真遇到这种糟糕的情况至少也能助我们一臂之力
3、“即时”的ADD COLUMN语句。我们可能需要对生产环境的数据库进行扩展，这一点是确定无疑的。大部分时候这是通过ALTER TABLE.…ADD COLUMN语句实现的。面对AD DCOLUMN语句，很多RDBMS会简单地将整个表重写为新格式的行。如果表包含10亿行，这一过程可能需要数小时？（在进行复制的过程中，整个表将完全无法访问，导致数据库在数小时内无法使用？）。让ADD COLUMN能够近乎即时（考虑到表的大小，可能需要几毫秒的时间）执行完成并不需要什么艰深的技术，有些RDBMS也确实能做到这一点，但是也不能忽视，这并不是一种普遍特性。
预算不足时的备选方案是实现无锁ADD COLUMN（以及常规的ALTER TABLE），方法如下：
用新的结构创建“影子”表
通过触发器将对当前表的所有改动写入影子表
将数据从当前表复制到影子表（一定要忽略已存在的行，因为触发器已经在其中写入内容了）用影子表取代当前表
这种“廉价”的ADDCOLUMN方法相当繁琐（全过程会对性能产生极大影响），但如果没有其他更好的方法，这种做法至少可以起到一定的效果。
“即时”ALTER COLUMN（字段拓宽，Widening field）也是个很好的功能，但因为字段拓宽可通过ADD COLUMN模拟，因此显得并不是太重要。
4、联机表优化。这个功能需要介绍一下。由于RDBMS会不断修改表内容，表的性能会逐渐退化（实际上取决于所用存储引擎，从“行溢出（Overflow row）"到“死行（Deadr ow）"，我们会遇到各种不希望出现的情况）。为此有必要进行一定的优化（例如InnoDB的OPTIMIZE TABLE，DB/2的REORG TABLE，Postgres的VACUUM等），并且我们会需要联机完成这些操作（无需让整个数据库彻底停摆，因为对包含数百万行内容的表进行优化通常需要花很长时间）。
大部分时候，此类优化需要创建“影子副本”（由数据库自行创建，这总好过需要我们手工创建），这也意味着需要额外的存储空间。不过至少有一个RDBMS提供了“原地”表优化功能。
5、容器的重新平衡。虽然不像上文列出的其他问题那么重要，但我始终认为“容器的重新平衡”也是RDBMS需要考虑的一个重要问题。
简单来说，这个问题主要出现在添加存储数据的新硬盘（这种情况时有发生），以及通过将数据分散在所有硬盘上实现提速时。此时可通过下列两种方法之一实现：
（a）使用RAID-10（这样就无需考虑数据库存储数据的方式了）
（b）通过多个RAID-1磁盘使用数据库容器（因为数据库本质上采用了类似RAID-0的工作原理）。
只要无需添加新硬盘（实际上通常在添加时，为了实现冗余往往会成对增加硬盘），所有系统基本上是均等的，然而在添加了一对新硬盘后，我们需要对硬盘进行“重新平衡”，借此实现负载的重新平衡，这一“重新平衡”的工作分别是由RAID或敖据库进行的。RAID级别的重新平衡对服务器性能的影响远大于数据库级别的重新平衡（尤其是有些情况下系统甚至完全无力承担RAID级别重新平衡过程中产生的负荷）。
原文地址：http://www.360doc.com/content/17/0215/16/1044878_629223899.shtml