1数据库基础
1.1数据库定义
1）数据库(Database)是按照数据结构来组织、存储和管理数据的建立在计算机存储设备上的仓库。简单来说是本身可视为电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行新增、截取、更新、删除等操作。
2）数据库是长期储存在计算机内、有组织的、可共享的数据集合。数据库中的数据指的是以一定的数据模型组织、描述和储存在一起、具有尽可能小的冗余度、较高的数据独立性和易扩展性的特点并可在一定范围内为多个用户共享。
这种数据集合具有如下特点：尽可能不重复，以最优方式为某个特定组织的多种应用服务，其数据结构独立于使用它的应用程序，对数据的增、删、改、查由统一软件进行管理和控制。从发展的历史看，数据库是数据管理的高级阶段，它是由文件管理系统发展起来的。
1.2数据库系统VS文件系统
1）共同点：
同属于系统软件或底层软件；都是用来存储和访问数据的；都有着悠久的研究开发历史；都有成熟的标准或规范。这既有利于开发可移植的程序，又不利于开发创新的系统，特别是分布式系统。
实现技术上也有很多的共同点：大都采用C/C++这样更底层的语言；需要保证数据的一致性，特别的，不同程度的支持事务；都有Block或Page或Allocation unit或Extent这样的概念；都用到Buffer cache、LRU、Group commit之类的概念和算法；都要针对各种负载做IO优化
2）不同点：
数据库对事务的支持要强很多，文件系统可以只保证元数据的一致性；数据库有不同级别的一致性，以隔离级别的形式体现出来；数据库可以有REDO和UNDO日志，文件系统一般只用REDO；数据库的事务可以很长，文件系统的事务很短；数据库的事务事先无法确定，是用户输入的，文件系统的事务可以事先确定，种类明确；数据库是用户态实现的，文件系统一般是内核态实现的。因此，前者更容易做到跨OS平台；数据库的访问接口通常是非过程化的SQL语言，文件系统的则是API。二者对应的主流标准分别是SQL和POSIX；数据库对死锁可以做检测，文件系统则需要避免死锁。
文件系统VS数据库
3）联系点：
数据库系统经常依赖于文件系统作为其最底层的存储，也可能会实现一些文件系统的功能；文件系统可以为数据库这种特殊的应用做专门的优化；文件系统可以被当做简单的数据库使用（例如VSAM），数据库也可以暴露出NFS（例如Oracle）；文件系统可能会用到一些简单的数据库功能（例如把符号链接当KV，实现简单的DB功能，或直接用一个小型的DBMS）
1.3数据库的体系结构
数据库系统各个部分以及他们之间的联系见图1。
图1DBMS体系结构
1.3.1集中式数据库系统
[if !supportLists]1）[endif]集中式系统：运行在一台机器上，数据集中存储在一台计算机中，并且不与其他计算机系统交互的数据库系统。
[if !supportLists]2）[endif]单用户系统：个人使用的桌面系统，单CPU，1至2个硬盘，OS可以只支持单用户，数据库系统不支持并发控制，故障恢复能力没有或非常有限，用户接口类似QBE。
3）多用户系统
服务大量用户，用户通过终端与之相连，多个磁盘，多个主存储器，多个CPU，多用户OS，具有并发控制、故障恢复等能力
1.3.2 C/S数据库系统
1.3.2.1简介
连接到集中式系统的终端被PC代替；以前由集中式系统执行的诸如用户界面功能由PC来处理；集中式系统变成服务器系统的作用，来响应客户系统产生的请求，见图2C/S数据库系统。优点：
图2C/S数据库系统
具有如下优点：有利于充分利用网络中的计算资源；减少网络上的传输量；高性能/价格比；可扩展性；友好的用户接口；易维护。
1.3.2.2服务器分类
[if !supportLists]1）[endif]事务服务器：又称查询服务器或SQL服务器，广泛用于关系数据库系统；客户向服务器发送请求，事务在服务器端执行，结果返回给客户端；可以以SQL表达请求，也可以通过应用程序接口，使用远程过程调用(RPC)机制来表达请求；ODBC（Open Database Connectivity）使用ODBC接口的任何客户程序都可以与提供ODBC接口的任何服务器连接。
2）数据服务器：用于局域网中；客户与服务器之间具有高速连接；客户机与服务器的处理能力相当，并且其执行的任务主要以计算为主；数据传送到客户机器，在客户机上进行所有处理，然后再把数据传回到服务器；多用于面向对象数据库系统。
1.3.3并行数据库系统
1.3.3.1简介
由通过高速互连网络连接在一起的多个CPU、存储器和磁盘组成；查询大数据量；处理大数量的事务；粗粒度并行机由几个能力强大的处理器组成；细粒度并行机由数千个小处理器组成。
1.3.3.2应用需求和目的
需求：查询非常大的数据库（1012字节以上）;处理很大数量的事务（每秒数千个事务）
目的：保证即使在数据库的规模和事务的数量都大大增长时，数据库系统仍能以可接受的速度运行。
1.3.4分布式数据库系统
1.3.4.1背景及定义
1）背景
分布式数据库系统的应用背景是数据库系统+计算机网络，如图3分布式系统图例为银行系统的一个简单示例，数据库系统分布与不同的地区，通过互联网实现数据的写入和读取操作。
图3分布式系统图例
[if !supportLists]1）[endif]描述定义
D-DBS是一个数据集合，这些数据在逻辑上属于同一个系统，但在物理上分布在计算机网络的不同结点上。
[if !supportLists]1）[endif]精确定义
D-DBS是一个数据集合，这些数据，分布在计算机网络的不同计算机上，网络中每个结点具有独立处理的能力，可以执行局部应用，同时每个结点也能通过网络通讯支持全局应用。分布式数据库强调场地自治性（局部应用）以及自治场地之间的协作性（全局应用）
1.3.4.2体系结构
1）G-外模式：全局应用的用户视图；
2）G-概念模式：定义D-DBS中数据的整体逻辑结构，数据如同没有分布一样；
3）分片模式：每一个关系可以分为若干互不相交的部分，每一部分称为一个片段；
4）分布模式：定义片段的存放地点。
图4分布式体系结构
1.4数据挖掘和信息检索
1.4.1基本定义
[if !supportLists]1）[endif]信息检索
信息检索（Information
Retrieval）是用户进行信息查询和获取的主要方式，是查找信息的方法和手段。狭义的信息检索仅指信息查询（Information Search）。即用户根据需要，采用一定的方法，借助检索工具，从信息集合中找出所需要信息的查找过程。广义的信息检索是信息按一定的方式进行加工、整理、组织并存储起来，再根据信息用户特定的需要将相关信息准确的查找出来的过程。又称信息的存储于检索。一般情况下，信息检索指的就是广义的信息检索。
[if !supportLists]2）[endif]数据挖掘
数据挖掘一般是指从大量的数据中通过算法搜索隐藏于其中信息的过程。数据挖掘通常与计算机科学有关，并通过统计、在线分析处理、情报检索、机器学习、专家系统（依靠过去的经验法则）和模式识别等诸多方法来实现上述目标。
[if !supportLists]1.4.2[endif]应用分类
[if !supportLists]1）[endif]信息检索：
个人信息检索：个人相关信息的组织、整理、搜素等。桌面搜索、个人信息管理、个人数字记忆；企业级信息检索：在企业内容文档的组织、管理、搜索等。企业级信息检索是内容管理的重要组成部分；Web信息检索：在超大规模数据集上的检索；移动搜索、产品搜索、专利搜索、广告推荐、社会网络分析、消费行为分析、网络评论分析、SEO营销。
[if !supportLists]2）[endif]数据挖掘：
大小公司对数据挖掘的需求有50多个方面：数据统计分析；预测预警模型；数据信息阐释；数据采集评估；数据加工仓库；品类数据分析；销售数据分析；网络数据分析；流量数据分析等等。
2数据库的分类
2.1商用数据库VS开源数据库
DB-Engines中目前有331个不同的数据库管理系统，其中开源数据库有165个，商业数据库有166个，双方可谓旗鼓相当见图5开源VS商用走势图。
图5开源VS商用走势图
2.2数据库切分
2.2.1切分概述
2.2.1.1 OLTP和OLAP
联机事务处理（OLTP）也称为面向交易的处理系统，其基本特征是原始数据可以立即传送到计算机中心进行处理，并在很短的时间内给出处理结果。
联机分析处理（OLAP）是指通过多维的方式对数据进行分析、查询和报表，可以同数据挖掘工具、统计分析工具配合使用，增强决策分析功能。
对于二者的区别见表1。
表1OLAP和OLTP对比
OLTPOLAP
系统功能日常交易处理统计、分析、报表
DB设计面向实时交易类应用面向统计分析类应用
数据处理当前的、最新的细节、二维的分立的历史的、聚集的、多维的、集成的、统一的
实时性实时读写要求高实时读写要求低
事务强一致性弱事务
分析要求低、简单高、复杂
2.2.1.2关系型数据库和非关系型数据库（NoSQL）
针对上面两类系统有多种技术实现方案，存储部分的数据库主要分为两大类：关系型数据库和NoSQL。
关系型数据库，是建立在关系模型基础上的数据库，其借助于集合代数等数学概念和方法来处理数据库中的数据。主流的Oracle、DB2、MS SQL Server和mysql都属于这类传统的数据库。
NoSQL数据库，全称为Not Only SQL，意思就是适用关系型数据库的时候使用关系型数据库，不适用的时候也没必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储。主要为临时性键值存储、永久性键值、面向文档的数据库、面向列的数据库。
二者各自特点见表2关系数据库与非关系数据库对比。
表2关系数据库与非关系数据库对比
关系型数据库NoSQL
特点数据关系模型基于关系模型，结构化存储，完整约束；基于二维表及其之间的联系，需要连接、并、交、差、除等数据操作；采用结构化的查询语言做数据读写；操作需要数据的一致性，需要事务甚至是强一致性非结构化的存储
基于多维关系模型
具有特有的使用场景
优点保持数据的一致性（事务处理）
可以进行join等复杂查询
通用化，技术成熟
高并发，大数据下读写能力较强；基本支持分布式，易于扩展，可伸缩；简单，弱结构化
缺点数据读写必须经过SQL解析、大量数据，高并发下读写性能不足；对数据做读写，或修改数据结构需要加锁，影响并发操作；无法适应非结构化存储；扩展困难；昂贵、复杂。Join等复杂操作能力较弱；事务支持较弱；通用性差；无完整约束复杂业务场景支持较差。
2.2.1.3何为数据切分
简单来说，就是指通过某种特定条件，将我们存放在同一个数据库中的数据分散存放到多个数据库中，以达到分散单台设备负载的效果。
数据的切分根据其切分规则的类型，可以分为两种切分模式。一种是按照不同的表来切分到不同的数据库上，这种切分可以称之为数据的垂直切分；另外一种则是根据数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库上，这种切分称之为水平切分。
关于数据库的垂直切分和水平切分将在第3.1.5和3.16节进行详细介绍。
2.3数据库分类
数据库通常分为层次式数据库、网络式数据库和关系式数据库三种。而不同的数据库是按不同的数据结构来联系和组织的。而在当今的互联网中，最常见的数据库模型主要是两种，即关系型数据库和非关系型数据库，见图6数据库简单划分。
图6数据库简单划分
数据库按其数据模型详细分类、使用情况和排名情况见图7数据库分类。
图7数据库分类
2.3.1关系型数据库(Relational DBMS)
关系数据库，是建立在关系模型基础上的数据库，借助于集合代数等数学概念和方法来处理数据库中的数据。简单来说，关系模型指的就是二维表格模型，而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。
关系数据库分为两类：一类是桌面数据库，例如Access、FoxPro和dBase等；另一类是客户/服务器数据库，例如SQL
Server、Oracle和Sybase等。一般而言，桌面数据库用于小型的、单机的应用程序，它不需要网络和服务器，实现起来比较方便，但它只提供数据的存取功能。客户/服务器数据库主要适用于大型的、多用户的数据库管理系统，应用程序包括两部分：一部分驻留在客户机上，用于向用户显示信息及实现与用户的交互；另一部分驻留在服务器中，主要用来实现对数据库的操作和对数据的计算处理。
表3关系型数据库是DB-Engines提供的关系型数据库的排名情况，表中按数字为先后进行排序，并对相应数据库做了最简要的介绍。由表可知：现在主流的数据库主要以Oracle、mysql和sql Server为主，但只有mysql开源（获取排名时间2017年6月）。
表3关系型数据库
排名简述
1、OracleOracle Database，又名Oracle RDBMS，或简称Oracle。是甲骨文公司的一款关系数据库管理系统。
2、MySqlMySQL是一种开放源代码的关系型数据库管理系统（RDBMS）
3、Microsoft SQL ServerSQL Server是Microsoft公司推出的关系型数据库管理系统
4、PostgreSQLPostgreSQL是一个自由的对象-关系数据库服务器(数据库管理系统)
5、DB2IBM DB2是美国IBM公司开发的一套关系型数据库管理系统
6、Microsoft AccessMicrosoft Office Access是微软把数据库引擎的图形用户界面和软件开发工具结合在一起的一个数据库管理系统。
7、SQLiteSQLite，是一款轻型的数据库，是遵守ACID的关系型数据库管理系统
8、TeradataTeradata天睿公司数据库，Teradata数据仓库配备性能最高、最可靠的大规模并行处理(MPP)平台，能够高速处理海量数据。（大数据，价格不菲）
9、SAP Adaptive ServerAdaptive Server IQ是sybase公司(现已被SAP收购)一个数据库产品
10、FileMakerFileMaker是一个关于数据库的应用软件，它因易于使用且有不要求使用另外的第三方应用程序就能动态地为网页服务的能力而著称。
11、MariaDBMariaDB数据库管理系统是MySQL的一个分支，主要由开源社区在维护，采用GPL授权许可MariaDB的目的是完全兼容MySQL，包括API和命令行，使之能轻松成为MySQL的代替品。
12、Hivehive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供简单的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。
…省略
2.3.2文档存储数据库（Document stores）
2.3.2.1定义
文档数据库区别于传统的其它数据库，它是用来管理文档。在传统的数据库中，信息被分割成离散的数据段，而在文档数据库中，文档是处理信息的基本单位。文档可以很长、很复杂、可以无结构，与字处理文档类似。一个文档相当于关系数据库中的一条记录。
2.3.2.2与文件系统区别
首先，文件系统中的文件基本上对应于某个应用程序。当不同的应用程序所需要的数据有部分相同时，也必须建立各自的文件，而不能共享数据，而文档数据库可以共享相同的数据。因此，文件系统比文档数据库数据冗余度更大，更浪费存储空间，且更难于管理维护。其次，文件系统中的文件是为某一特定应用服务的，所以，要想对现有的数据再增加一些新的应用是很困难的，系统不容易扩充。数据和程序缺乏独立性。而文档数据库具有数据的物理独立性和逻辑独立性，数据和程序分离。
2.3.2.3与关系型数据库的区别
文档数据库也不同于关系数据库,关系数据库是高度结构化的,而Notes的文档数据库允许创建许多不同类型的非结构化的或任意格式的字段,与关系数据库的主要不同在于,它不提供对参数完整性和分布事务的支持,但和关系数据库也不是相互排斥的,它们之间可以相互交换数据,从而相互补充、扩展。
2.3.2.4常用的文档存储数据库
表4文档存储类数据库
1、MongoDBMongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。
可以存储比较复杂的数据类型；
最大的特点是他支持的查询语言非常强大。
2、Amazon DynamoDBAmazon DynamoDB是一项完全托管的NoSQL数据库服务，提供快速而可预测的性能，能够实现无缝扩展。
Amazon DynamoDB可自动将表的数据和流量分布到足够多的服务器中，以处理客户指定的请求容量和数据存储量，同时保持一致的性能和高效的访问。
3、CouchbaseCouchbase是一个具有高性能、可扩展性和可 用性强的数据库引擎。它可以让开发人员通过NoSQL的键值存储（二进制或者JSON）或者使用N1QL的形式对数据进行操作（N1QL是非常类似于SQL的一种语法操作JSON数据的方式）。
2.3.3键值存储（key-value stores）
数据按照键值对的形式进行组织、索引和存储。KV存储非常适合不涉及过多数据关系业务关系的业务数据，同时能有效减少读写磁盘的次数，比SQL数据库存储拥有更好的读写性能。
1、Redis（高性能的key-value数据库）Redis与其他key - value缓存产品有以下三个特点：
Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
Redis支持数据的备份，即master-slave模式的数据备份。
2、MemcachedMemcached是一个高性能的分布式内存对象缓存系统，用于动态Web应用以减轻数据库负载。
2.3.4图形数据库
图形数据库是NoSQL数据库的一种类型，它应用图形理论存储实体之间的关系信息。图形数据库是一种非关系型数据库，它应用图形理论存储实体之间的关系信息。最常见例子就是社会网络中人与人之间的关系。关系型数据库用于存储“关系型”数据的效果并不好，其查询复杂、缓慢、超出预期，而图形数据库的独特设计恰恰弥补了这个缺陷。
在一个图形数据库中，最主要的组成有两种，结点集和连接结点的关系（有的也称泡泡和箭头）。结点集就是图中一系列结点的集合，比较接近于关系数据库中所最常使用的表，而关系则是图形数据库所特有的组成。
表5图形数据库
1、Neo4jNeo4j是一个高性能的,NOSQL图形数据库，它将结构化数据存储在网络上而不是表中。它是一个嵌入式的、基于磁盘的、具备完全的事务特性的Java持久化引擎，但是它将结构化数据存储在网络(从数学角度叫做图)上而不是表中。
2、Microsoft Azure Cosmos DBAzure Cosmos DB是一个全球分布式数据库服务，使用它可以跨任意数量的地理区域，根据全面的SLA，灵活、独立地缩放吞吐量与存储。 使用Cosmos DB可通过一系列流行API和编程模型开发文档、键/值或图形数据库。
3、OrientDBOrientDB是兼具文档数据库的灵活性和图形数据库管理链接能力的可深层次扩展的文档-图形数据库管理系统。
4、TitanTitan是一个在服务器集群搭建的分布式的图形数据库，特别为存储和处理大规模图形而优化
2.3.5列存储（Wide column stores）
在SQL Server里，Page是数据存储的基本单位，而数据行是实际数据的存储单位，它们从Page Header之后就开始依次存储在Page上。这种按行在Page上存储记录的方式就是行存储。当数据是按单列而不是多行进行连续存储时，就是所谓的列存储。（列存储的数据库更适合（联机分析处理）OLAP；行存储的数据库更适合（联机事务处理过程）OLTP）。
表6列式存储
1、CassandraCassandra是一个来自Apache的分布式数据库，具有高度可扩展性，可用于管理大量的结构化数据。它提供了高可用性，没有单点故障。
2、HbaseHBase是一个分布式的、面向列的开源数据库，HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。
3、Microsoft Azure Cosmos DB上面简要介绍过。
4、AccumuloAccumulo是一个基于谷歌Big Table、采用键值的分布式数据存储。
2.4数据库选型
2.4.1五个要素
2.4.1.1开发要求
实现基于关系型数据库的应用可以选择传统的主流品牌，这些数据库产品有着很成熟的关系技术以及广泛的应用资源。但是,如果实现的是基于面向对象技术的应用、又或是数据结构更为复杂时，不妨考虑目前一些公司推出的所谓后关系数据库。它所代表的正好是关系数据库和面向对象技术的融合，以多维数据引擎作为核心，从根本上支持复杂的对象存储及主流的二维表，同时也已经配备了功能强大的应用服务引擎，可作对象逻辑操作的平台。它的出现已经为传统数据库领域带来了冲击，而在面向对象数据库方面更是广受欢迎。
2.4.1.2性能/成本
测量数据库性能最常见的方法是TPC基准。TPC定义了数据库方案、数据量以及SQL查询。它指出，在这一数据库版本、平台、操作系统版本，以及这一内存和磁盘技术/容量条件下，每项事务的成本是多少－其中的事务可以是TPC测试中定义的任何数据库操作。
理论上来讲，这类基准旨在提供不同产品间的比较值，而在现实中，方案定义可能无法准确反映您正在挑选的技术的使用的本质情况。其次，所有技术厂商发布的TPC基准都会超过以前发布的结果。这样，TPC基准更大程度上反映的是为解决问题而投入的内存和CPU量，而不是数据库性能的任何真实表现。
2.4.1.3数据库的运行和管理
数据库管理涉及以下问题：
表7数据库管理涉及的问题
操作任务备份、故障切换、灾难恢复等
整理系统分段、存档
访问控制定义、监控
性能保持系统在线和优化运行
数据库方案变更更改数据库结构、重新索引、数据库同步
2.4.1.4可升级性
随着对数据库应用软件使用的不断增加，很可能某一时刻当前的硬件配置就不够用了，这时您就需要对硬件进行检查。升级可以朝两个方向发展：垂直升级（使用更大/更多的处理器）和水平升级（使用与当前平台同一规格的更多的计算机/处理器）。
应考虑到的问题：业务逻辑能否和数据分离；业务逻辑能否拆分；数据库能否分段；
执行上述任一操作后对性能有多少提升；如果当前的配置成倍增长，那么性能是否会成倍增长；高容量升级是否会引发直接、间接或者隐藏的成本。
2.3.2商用主流数据库
表8商用数据库优缺点
数据库优点缺点
Oracle[if !supportLists]1）[endif]广泛的支持选项；
[if !supportLists]2）[endif]可在多平台上运行；
[if !supportLists]3）[endif]良好的可扩展性；
[if !supportLists]4）[endif]非常稳定；
[if !supportLists]5）[endif]针对大型数据集的速度最快；
[if !supportLists]6）[endif]强大的第三方应用程序支持
1）对管理员要求较高(经过培训认证)；
2）价格非常昂贵3）授权方式复杂4）升级过程复杂
DB21）可在多平台上运行；
2）良好的支持选项；
3）可以轻松地进行扩容；
4）非常稳定；
5）极佳的压缩特性
1）价格非常昂贵；
2）授权方式复杂；
3）有限的培训选项；
4）有限的附加工具
SQL Server1）出色的维护与开发工具；
2）广泛的支持选项；
3）非常稳定；
4）完整的解决方案，无需添加其他选；
5）大多数情况下可以提供最低的TCO；
6）强大的第三方应用程序支持；
7）与Windows操作系统的紧密整合
1）只能运行在Windows平台；
2）功能不如DB2与Oracle强大；
3）价格相对昂贵
4）需要手动管理
2.3.3开源主流数据库
表9开源数据库优缺点
数据库优点缺点
MySql快速、多线程、多用户；
支持不同的操作系统；灵活而又安全的权限和口令系统；支持ODBC for
Windows；拥有一个非常快速而且稳定的基于线程的内存分配系统，可以持续使用面不必担心其稳定性。
MySQL不完全支持陌生的关键词；使用myisam配置，如果你不慎损坏数据库，结果可能会导致所有的数据丢失；
MongoDB文件验证；
加密存储引擎；
具有内存存储引擎（beta）的实时应用程序；
减少主要故障恢复的时间；
不适合需要处理复杂事务的应用程序；不是传统应用程序的替代品；年轻的解决方案：软件更新快
PostgreSQL创建自定义数据类型和查询方法；框架允许定义和创建自定义数据类型；以十几种编程语言运行存储过程；提供不同的排序和搜索算法MVCC系统需要定期的“清理（vacuuming）”；
高交易率环境中的问题；
由强大的社区发展起来的
3数据库设计
3.1数据库架构演变
3.1.1单主机
最开始网站一般都是由典型的LAMP架构演变而来的，一般都是一台linux主机，一台apache服务器，php执行环境以及mysql服务器，一般情况下，这些都在一台虚拟主机上，简称单主机模式。
单主机模式缺点：1）web服务器和mysql服务器公用一台主机，共享硬件资源，可能存在某一方资源征用太大，导致整个应用产生瓶颈；2）当业务增长之后，没有办法做到横向扩展；3）容错性太差，一旦主机存在问题，整个应用不可用。
3.1.2独立主机
随着业务的发展，可以把mysql服务器和web服务器主机分开，分别部署，就是独立主机模式。
独立主机模式下，web服务器和mysql不再共享硬件资源，分别部署，增加了容错性。如果只是mysql服务器故障，那么对于web上不访问服务器的应用是不会受到影响的。而且web服务器可以做到横向扩展，如果web服务器性能不够，可以增加多台web服务器，进行负载均衡，分散web服务器的压力。
独立主机模式的缺点：1）可扩展性问题：虽然web服务器可以做到横向扩展，但是mysql服务器是没有办法做到横向扩展的；2）可用性问题：mysql服务器存在单点问题，一旦mysql服务器宕机，对影响的影响很大；3）性能问题：单台mysql服务器能够支撑的服务是有限的。
3.1.3读写分离
随着业务的不断发展，数据库的压力会越来越大，单数据库慢慢的就不能满足需求了，一些网站对数据实时性要求不高，就会慢慢发展读写分离模式，对于普通的查询请求，分配到读库（也可以说是备库），对于修改请求，在主库上完成。对于读库，由于是无状态的，可以做到横向扩展。对于写库，还只能是单台主机。
图8读写分离
这种模式其实有限制的，要根据业务的类型来考虑。主库的数据是最新的，但是同步到读库会有时延，所以应用必须能够容忍短暂的不一致性。对于一致性要求非常高的场景是不适合的。
实现层面可能出现的问题：1）主从数据库之间的数据同步问题；2）应用对于数据源的选择问题。
解决思路：1）我们可以使用MYSQL自带的master+slave的方式实现主从复制；2）采用第三方数据库中间件，例如mycat。
这种模式的存在的问题：
1）可扩展性：虽然读库可以做到横向扩展，但是写库还不行，读库不能够横向扩展；
2）可用性：读库成为单点，一旦故障，影响所有的写操作业务；
3）主库无法承受数据写入量时怎么办。
3.1.4读库缓存
随着访问量的增加，逐渐出现了许多用户访问同一部分内容的情况，对于这些比较热门的内容，没必要每次都从数据库读取。我们可以使用缓存技术，例如可以使用google的开源缓存技术guava或者使用memcacahe作为应用层的缓存，也可以使用redis作为数据库层的缓存。
另外，在某些场景下，关系型数据库并不是很适合，例如我想做一个“每日输入密码错误次数限制”的功能，思路大概是在用户登录时，如果登录错误，则记录下该用户的IP和错误次数，那么这个数据要放在哪里呢？假如放在内存中，那么显然会占用太大的内容；假如放在关系型数据库中，那么既要建立数据库表，还要简历对应的java bean，还要写SQL等等。而分析一下我们要存储的数据，无非就是类似{ip:errorNumber}这样的key:value数据。对于这种数据，我们可以用NOSQL数据库来代替传统的关系型数据库。
优点：减轻数据库的压力；大幅度提高访问速度。
缺点：需要维护缓存服务器，提高了编码的复杂性。
3.1.5业务垂直拆分
随着业务的发展，一台写库显然不能够满足高并发的情况，但是考虑到写库是有状态的，不能简单的横向扩展，假设有两台写库，那么随机更新一台的数据，就会导致另一方数据存在问题。出现一种数据两个不同版本，显然是无法接受的。在写库上，可以考虑按照业务来垂直进行分库。所谓垂直就是从业务角度来看，将关联性不强的数据拆分到不同的instance上，从而达到消除瓶颈的目标。
图9数据库的垂直拆分
在按照业务垂直拆分以后，系统在性能上有了很高的提升，只需要把业务上分成垂直部分，分的越细，系统的整体扩展能力就越强。
这种模式下，存在以下几个问题：
[if !supportLists]1）[endif]可用性：假设一个完整的业务流程P访问的数据库被拆分为A、B、C、D、E五个库，假设每个写库可用性为99%，那么这个业务流程P的可用性就为99%*99%*99%*99%*99%=95%，库拆分的越多，对系统的整体可用性挑战就越大；
2）性能：由于垂直业务库每个库的负载可能不一样，假设交易库负载很高，一个交易写库肯定不能够满足需求，这个情况下，交易库成为整个系统的瓶颈；
3）可扩展性：单个节点的可扩展性没有得到改善，交易库不能单独进行扩展。
3.1.6单业务库水平、垂直拆分
在上一种情况，假设交易库是整个系统的瓶颈，需要对交易库进行单独的扩展。可以考虑交易的水平拆分或者垂直拆分，有可能同时进行两种方式拆分。
水平拆分一般根据业务无关的关键字进行拆分，拆分结果是任何实例都只有全量的1/n的数据，横向扩展性比较好，但是对于查询的挑战比较大。
垂直拆分一般根据业务来拆分，但是可能导致数据不均匀以及拆分不够灵活。对于查询来说，相对比较友好，垂直拆分拆完的结果是在一个实例上是拥有全量数据的。
图10水平拆分
以交易库为例，可以先交易的类型进行业务上的垂直分库，在按照订单号进行水平分库。
假设可以分成M*N个库，那么单个库的故障会影响1/M*N的交易，但是假设每个库可用性为99%，那么交易数据库故障概率为(99%)的(M+N)次方，如果数据库拆分的越多，发生单个数据库故障概率就越高。
这种方式存在的问题：1）虽然单个节点故障影响的用户很少，但是整体可用会降低；2）数据库管理上带来复杂的挑战，假设交易库表结构变更，需要执行M×N次脚本变更；3）由于发生单个数据库故障的概率比较高，DBA需经常维护；4）开发和测试成本会变高，查询非常复杂；5）单个节点如果发生故障，没有失败检测并且切换机制；6）分库还不能在水平方向做到无限扩展，我们的算法是事先分配M个库，如果添加一个库基本上不可行。
解决方案：
[if !supportLists]1）[endif]针对垂直拆分查询:在应用层尽量避免跨数据库事务，或者使用中间件进行跨库join；
[if !supportLists]2）[endif]针对水平拆分查询：使用中间件的分页查询方案。
3.2数据库设计的思路
3.2.1初期（读写分离）
读写分离简单的说是把对数据库读和写的操作分开对应不同的数据库服务器，这样能有效地减轻数据库压力，也能减轻io压力。主数据库提供写操作，从数据库提供读操作。
3.2.1.1读写分离整体架构
1）基于后端MySql的主从数据库同步利用MyCat实现的读写分离架构见图11读写分离架构。这种架构适用于读远高于写，并且实时性不高的场景。（注：主从架构是一种用于数据容错的高可用性解决方案，而不是一种处理高并发压力的解决方案，但是加入MyCat可以）
图11读写分离架构
2）从服务器的IO线程从主服务器获取二进制日志，并在本地保存为中继日志，然后通过SQL线程来在从上执行中继日志中的内容，从而使从库和主库保持一致。
图12mysql数据库同步
3.2.2读写分离+数据拆分+负载均衡
（待更新）；
4数据库性能指标及测试
4.1衡量性能的关键性指标
数据库需要着重关注的六个性能指标：数据库性能指标衡量企业应用数据库性能的6大指标 -数据库 - ITeye资讯.htm
文中详细介绍了事务、查询性能、用户和查询冲突、容量、配置。
4.2数据库压测工具
4.2.1Sysbench
sysbench是一个模块化的、跨平台、多线程基准测试工具，主要用于评估测试各种不同系统参数下的数据库负载情况。
主要包括以下几种方式的测试：
1、cpu性能
2、磁盘io性能
3、调度程序性能
4、内存分配及传输速度
5、POSIX线程性能
6、数据库性能(OLTP基准测试)
目前sysbench主要支持mysql,pgsql,oracle这3种数据库。
测试示例网址：基准测试工具之sysbench
4.2.2Tpcc-mysql
TPC(Tracsaction
Processing Performance Council)事务处理性能协会是一个评价大型数据库系统软硬件性能的非盈利的组织,TPC-C是TPC协会制定的，用来测试典型的复杂OLTP系统的性能。Tpcc-mysql是percona基于tpcc衍生出来的产品，专用于mysql基准测试，其源码放在bazaar上，因此需要先安装bazaar客户端。值得说明的是Tpcc-mysql包括五个处理逻辑，是比较贴近电商平台业务的一个压测工具New-Order :新订单Payment :支付Order-Status :订单查询Delivery:发货Stock-Level
:库存。
项目地址：源码地址
测试示例：tpcc使用结果示例
4.2.3mysqlslap
mysqlslap是从5.1.4版开始的一个MySQL官方提供的压力测试工具。通过模拟多个并发客户端访问MySQL来执行压力测试，同时提供了比较详细的数据性能报告。并且能很好的对比多个存储引擎在相同环境下的并发压力性能差别。通过mysqlslap–help可以获得可用的选项。
官网地址：mysqlslap官网
测试示例：mysqlslap使用实例
4.2.4tcpcopy
TCPCOPY是一个tcp流量的实时复制工具，其1.0版本由网易工程师@tcpcopy开发和维护。一般用来将生产环境的线上流量实时复制到测试环境进行测试。例如新系统上线前，如果我们希望进行一些基本的压力测试，那么我们可以直接利用tcpcopy来复制线上的流量过来对系统进行测试，这样的好处是测试数据接近真实水平，且实施起来相对简单。下面我们将通过一个真实的使用案例，来简单介绍tcpcopy的基本使用方法。我们假定读者对tcp以及路由相关基本知识有一定了解。
项目地址：项目源码地址
4.2.5Mydbtest
楼方鑫的一款压测工具，可以根据业务模型配置业务的sql，利用线上的数据备份进行压测的一款工具。具有免安装，上手快，而且可以针对业务sql做定制化压测等优点
测试示例：Mydbtest测试实例
5数据库优化
数据库的优化一方面是找出系统的瓶颈，提高数据库的整体性能，另一方面是设计合理的结构和参数调整，以提高用户的访问速度；同时还要尽可能节省系统资源，以便系统提供更大负荷的服务。详见：数据库五个方面的性能优化
图13计算机性能指标
从图13可以看到基本上每种设备都有两个指标：延时（响应时间）：表示硬件的突发处理能力；带宽（吞吐量）：代表硬件持续处理能力。
根据数据库知识，我们可以列出每种硬件主要的工作内容：1)CPU及内存：缓存数据访问、比较、排序、事务检测、SQL解析、函数或逻辑运算；2)网络：结果数据传输、SQL请求、远程数据库访问（dblink）；3)硬盘：数据访问、数据写入、日志记录、大数据量排序、大表连接。
根据当前计算机硬件的基本性能指标及其在数据库中主要操作内容，可以整理出如下图所示的性能基本优化法则：1）减少数据访问（减少磁盘访问）；2）返回更少数据（减少网络传输或磁盘访问）；3）减少交互次数（减少网络传输）；4）减少服务器CPU开销（减少CPU及内存开销）；5）利用更多资源（增加资源）；6）数据库备份；7）数据库安全。
优化成本见表10硬件优化成本。
表10硬件优化成本
优化法则性能提升效果优化成本
减少数据访问1~1000低
返回更少数据1~100低
减少交互次数1~20低
减少服务器CPU开销1~5低
利用更多资源@~10高
5.1减少数据访问
5.1.1创建并正确使用索引
索引会大大增加表记录的DML(INSERT,UPDATE,DELETE)开销，正确的索引可以让性能提升100，1000倍以上，不合理的索引也可能会让性能下降100倍，因此在一个表中创建什么样的索引需要平衡各种业务需求。
常见的索引有B-TREE索引、位图索引、全文索引，位图索引一般用于数据仓库应用，全文索引由于使用较少，这里不深入介绍。B-TREE索引包括很多扩展类型，如组合索引、反向索引、函数索引等等。
5.1.2组合索引
有些时候，我们只是访问表中的几个字段，并且字段内容较少，我们可以为这几个字段单独建立一个组合索引，这样就可以直接只通过访问索引就能得到数据，一般索引占用的磁盘空间比表小很多，所以这种方式可以大大减少磁盘IO开销。
如：select id,name fromcompany where type='2';
如果这个SQL经常使用，我们可以在type,id,name上创建组合索引：
createindex my_comb_index on company(type,id,name);
有了这个组合索引后，SQL就可以直接通过my_comb_index索引返回数据，不需要访问company表。
注：性能优化是无止境的，当性能可以满足需求时即可，不要过度优化。
5.1.3优化SQL执行计划
所谓执行计划，顾名思义，就是对一个查询任务，做出一份怎样去完成任务的详细方案。举个生活中的例子，我从珠海要去英国，我可以选择先去香港然后转机，也可以先去北京转机，或者去广州也可以。但是到底怎样去英国划算，也就是我的费用最少，这是一件值得考究的事情。同样对于查询而言，我们提交的SQL仅仅是描述出了我们的目的地是英国，但至于怎么去，通常我们的SQL中是没有给出提示信息的，是由数据库来决定的。
基于代价的优化器在绝大多数情况下它会选择正确的优化器，减轻了DBA的负担。但有时它也聪明反被聪明误，选择了很差的执行计划，使某个语句的执行变得奇慢无比。此时就需要DBA进行人为的干预，告诉优化器使用我们指定的存取路径或连接类型生成执行计划，从而使语句高效的运行。例如:对于一个特定的语句，执行全表扫描要比执行索引扫描更有效，则我们可以指示优化器使用全表扫描。
关于执行计划的解释详见：http://blog.chinaunix.net/uid-22864942-id-375762.html
5.2返回更少数据
5.2.1数据分页处理
5.2.1.1客户端分页
将数据从应用服务器全部下载到本地应用程序或浏览器，在应用程序或浏览器内部通过本地代码进行分页处理
优点：编码简单，减少客户端与应用服务器网络交互次数
缺点：首次交互时间长，占用客户端内存
适应场景：客户端与应用服务器网络延时较大，但要求后续操作流畅，如手机GPRS，超远程访问（跨国）等等。
5.2.1.2应用服务器分页
将数据从数据库服务器全部下载到应用服务器，在应用服务器内部再进行数据筛选。以下是一个应用服务器端Java程序分页的示例：
Listlist=executeQuery(“select * from employee order by id”);
Int count=list.size();
ListsubList= list.subList(10, 20);
优点：编码简单，只需要一次SQL交互，总数据与分页数据差不多时性能较好。
缺点：总数据量较多时性能较差。
适应场景：数据库系统不支持分页处理，数据量较小并且可控。
5.2.1.3数据库SQL分页
采用数据库SQL分页需要两次SQL完成
一个SQL计算总数量
一个SQL返回分页后的数据
优点：性能好
缺点：编码复杂，各种数据库语法不同，需要两次SQL交互。
5.2.2返回所需字段
通过去除不必要的返回字段可以提高性能，例：
调整前：select * fromproduct where company_id=?;
调整后：select id,namefrom product where company_id=?;
优点：1、减少数据在网络上传输开销；2、减少服务器数据处理开销；3、减少客户端内存占用；4、字段变更时提前发现问题，减少程序BUG；5、如果访问的所有字段刚好在一个索引里面，则可以使用纯索引访问提高性能。
缺点：增加编码工作量
5.3减少交互次数
具体包括：batch DML；In List；设置Fetch Size；使用存储过程；优化业务逻辑；使用ResultSet游标处理记录等方法。
5.4减少服务器CPU开销
具体的方法包括：使用绑定变量；合理使用排序；较少比较操作；大量复杂运算在客户端处理等等。
5.5利用更多资源
具体方法包括利用客户端多进程访问；数据库并行处理等等。
6数据库安全
6.1定义
数据库安全包含两层含义：
第一层是指系统运行安全，系统运行安全通常受到的威胁如下，一些网络不法分子通过网络，局域网等途径通过入侵电脑使系统无法正常启动，或超负荷让机子运行大量算法，并关闭cpu风扇，使cpu过热烧坏等破坏性活动；
第二层是指系统信息安全，系统安全通常受到的威胁如下，黑客对数据库入侵，并盗取想要的资料。数据库系统的安全特性主要是针对数据而言的，包括数据独立性、数据安全性、数据完整性、并发控制、故障恢复等几个方面。
6.2常见问题及解决措施
6.2.1错误地部署
开发者在部署过程中的粗心大意会很容易让数据库陷入危难之中。在现实中，有些公司会意识到优化搜索引擎对于业务取得成功的重要性，但只有对数据库进行排序，SEO才可以很好地对其优化。尽管功能性测试对性能有一定的保证，但测试并不能预料数据库会发生的一切。因此，在进行完全部署之前，对数据库进行全面的检查是非常有必要的。
6.2.2数据泄露
你可以把数据库当做后端设置的一部分，并将焦点转移到保护互联网安全上面，黑客很容易操纵数据库中的网络接口的，所以，为了避免这种现象发生，工程师在进行数据库开发时，使用TLS或SSL加密通信平台变的尤为重要。
6.2.3数据库维护
你是否还记得2003年的SQL Slammer蠕虫病毒，该病毒利用SQL Server的漏洞进行传播，导致全球范围内的互联网瘫痪，中国也有80%以上网民受到影响。该蠕虫的成功充分说明了保护数据库安全是多么的重要。不幸的是，现实中很少有公司对他们的系统提供常规的补丁，因此，他们很容易遭受蠕虫攻击。
6.2.4数据库备份信息被盗
通常，数据库备份信息外泄一般会来自两种途径，一个是外部，一个是内部的。这是许多企业会经常遇到的问题，而解决这种问题的唯一方法是对档案进行加密。
6.2.5滥用数据库特性
据专家称，每一个被黑客攻击的数据库都会滥用数据库特性。例如，黑客可以在系统没有执行的情况下随意进入系统。解决这种问题的方法是移除不必要的工具。
6.2.6基础设施薄弱
黑客一般不会马上控制整个数据库，相反，他们会选择玩跳房子游戏来发现基础架构中薄弱的地方，然后再利用该地方的优势来发动字符串攻击，直到抵达后端。
6.2.7缺乏隔离
给管理员和用户进行职责划分，如果他们试图盗取数据，那么内部员工将会面临更多的困难。所以，限制用户数量，这样黑客想控制整个数据库就会有一定的挑战。
6.2.8 SQL注入
一旦应用程序被注入恶意的字符串来欺骗服务器执行命令，那么管理员不得不收拾残局，在保护数据库上，这是一个主要问题。目前最佳的解决方案就是使用防火墙来保护数据库网络。
6.2.9密钥管理不当
保证密钥安全是非常重要的，但是加密密钥通常存储在公司的磁盘驱动器上，如果无人防守，那么您的系统会很容易遭受黑客攻击。
6.2.10违法操作
开发人员可以利用追踪信息/日志文本来查询和解决此类问题。
7数据库备份与还原
7.1数据库备份类型
按照备份数据库的大小数据库备份有四种类型：
1）完全备份：这是大多数人常用的方式，它可以备份整个数据库，包含用户表、系统表、索引、视图和存储过程等所有数据库对象。但它需要花费更多的时间和空间，所以，一般推荐一周做一次完全备份。
2）事务日志备份：事务日志是一个单独的文件，它记录数据库的改变，备份的时候只需要复制自上次备份以来对数据库所做的改变，所以只需要很少的时间。为了使数据库具有鲁棒性，推荐每小时甚至更频繁的备份事务日志。
3）差异备份：也叫增量备份。它是只备份数据库一部分的另一种方法，它不使用事务日志，相反，它使用整个数据库的一种新映象。它比最初的完全备份小，因为它只包含自上次完全备份以来所改变的数据库。它的优点是存储和恢复速度快。推荐每天做一次差异备份。
4）文件备份：数据库可以由硬盘上的许多文件构成。如果这个数据库非常大，并且一个晚上也不能将它备份完，那么可以使用文件备份每晚备份数据库的一部分。由于一般情况下数据库不会大到必须使用多个文件存储，所以这种备份不是很常用。
按照数据库的状态可分为三种：
1.冷备份，此时数据库处于关闭状态，能够较好的保证数据库的完整性。
2.热备份，数据库正处于运行状态，这种方法依赖于数据库的日志文件进行备份。
3.逻辑备份，使用软件从数据库中提取数据并将结果写到一个文件上。
7.2数据库恢复
1）还原完整备份
还原完整备份是指对数据库完整备份文件进行还原，将数据库还原到完备时的状态。
2）还原完整备份+差异备份
该方式是将数据库还原到差异备份的状态。在还原完整备份后，可以继续对目标数据库还原差异备份，用于将差异备份保存的数据更新进入当前数据库，使数据库还原到差异备份时的状态。
3）还原完整备份+差异备份+事务日志备份
该方式是将数据库还原到事务日志备份时的状态。在还原完整备份后，可以继续对目标数据库还原差异备份然后在继续还原事务日志备份，用于将差异备份、事务日志备份保存的数据更新进入当前数据库，使数据库还原到事务日志备份时的状态。
附录一文件系统
所谓文件系统，它是操作系统中藉以组织、存储和命名文件的结构。磁盘或分区和它所包括的文件系统的不同是很重要的，大部分应用程序都基于文件系统进行操作，在不同种文件系统上是不能工作的。
文件系统简介
FAT16
FAT文件系统FAT文件系统最初用于小型磁盘和简单文件结构的简单文件系统。
磁盘文件系统文件系统就是在硬盘上存储信息的格式。
FAT32文件系统FAT32文件系统提供了比FAT文件系统更为先进的文件管理特性
NTFS文件系统NTFS文件系统的设计目标就是用来在很大的硬盘上能够很快地执行诸如：读、写和搜索这样的标准文件操作，甚至包括像文件系统恢复这样的高级操作
VFATVFAT是“扩展文件分配表系统”的意思，主要应用于在Windows 95中。它对FAT16文件系统进行扩展，并提供支持长文件名，文件名可长达255个字符
HPFS高性能文件系统。OS/2的高性能文件系统(HPFS)主要克服了FAT文件系统不适合于高档操作系统这一缺点，HPFS支持长文件名，比FAT文件系统有更强的纠错能力。
ext2Linux中使用最多的一种文件系统，因为它是专门为Linux设计，拥有最快的速度和最小的CPU占用率。
附录二SqlServer性能指标
指标名称指标描述指标范围指标单位
1．SQL
Server中访问方法（Access Methods）对象包含的性能计数器
全表扫描/秒
(Full Scans/sec)
指每秒全表扫描的数量。全表扫描可以是基本表扫描或全索引扫描。由于全表扫描需要耗费大量时间，因此全表扫描的频率过高的话，会影响性能。如果该指标的值比1或2高，应该分析设计的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。次数/秒
2．SQL
Server中缓冲器管理器（Buffer
Manager）对象包含的性能计数器
缓冲区高速缓存命中率(BufferCache
Hit Ratio%）
指在缓冲区高速缓存中找到而不需要从磁盘中读取的页的百分比。该比率是缓存命中总次数与缓存查找总次数之比。经过很长时间后，该比率的变化很小。由于从缓存中读取数据比从磁盘中读取数据的开销小得多，一般希望该比率高一些。该指标的值最好为90%或更高。通常可以通过增加SQL Server可用的内存数量来提高该指标的值。增加内存直到这指标的值持续高于90%，表示90%以上的数据请求可以从数据缓冲区中获得所需数据。%
读的页/秒
(Page Reads/sec)
指每秒发出的物理数据库页读取数。该指标主要考察数据库从磁盘读取数据的频率。因为物理I/O会耗费大量时间，所以应尽可能地减少物理I/O以提高性能。该指标的值应尽可能的小。可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，以降低该指标的值。个数/秒
写的页/秒
(Page Writes/sec)
指每秒执行的物理数据库写的页数。该指标主要考察数据库向磁盘写入数据的频率。因为物理I/O会耗费大量时间，所以应尽可能地减少物理I/O以提高性能。该指标的值应尽可能的小。可以通过使用更大的数据高速缓存、智能索引、更高效的查询或者改变数据库设计等方法，以降低该指标的值。个数/秒
惰性写/秒
(Lazy Writes/sec)
指每秒被缓冲区管理器的惰性编写器写入的缓冲区数。惰性编写器是一个系统进程，用于成批刷新脏的老化的缓冲区（包含更改的缓冲区，必须将这些更改写回磁盘，才能将缓冲区重用于其他页），并使它们可用于用户进程。该指标的值最好为0。个数/秒
3．SQL
Server中高速缓存管理器（Cache
Manager）对象包含的性能计数器
高速缓存命中率(Cache Hit Ratio%）指高速缓存命中次数和查找次数的比率。在SQL
Server中，Cache包括Log Cache，Buffer
Cache以及Procedure Cache，该指标是指所有Cache的命中率，是一个总体的比率。
该指标的值越高越好。如果该指标的值持续低于80%，就需要增加更多的内存。%
4．SQL
Server中闩（Latches）对象包含的性能计数器
平均闩等待
时间(毫秒)
(Average Latch
Wait Time(ms))
指一个SQL
Server线程必须等待一个闩的平均时间。
如果该指标的值很高，则系统可能正经历严重的资源竞争问题。毫秒
闩等待/秒
(Latch Waits/sec)
指在一个闩上每秒的平均等待数量。如果该指标的值很高，则系统可能正经历严重的资源竞争问题。个数/秒
5．SQL
Server中锁（Locks）对象包含的性能计数器
死锁的数量/秒
(Number of Deadlocks/sec)
指每秒导致死锁的锁请求数。锁加在SQL
Server资源上（如在一个事务中进行的行读取或修改），以防止多个事务并发使用资源。应尽可能少使用锁以提高事务的并发性，从而改善性能。
个数/秒
平均等待时间(毫秒)
(Average Wait
Time(ms))
指线程等待某种类型的锁的平均等待时间。同上毫秒
锁请求/秒
(Lock Requests/sec)
指每秒钟某种类型的锁请求的数量。同上个数/秒
附录三DB2性能指标
附录四oracle数据库性能指标