如何对数据库备份进行性能优化

一、选择合理的备份时机。虽然说，SQL Server数据库在联机或者活动状态，也可以进行备份。但是，一般情况下，笔者不建议这么做。因为在数据库活动的时候进行备份的话，一方面会增加备份的时间;另一方面，因为备份作业占用了一定的硬件资源，会对数据库的访问性能产生比较大的影响，特别是并发性访问。所以，在数据库备份的时候，数据库管理员应当尽量减少SQL Server中的当前活动。对于大部分企业来说，一般数据库活动的高发期在白天的八个小时。故从理论上说，除了这八个小时外，对数据库进行备份的话，可以把这个不利影系降低到最低。笔者现在的备份策略，就是在凌晨一点开始进行数据库备份。根据笔者一段时间的追踪，发现在这个时段内，基本上没有用户访问数据库。故笔者利用SQL Server的任务计划结合数据库的备份策略，定在凌层这个时间进行数据库备份。不过，为了保障数据库备份的准确性，在第二天上班后，就需要查看相关的备份日志。看看在备份的过程中有否出现异常情况。若有的话，要及时加以解决。总之，数据库备份的时机选择上，一个基本原则就是“在备份作业进行的整个过程中，尽量减少数据库的当前活动”。二、备份到多个物理设备。通常情况下，与备份到单个物理设备相比，备份到多个物理设备的速度会更快一点。为此，数据库管理员可以通过并行方式将数据复制到各个备份设备中。SQL Server服务器通过相关技术，能够充分利用多个备份设备的优势。SQL Server数据库可以同时向多个备份文件进行写 *** 作。在企业具有多个备份文件的时候，数据库可以将数据条带化的分布到用于创建备份的全部文件中。通俗说的说，就是建立多个备份文件，然后把不同的备份文件存储在不同的物理设备上。如此的话，就好像是在泄洪的时候，多开几个通道。那么，很明显可以缩短备份的时间。在另一方面，也就降低了备份作业对数据库的不利影响。从理论上说，如果备份到单个设备上需要3个小时，则备份到两个硬盘上的话，则可以缩短为一个半小时。当然，实际能够把备份时间缩短到多少，还跟硬件的读取速度、服务器的性能相关。但是可以肯定的一点就是，把备份文件存储到多个硬件设备中，实现条带化备份，是可以大幅度的缩短备份所需要的时间。在使用这种方法降低备份对数据库的不利影响，需要注意以下几个方面的内容：1、在备份时，所采用的硬件设备必须属于同种类型的媒体。现在用户备份的媒体主要有磁带或者硬盘。不过，现在基本上大家都习惯于硬盘。在进行条带化备份的时候，数据库管理员不能够在单个备份媒体集中混合使用磁带或者硬盘设备。这是在工作中要切记的一个限制条件。2、如果将某个备份文件定义为备份集成员，那么用户就必须一起使用这些文件。也就是说，数据库管理员若设置了多个备份文件，则无论是在对其进行异地备份，还是在进行还原的时候，要对所有的备份文件进行 *** 作。不然的话，很可能会丢失部分数据。这就好像一个蛋糕，数据库管理员把它切成一快一快。若要把它换一个地方存放的话，则要把切割后的每一块蛋糕都搬走。少一块的话，蛋糕就不完整了。这也是类似的道理。3、如果删除了某个备份集的成员，则备份集中其他成员所包含的数据是无效的，不能够被使用。也就是说，数据库在执行条带化备份的时候，在各个备份文件中存储的数据是没有规则的。并不是说，一个备份文件中就存储索引，另一个备份文件中存储数据信息。即时某个备份文件不小心丢失了，仍然可以利用另外的备份文件修复部分数据。这是不肯能的。这就好利用RAR等工具分割压缩文件的时候，必须所有的压缩文件齐全，才能够解压缩文件。故这就要求数据库管理员在对这些文件进行异地备份的时候，要考虑其完整性。在SQL Server数据库中，可以利用MEDIANAME参数来为整个备份媒体集指名媒体名。当使用多个文件来备份数据库的时候，数据库管理员就要使用这个选项。利用这个参数，可以把各个独立的备份文件作为媒体集的成员而相互联系起来。三、物理设备的速度决定备份所需要的时间。不同类型的物理设备，由于其本身性能的差异，对数据库备份的时间也会有不小的影响。如早起的磁带备份设备，相比较磁盘设备来说，备份就需要花费更多的时间。现在硬件设备在不断的跌价中，故数据库管理员在备份设备的选择上，可以有更多的选择余地。在力所能及的情况下，最好能够选择性能高一点的备份设备。另外，即使都是硬盘，其性能也会有所差异。故数据库管理员最好能够跟硬件管理人眼一起，商量确定一个合适的硬件设备。四、合理使用完全数据库备份。一般来说，数据库备份包括完全数据库备份、差异数据库备份等等几种方式。而对数据库进行完全备份，所需要花费的时间最长。故若数据库管理员能够合理选择完全数据库备份的时机，就可以大幅度的降低数据库备份对服务器性能的不利影响。通常来说，在下面两种情况下，可以考虑只采用数据库完全备份。一是在数据库容量比较小的时候。若数据库管理员认为备份这个小型数据库所花费的时间是可以忍受的，则就可以采用完全数据库备份策略。二是数据库的数据修改频率很低，或者数据库是只读的。此时，数据库管理员若执行完全数据库备份，将会备份相当完整的数据集。如果数据库在两次备份之间不幸出现了故障，对其进行恢复时，企业用户或许可以少受损失。在完全备份的时候，SQL Server会备份在备份过程中发生的任何活动;同行也会备份事务日志中的任何未提交事务。这主要是因为在对数据库进行恢复的时候，为了保证数据的一致性，SQL Server需要使用备份文件中所记录的部分事务日志。除了以上两种情况外，最好对数据库执行完全备份与差异备份结合的策略。如笔者企业现在的备份策略是，从星期一到星期六执行差异备份，星期天执行完全备份。因为差异备份要比完全备份所花费的时间少的多。通过这种方式，即保障了数据的安全性，同时，也可以最大限度的对数据备份的性能进行优化。总之，在数据库备份的时候，这个作业对数据库性能的不利影响肯定是存在的。数据库管理员现在可以做的，就是想法设法，把数据库备份所需要的时间尽量缩短。并且合理安排数据库备份的时间，要把数据库备份作业跟用户使用数据库的的繁忙时间错开，减少他们对于硬件资源的争夺。

本文首先讨论了基于第三范式的数据库表的基本设计，着重论述了建立主键和索引的策略和方案，然后从数据库表的扩展设计和库表对象的放置等角度概述了数据库管理系统的优化方案。

关键词： 优化（Optimizing） 第三范式（3NF） 冗余数据（Redundant Data） 索引（Index） 数据分割（Data Partitioning） 对象放置（Object Placement）

1 引言

数据库优化的目标无非是避免磁盘I/O瓶颈、减少CPU利用率和减少资源竞争。为了便于读者阅读和理解，笔者参阅了Sybase、Informix和Oracle等大型数据库系统参考资料，基于多年的工程实践经验，从基本表设计、扩展设计和数据库表对象放置等角度进行讨论，着重讨论了如何避免磁盘I/O瓶颈和减少资源竞争，相信读者会一目了然。

2 基于第三范式的基本表设计

在基于表驱动的信息管理系统（MIS）中，基本表的设计规范是第三范式（3NF）。第三范式的基本特征是非主键属性只依赖于主键属性。基于第三范式的数据库表设计具有很多优点：一是消除了冗余数据，节省了磁盘存储空间；二是有良好的数据完整性限制，即基于主外键的参照完整限制和基于主键的实体完整性限制，这使得数据容易维护，也容易移植和更新；三是数据的可逆性好，在做连接（Join）查询或者合并表时不遗漏、也不重复；四是因消除了冗余数据（冗余列），在查询（Select）时每个数据页存的数据行就多，这样就有效地减少了逻辑I/O，每个Cash存的页面就多，也减少物理I/O；五是对大多数事务(Transaction)而言，运行性能好；六是物理设计(Physical Design)的机动性较大，能满足日益增长的用户需求。

在基本表设计中，表的主键、外键、索引设计占有非常重要的地位，但系统设计人员往往只注重于满足用户要求，而没有从系统优化的高度来认识和重视它们。实际上，它们与系统的运行性能密切相关。现在从系统数据库优化角度讨论这些基本概念及其重要意义：

（1）主键(Primary Key)：主键被用于复杂的SQL语句时，频繁地在数据访问中被用到。一个表只有一个主键。主键应该有固定值（不能为Null或缺省值，要有相对稳定性），不含代码信息，易访问。把常用（众所周知）的列作为主键才有意义。短主键最佳（小于25bytes），主键的长短影响索引的大小，索引的大小影响索引页的大小，从而影响磁盘I/O。主键分为自然主键和人为主键。自然主键由实体的属性构成，自然主键可以是复合性的，在形成复合主键时，主键列不能太多，复合主键使得Join作复杂化、也增加了外键表的大小。人为主键是，在没有合适的自然属性键、或自然属性复杂或灵敏度高时，人为形成的。人为主键一般是整型值（满足最小化要求），没有实际意义，也略微增加了表的大小；但减少了把它作为外键的表的大小。

（2）外键（Foreign Key）：外键的作用是建立关系型数据库中表之间的关系（参照完整性），主键只能从独立的实体迁移到非独立的实体，成为后者的一个属性，被称为外键。

（3）索引(Index)：利用索引优化系统性能是显而易见的，对所有常用于查询中的Where子句的列和所有用于排序的列创建索引，可以避免整表扫描或访问，在不改变表的物理结构的情况下，直接访问特定的数据列，这样减少数据存取时间；利用索引可以优化或排除耗时的分类作；把数据分散到不同的页面上，就分散了插入的数据；主键自动建立了唯一索引，因此唯一索引也能确保数据的唯一性（即实体完整性）；索引码越小，定位就越直接；新建的索引效能最好，因此定期更新索引非常必要。索引也有代价：有空间开销，建立它也要花费时间，在进行Insert、Delete和Update作时，也有维护代价。索引有两种：聚族索引和非聚族索引。一个表只能有一个聚族索引，可有多个非聚族索引。使用聚族索引查询数据要比使用非聚族索引快。在建索引前，应利用数据库系统函数估算索引的大小。

① 聚族索引（Clustered Index）：聚族索引的数据页按物理有序储存，占用空间小。选择策略是，被用于Where子句的列：包括范围查询、模糊查询或高度重复的列（连续磁盘扫描）；被用于连接Join作的列；被用于Order by和Group by子句的列。聚族索引不利于插入作，另外没有必要用主键建聚族索引。

② 非聚族索引（Nonclustered Index）：与聚族索引相比，占用空间大，而且效率低。选择策略是，被用于Where子句的列：包括范围查询、模糊查询（在没有聚族索引时）、主键或外键列、点（指针类）或小范围（返回的结果域小于整表数据的20%）查询；被用于连接Join作的列、主键列（范围查询）；被用于Order by和Group by子句的列；需要被覆盖的列。对只读表建多个非聚族索引有利。索引也有其弊端，一是创建索引要耗费时间，二是索引要占有大量磁盘空间，三是增加了维护代价（在修改带索引的数据列时索引会减缓修改速度）。那么，在哪种情况下不建索引呢？对于小表（数据小于5页）、小到中表（不直接访问单行数据或结果集不用排序）、单值域（返回值密集）、索引列值太长（大于20bitys）、容易变化的列、高度重复的列、Null值列，对没有被用于Where子语句和Join查询的列都不能建索引。另外，对主要用于数据录入的，尽可能少建索引。当然，也要防止建立无效索引，当Where语句中多于5个条件时，维护索引的开销大于索引的效益，这时，建立临时表存储有关数据更有效。

批量导入数据时的注意事项：在实际应用中，大批量的计算（如电信话单计费）用C语言程序做，这种基于主外键关系数据计算而得的批量数据（文本文件），可利用系统的自身功能函数（如Sybase的BCP命令）快速批量导入，在导入数据库表时，可先删除相应库表的索引，这有利于加快导入速度，减少导入时间。在导入后再重建索引以便优化查询。

（4）锁：锁是并行处理的重要机制，能保持数据并发的一致性，即按事务进行处理；系统利用锁，保证数据完整性。因此，我们避免不了死锁，但在设计时可以充分考虑如何避免长事务，减少排它锁时间，减少在事务中与用户的交互，杜绝让用户控制事务的长短；要避免批量数据同时执行，尤其是耗时并用到相同的数据表。锁的征用：一个表同时只能有一个排它锁，一个用户用时，其它用户在等待。若用户数增加，则Server的性能下降，出现“假死”现象。如何避免死锁呢？从页级锁到行级锁，减少了锁征用；给小表增加无效记录，从页级锁到行级锁没有影响，若在同一页内竞争有影响，可选择合适的聚族索引把数据分配到不同的页面；创建冗余表；保持事务简短；同一批处理应该没有网络交互。

（5）查询优化规则：在访问数据库表的数据(Access Data)时，要尽可能避免排序（Sort）、连接(Join)和相关子查询作。经验告诉我们，在优化查询时，必须做到：

① 尽可能少的行；

② 避免排序或为尽可能少的行排序，若要做大量数据排序，最好将相关数据放在临时表中作；用简单的键（列）排序，如整型或短字符串排序；

③ 避免表内的相关子查询；

④ 避免在Where子句中使用复杂的表达式或非起始的子字符串、用长字符串连接；

⑤ 在Where子句中多使用“与”（And）连接，少使用“或”(Or)连接；

⑥ 利用临时数据库。在查询多表、有多个连接、查询复杂、数据要过滤时，可以建临时表（索引）以减少I/O。但缺点是增加了空间开销。

除非每个列都有索引支持，否则在有连接的查询时分别找出两个动态索引，放在工作表中重新排序。

3 基本表扩展设计

基于第三范式设计的库表虽然有其优越性（见本文第一部分），然而在实际应用中有时不利于系统运行性能的优化：如需要部分数据时而要扫描整表，许多过程同时竞争同一数据，反复用相同行计算相同的结果，过程从多表获取数据时引发大量的连接作，当数据来源于多表时的连接作；这都消耗了磁盘I/O和CPU时间。

尤其在遇到下列情形时，我们要对基本表进行扩展设计：许多过程要频繁访问一个表、子集数据访问、重复计算和冗余数据，有时用户要求一些过程优先或低的响应时间。

如何避免这些不利因素呢？根据访问的频繁程度对相关表进行分割处理、存储冗余数据、存储衍生列、合并相关表处理，这些都是克服这些不利因素和优化系统运行的有效途径。

31 分割表或储存冗余数据

分割表分为水平分割表和垂直分割表两种。分割表增加了维护数据完整性的代价。

水平分割表：一种是当多个过程频繁访问数据表的不同行时，水平分割表，并消除新表中的冗余数据列；若个别过程要访问整个数据，则要用连接作，这也无妨分割表；典型案例是电信话单按月分割存放。另一种是当主要过程要重复访问部分行时，最好将被重复访问的这些行单独形成子集表（冗余储存），这在不考虑磁盘空间开销时显得十分重要；但在分割表以后，增加了维护难度，要用触发器立即更新、或存储过程或应用代码批量更新，这也会增加额外的磁盘I/O开销。

垂直分割表（不破坏第三范式），一种是当多个过程频繁访问表的不同列时，可将表垂直分成几个表，减少磁盘I/O（每行的数据列少，每页存的数据行就多，相应占用的页就少），更新时不必考虑锁，没有冗余数据。缺点是要在插入或删除数据时要考虑数据的完整性，用存储过程维护。另一种是当主要过程反复访问部分列时，最好将这部分被频繁访问的列数据单独存为一个子集表（冗余储存），这在不考虑磁盘空间开销时显得十分重要；但这增加了重叠列的维护难度，要用触发器立即更新、或存储过程或应用代码批量更新，这也会增加额外的磁盘I/O开销。垂直分割表可以达到最大化利用Cache的目的。

总之，为主要过程分割表的方法适用于：各个过程需要表的不联结的子集，各个过程需要表的子集，访问频率高的主要过程不需要整表。在主要的、频繁访问的主表需要表的子集而其它主要频繁访问的过程需要整表时则产生冗余子集表。

注意，在分割表以后，要考虑重新建立索引。

32 存储衍生数据

对一些要做大量重复性计算的过程而言，若重复计算过程得到的结果相同（源列数据稳定，因此计算结果也不变），或计算牵扯多行数据需额外的磁盘I/O开销，或计算复杂需要大量的CPU时间，就考虑存储计算结果（冗余储存）。现予以分类说明：

若在一行内重复计算，就在表内增加列存储结果。但若参与计算的列被更新时，必须要用触发器更新这个新列。

若对表按类进行重复计算，就增加新表（一般而言，存放类和结果两列就可以了）存储相关结果。但若参与计算的列被更新时，就必须要用触发器立即更新、或存储过程或应用代码批量更新这个新表。

若对多行进行重复性计算（如排名次），就在表内增加列存储结果。但若参与计算的列被更新时，必须要用触发器或存储过程更新这个新列。

总之，存储冗余数据有利于加快访问速度；但违反了第三范式，这会增加维护数据完整性的代价，必须用触发器立即更新、或存储过程或应用代码批量更新，以维护数据的完整性。

33 消除昂贵结合

对于频繁同时访问多表的一些主要过程，考虑在主表内存储冗余数据，即存储冗余列或衍生列（它不依赖于主键），但破坏了第三范式，也增加了维护难度。在源表的相关列发生变化时，必须要用触发器或存储过程更新这个冗余列。当主要过程总同时访问两个表时可以合并表，这样可以减少磁盘I/O作，但破坏了第三范式，也增加了维护难度。对父子表和1：1关系表合并方法不同：合并父子表后，产生冗余表；合并1：1关系表后，在表内产生冗余数据。

4 数据库对象的放置策略

数据库对象的放置策略是均匀地把数据分布在系统的磁盘中，平衡I/O访问，避免I/O瓶颈。

⑴ 访问分散到不同的磁盘，即使用户数据尽可能跨越多个设备，多个I/O运转，避免I/O竞争，克服访问瓶颈；分别放置随机访问和连续访问数据。

⑵ 分离系统数据库I/O和应用数据库I/O。把系统审计表和临时库表放在不忙的磁盘上。

⑶ 把事务日志放在单独的磁盘上，减少磁盘I/O开销，这还有利于在障碍后恢复，提高了系统的安全性。

⑷ 把频繁访问的“活性”表放在不同的磁盘上；把频繁用的表、频繁做Join作的表分别放在单独的磁盘上，甚至把把频繁访问的表的字段放在不同的磁盘上，把访问分散到不同的磁盘上，避免I/O争夺；

⑸ 利用段分离频繁访问的表及其索引（非聚族的）、分离文本和图像数据。段的目的是平衡I/O，避免瓶颈，增加吞吐量，实现并行扫描，提高并发度，最大化磁盘的吞吐量。利用逻辑段功能，分别放置“活性”表及其非聚族索引以平衡I/O。当然最好利用系统的默认段。另外，利用段可以使备份和恢复数据更加灵活，使系统授权更加灵活。

你最好买一本专门讲ORACLE性能优化的书，好好看看\x0d\1、调整数据库服务器的性能\x0d\Oracle数据库服务器是整个系统的核心，它的性能高低直接影响整个系统的性能，为了调整Oracle数据库服务器的性能，主要从以下几个方面考虑： \x0d\11、调整 *** 作系统以适合Oracle数据库服务器运行\x0d\Oracle数据库服务器很大程度上依赖于运行服务器的 *** 作系统，如果 *** 作系统不能提供最好性能，那么无论如何调整，Oracle数据库服务器也无法发挥其应有的性能。 \x0d\111、为Oracle数据库服务器规划系统资源 \x0d\据已有计算机可用资源, 规划分配给Oracle服务器资源原则是：尽可能使Oracle服务器使用资源最大化,特别在Client/Server中尽量让服务器上所有资源都来运行Oracle服务。 \x0d\112、调整计算机系统中的内存配置 \x0d\多数 *** 作系统都用虚存来模拟计算机上更大的内存，它实际上是硬盘上的一定的磁盘空间。当实际的内存空间不能满足应用软件的要求时， *** 作系统就将用这部分的磁盘空间对内存中的信息进行页面替换，这将引起大量的磁盘I/O *** 作，使整个服务器的性能下降。为了避免过多地使用虚存，应加大计算机的内存。 \x0d\113、为Oracle数据库服务器设置 *** 作系统进程优先级 \x0d\不要在 *** 作系统中调整Oracle进程的优先级，因为在Oracle数据库系统中，所有的后台和前台数据库服务器进程执行的是同等重要的工作，需要同等的优先级。所以在安装时，让所有的数据库服务器进程都使用缺省的优先级运行。 \x0d\12、调整内存分配\x0d\Oracle数据库服务器保留3个基本的内存高速缓存，分别对应3种不同类型的数据：库高速缓存，字典高速缓存和缓冲区高速缓存。库高速缓存和字典高速缓存一起构成共享池，共享池再加上缓冲区高速缓存便构成了系统全程区(SGA)。SGA是对数据库数据进行快速访问的一个系统全程区，若SGA本身需要频繁地进行释放、分配，则不能达到快速访问数据的目的，因此应把SGA放在主存中，不要放在虚拟内存中。内存的调整主要是指调整组成SGA的内存结构的大小来提高系统性能，由于Oracle数据库服务器的内存结构需求与应用密切相关，所以内存结构的调整应在磁盘I/O调整之前进行。 \x0d\121、库缓冲区的调整 \x0d\库缓冲区中包含私用和共享SQL和PL/SQL区，通过比较库缓冲区的命中率决定它的大小。要调整库缓冲区，必须首先了解该库缓冲区的活动情况，库缓冲区的活动统计信息保留在动态性能表v$librarycache数据字典中，可通过查询该表来了解其活动情况，以决定如何调整。 \x0d\ \x0d\Select sum(pins),sum(reloads) from v$librarycache; \x0d\ \x0d\Pins列给出SQL语句，PL/SQL块及被访问对象定义的总次数；Reloads列给出SQL 和PL/SQL块的隐式分析或对象定义重装载时在库程序缓冲区中发生的错误。如果sum(pins)/sum(reloads) ≈0，则库缓冲区的命中率合适；若sum(pins)/sum(reloads)>1, 则需调整初始化参数 shared_pool_size来重新调整分配给共享池的内存量。 \x0d\122、数据字典缓冲区的调整 \x0d\数据字典缓冲区包含了有关数据库的结构、用户、实体信息。数据字典的命中率，对系统性能影响极大。数据字典缓冲区的使用情况记录在动态性能表v$librarycache中，可通过查询该表来了解其活动情况，以决定如何调整。 \x0d\ \x0d\Select sum(gets),sum(getmisses) from v$rowcache; \x0d\ \x0d\Gets列是对相应项请求次数的统计；Getmisses 列是引起缓冲区出错的数据的请求次数。对于频繁访问的数据字典缓冲区，sum(getmisses)/sum(gets)<10%～15%。若大于此百分数，则应考虑增加数据字典缓冲区的容量，即需调整初始化参数shared_pool_size来重新调整分配给共享池的内存量。 \x0d\123、缓冲区高速缓存的调整 \x0d\用户进程所存取的所有数据都是经过缓冲区高速缓存来存取，所以该部分的命中率，对性能至关重要。缓冲区高速缓存的使用情况记录在动态性能表v$sysstat中，可通过查询该表来了解其活动情况，以决定如何调整。 \x0d\ \x0d\Select name,value from v$sysstat where name in ('dbblock gets','consistent gets','physical reads'); \x0d\ \x0d\dbblock gets和consistent gets的值是请求数据缓冲区中读的总次数。physical reads的值是请求数据时引起从盘中读文件的次数。从缓冲区高速缓存中读的可能性的高低称为缓冲区的命中率，计算公式： \x0d\ \x0d\Hit Ratio=1-(physical reds/(dbblock gets+consistent gets)) \x0d\ \x0d\如果Hit Ratio<60%～70%，则应增大db_block_buffers的参数值。db_block_buffers可以调整分配给缓冲区高速缓存的内存量，即db_block_buffers可设置分配缓冲区高速缓存的数据块的个数。缓冲区高速缓存的总字节数=db_block_buffers的值db_block_size的值。db_block_size 的值表示数据块大小的字节数，可查询 v$parameter 表： \x0d\ \x0d\select name,value from v$parameter where name='db_block_size'; \x0d\ \x0d\在修改了上述数据库的初始化参数以后，必须先关闭数据库，在重新启动数据库后才能使新的设置起作用。

在开始演示之前，我们先介绍下两个概念。

概念一，数据的可选择性基数，也就是常说的cardinality值。

查询优化器在生成各种执行计划之前，得先从统计信息中取得相关数据，这样才能估算每步 *** 作所涉及到的记录数，而这个相关数据就是cardinality。简单来说，就是每个值在每个字段中的唯一值分布状态。

比如表t1有100行记录，其中一列为f1。f1中唯一值的个数可以是100个，也可以是1个，当然也可以是1到100之间的任何一个数字。这里唯一值越的多少，就是这个列的可选择基数。

那看到这里我们就明白了，为什么要在基数高的字段上建立索引，而基数低的的字段建立索引反而没有全表扫描来的快。当然这个只是一方面，至于更深入的探讨就不在我这篇探讨的范围了。

概念二，关于HINT的使用。

这里我来说下HINT是什么，在什么时候用。

HINT简单来说就是在某些特定的场景下人工协助MySQL优化器的工作，使她生成最优的执行计划。一般来说，优化器的执行计划都是最优化的，不过在某些特定场景下，执行计划可能不是最优化。

比如：表t1经过大量的频繁更新 *** 作，（UPDATE,DELETE,INSERT），cardinality已经很不准确了，这时候刚好执行了一条SQL，那么有可能这条SQL的执行计划就不是最优的。为什么说有可能呢？

来看下具体演示

譬如，以下两条SQL，

A：

select from t1 where f1 = 20;

B：

select from t1 where f1 = 30;

如果f1的值刚好频繁更新的值为30，并且没有达到MySQL自动更新cardinality值的临界值或者说用户设置了手动更新又或者用户减少了sample page等等，那么对这两条语句来说，可能不准确的就是B了。

这里顺带说下，MySQL提供了自动更新和手动更新表cardinality值的方法，因篇幅有限，需要的可以查阅手册。

那回到正题上，MySQL 80 带来了几个HINT，我今天就举个index_merge的例子。

示例表结构：

mysql> desc t1;+------------+--------------+------+-----+---------+----------------+| Field      | Type         | Null | Key | Default | Extra          |+------------+--------------+------+-----+---------+----------------+| id         | int(11)      | NO   | PRI | NULL    | auto_increment || rank1      | int(11)      | YES  | MUL | NULL    |                || rank2      | int(11)      | YES  | MUL | NULL    |                || log_time   | datetime     | YES  | MUL | NULL    |                || prefix_uid | varchar(100) | YES  |     | NULL    |                || desc1      | text         | YES  |     | NULL    |                || rank3      | int(11)      | YES  | MUL | NULL    |                |+------------+--------------+------+-----+---------+----------------+7 rows in set (000 sec)

表记录数：

mysql> select count() from t1;+----------+| count() |+----------+|    32768 |+----------+1 row in set (001 sec)

这里我们两条经典的SQL：

SQL C：

select from t1 where rank1 = 1 or rank2 = 2 or rank3 = 2;

SQL D：

select from t1 where rank1 =100  and rank2 =100  and rank3 =100;

表t1实际上在rank1,rank2,rank3三列上分别有一个二级索引。

那我们来看SQL C的查询计划。

显然，没有用到任何索引，扫描的行数为32034，cost为324365。

mysql> explain  format=json select from t1  where rank1 =1 or rank2 = 2 or rank3 = 2\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "324365"    },    "table": {      "table_name": "t1",      "access_type": "ALL",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "rows_examined_per_scan": 32034,      "rows_produced_per_join": 115,      "filtered": "036",      "cost_info": {        "read_cost": "323207",        "eval_cost": "1158",        "prefix_cost": "324365",        "data_read_per_join": "49K"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank1` = 1) or (`ytt``t1``rank2` = 2) or (`ytt``t1``rank3` = 2))"    }  }}1 row in set, 1 warning (000 sec)

我们加上hint给相同的查询，再次看看查询计划。

这个时候用到了index_merge,union了三个列。扫描的行数为1103，cost为44109，明显比之前的快了好几倍。

mysql> explain  format=json select /+ index_merge(t1) / from t1  where rank1 =1 or rank2 = 2 or rank3 = 2\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "44109"    },    "table": {      "table_name": "t1",      "access_type": "index_merge",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "union(idx_rank1,idx_rank2,idx_rank3)",      "key_length": "5,5,5",      "rows_examined_per_scan": 1103,      "rows_produced_per_join": 1103,      "filtered": "10000",      "cost_info": {        "read_cost": "33079",        "eval_cost": "11030",        "prefix_cost": "44109",        "data_read_per_join": "473K"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank1` = 1) or (`ytt``t1``rank2` = 2) or (`ytt``t1``rank3` = 2))"    }  }}1 row in set, 1 warning (000 sec)

我们再看下SQL D的计划：

不加HINT，

mysql> explain format=json select from t1 where rank1 =100 and rank2 =100 and rank3 =100\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "53434"    },    "table": {      "table_name": "t1",      "access_type": "ref",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "idx_rank1",      "used_key_parts": [        "rank1"      ],      "key_length": "5",      "ref": [        "const"      ],      "rows_examined_per_scan": 555,      "rows_produced_per_join": 0,      "filtered": "007",      "cost_info": {        "read_cost": "47884",        "eval_cost": "004",        "prefix_cost": "53434",        "data_read_per_join": "176"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank3` = 100) and (`ytt``t1``rank2` = 100))"    }  }}1 row in set, 1 warning (000 sec)

加了HINT，

mysql> explain format=json select /+ index_merge(t1)/ from t1 where rank1 =100 and rank2 =100 and rank3 =100\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "523"    },    "table": {      "table_name": "t1",      "access_type": "index_merge",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "intersect(idx_rank1,idx_rank2,idx_rank3)",      "key_length": "5,5,5",      "rows_examined_per_scan": 1,      "rows_produced_per_join": 1,      "filtered": "10000",      "cost_info": {        "read_cost": "513",        "eval_cost": "010",        "prefix_cost": "523",        "data_read_per_join": "440"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank3` = 100) and (`ytt``t1``rank2` = 100) and (`ytt``t1``rank1` = 100))"    }  }}1 row in set, 1 warning (000 sec)

对比下以上两个，加了HINT的比不加HINT的cost小了100倍。

总结下，就是说表的cardinality值影响这张的查询计划，如果这个值没有正常更新的话，就需要手工加HINT了。相信MySQL未来的版本会带来更多的HINT。

在进行软件开发过程中，数据库的使用是非常重要的，但是数据库有很多种，不同数据库的使用方法是不同的。进行软件开发过程中，至少需要掌握一种数据库的使用方法。SQL数据库语法简单、 *** 作方便和高效，是很多人最优的选择，但是SQL语句会受到不同数据库功能的影响，在计算时间和语言的效率上面需要进行优化，根据实际情况进行调整。下面电脑培训为大家介绍SQL数据库的优化方法。

一、适当的索引

索引基本上是一种数据结构，有助于加速整个数据检索过程。唯一索引是创建不重叠的数据列的索引。正确的索引可以更快地访问数据库，但是索引太多或没有索引会导致错误的结果。IT培训认为如果没有索引，处理速度会变得非常慢。

二、仅索引相关数据

指定需要检索数据的精度。使用命令和LIMIT代替SELECT。调整数据库时，必须使用所需的数据集而不是整个数据集，尤其是当数据源非常大时，指定所需的数据集，能够节省大部分时间。

三、根据需求使用或避免临时表

如果代码可以用简单的方式编写，那么永远不要使临时表变得复杂。当然，如果数据具有需要多个查询的特定程序，北大青鸟建议在这种情况下，使用临时表。临时表通常由子查询交替。

四、避免编码循环

避免编码循环是非常重要的，因为它会减慢整个序列的速度。通过使用具有单行的唯一UPDATE或INSERT命令来避免编码循环，并且回龙观北大青鸟发现WHERE命令能够确保存储的数据不被更新，这样能够方便在找到匹配和预先存在的数据时被找到。

以上就是关于如何对数据库备份进行性能优化全部的内容，包括:如何对数据库备份进行性能优化、谁知道数据库优化设计方案有哪些、oracle数据库优化有哪些方法等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！