当前位置：首页 > 实用文档 > 其他范文> 调优日志切换(Tuning Log Switches)数据库教程

调优日志切换(Tuning Log Switches)数据库教程

时间：2022-04-30 01:13:09 其他范文收藏本文下载本文

“G扇子”为你分享9篇“调优日志切换(Tuning Log Switches)数据库教程”，经本站小编整理后发布，但愿对你的工作、学习、生活带来方便。

篇1：调优日志切换(Tuning Log Switches)数据库教程

调优日志切换(Tuning Log Switches)

日志切换：LGWR进程停止写日志到当前日志文件，关闭日志文件，打开新的日志文件并写日志缓存中的数据到新的日志文件，

日志切换可以命令ALTER SYSTEM SWITCH LOGFILE或者ALTER SYSTEM ARCHIVE LOG来手工执行，也可以通过设置参数LOG_ARCHIVE_START使其自动执行。一般的原因是一个进程不能将生成的重做日志从缓存中写到当前的日志文件，因为已经使用到当前日志文件的最后一个数据块。

日志切换时做到的相关的步骤顺序：

1、执行一个控制文件事务来选择下一个日志文件以使用并清除控制文件入口。一般是选择当前带有最小日志序列号的日志文件来作为下一个使用，在这一步上，如果有必要，日志切换将会等待DBWR进程完全前面一个日志文件的日志切换的CHECKPOINT，等待ARCn进程完成归档。

2、使用redo copy latches和redo generation latches两个latch来阻止重做日志在日志缓存中生成（标记日志缓存状态），并将日志缓存中的数据写到日志文件（磁盘）中。如有可能用并行的方式，会同时将文件中最后一个记录的SCN号写到头数据块中（header block）。在这些“写”操作都完成之后LGWR进程关闭这个日志文件。

3、提升SCN值执行第二个控制文件事务来将日志文件标记为CURRENT，把之前的日志文件标记为ACTIVE，一旦DBWR进程完成了日志切换的CHECKPOINT后，这个文件的状态（之前的日志文件）会被标记为INACTIVE。如果数据库运行在归档模式下，LGWR进程通过控制文件中日志文件的入口段将这个日志文件（之前的日志文件）添加到归档连接单中，如果启动的是自动归档，LGWR会激活ARCn后台进程将这个日志文件进行归档。如果当前使用的所有ARCn进程都处于忙状态，LGWR会激活一个新的ARCn进程，ARCn进程数由参数log_archive_max_processes。

4、最后一步，LGWR进程打开新日志文件组的所有成员，并将新的日志序列号和底SCN写到头数据块（header block）。然后将日志缓存状态改为可以生成日志。

日志切换可能会花较长时间，经常是以秒记，日志切换过程有较大的调优潜力。相对于连续的缓慢的性能，OLTP系统的用户一般更难忍受数据库的间断的较差的性能，所以，减少日志切换频率，减少切换间隔时间是非常重要的。

在系统性能方面，日志切换冲突的主要表现在于log file switch completion等待事件上。如果日志切换性能差，另外一个等待事件log buffer space等待也会即刻产生。对日志切换调优就是要先调优log file switch completion等待事件然后是log buffer space等待。

使用大的日志文件：为了最小化日志切换频率，可以加大日志文件的SIZE（尽可能大，最易归档），也要控制CHECKPOINT（如设置参数fast_start_mttr_target）来使数据库恢复性能最优。

每个联机日志文件应该放在专有的磁盘上以免ARCn进程同时进入访问该磁盘。不要使用小的日志文件来保存磁盘空间，因为保存下来的空间不会再被使用（联机日志文件大小确定后是不会再增长的，所以不会用到您所保留下来的这些空间）

增加联机日志文件会提高归档的间隔时间。、

另外一方面，在使用了大的联机日志文件时，要通过调优归档以减少资源使用强度。

保持日志文件是打开状态：调整日志切换的速度最大的调优的潜在地方在于新日志文件成员的打开过程，打开新日志文件是用操作系统的指令open。如果有其他的一个进程在同一个文件中已经有打开文件的描述符则操作系统调用这个命令来打开新的日志文件的速度是很快的，主要原因是关于文件的一些信息都放在了系统的内核内存中。

下面这个脚本用于在实例启动时将日志文件的信息放到内核内存中，可以在一定的程度上提高日志切换的速度。这个是SHELL脚本，用于UNIX操作系统中，用CRON来定期每天实现：hold_logs_open.sh

###############################################################################

# Synopsis: hold_logs_open.sh instance

# Purpose: to hold the log files open to accelerate log switches

# Copyright: (c) Ixora Pty Ltd

# Author: Steve Adams with acknowledgements to Chris Bunting

###############################################################################

if [ $# -ne 1 ]

then

echo “Usage: hold_logs_open instance” >&2

exit 1

instance=$1

ORACLE_SID=$1

ORAENV_ASK=NO

. oraenv

fd=3

echo '

set pages 0 feedback off

select member from v$logfile;

prompt End-of-Files

' |

sqlplus -s internal |

while read logfile

if [ “$logfile” = End-of-Files ]

then

if [ “$fd” -gt 3 ]

then

sleep 86460 &

exit 0

eval “exec $fd<$logfile”

fd=`expr $fd + 1`

# Uncomment these lines if your shell only supports input redirection

# for single digit file descriptors.

# if [ “$fd” -eq 10 ]

# then

# sleep 86460 &

# fd=3

# fi

done

调整控制文件事务：每次日志切换都包含了两次控制文件事务，控制文件事务是在CF队列锁的保护下执行的，所以没有进一步的必要来控制控制文件的“写”操作，但是为了在控制文件事务期间的实例或者系统FAILURE的可恢复性，还是有必要进行一定的控制。

控制文件的可恢复性，首先写恢复结构到控制文件的第二个数据块，在写控制文件中的目标块时（控制文件事务所要写的块）等待其操作（恢复结构写操作）完成，因此，每个控制文件事务至少包含两个写I/O操作的等待。

如果使用的激活的控制文件是多个，则I/O操作会以串行的方式来实现。因此，要提高控制文件事务的性能就是要减少激活的控制文件数。在大多数情况下，可以只使用一个激活的控制文件，然后用硬件镜像及使用命令ALTER SYSTEM BACKUP CONTROLFILE TO TRACE来备份控制文件及保护控制文件。

下面的脚本（backup_controlfile.sql）提供了一种备份方案，主要在UNIX下实现，将控制文件的备份放到数据库的创建目录中：

trace_file_name.sql（获得跟踪文件名）

-------------------------------------------------------------------------------

-- Script.: trace_file_name.sql

-- Purpose: to get the name of the current trace file

-- Copyright: (c) Ixora Pty Ltd

-- Author: Steve Adams

-- Synopsis: @trace_file_name

-- OR

-- set termout off

-- @trace_file_name

-- set termout on

-- ... &Trace_Name ...

-- Description: This script. gets the name of the trace file for the current

-- session. It can be used interactively, or from other scripts.

-- The name is saved in the SQL*Plus define &Trace_Name.

-- There are three versions of the query below, because the trace

-- files are named differently depending on the platform. The

-- two incorrect versions should be commented out or deleted.

-------------------------------------------------------------------------------

column trace_file_name new_value Trace_Name

column trace_file_zipped new_value Trace_Zipped noprint

select

d.value || '/ora_' || p.spid || '.trc' trace_file_name,

d.value || '/ora_' || p.spid || '.trc.gz' trace_file_zipped

from

( select

p.spid

from

sys.v_$mystat m,

sys.v_$session s,

sys.v_$process p

where

m.statistic# = 1 and

s.sid = m.sid and

p.addr = s.paddr

) p,

( select

value

from

sys.v_$parameter

where

name = 'user_dump_dest'

) d

select

d.value||'/'||lower(rtrim(i.instance, chr(0)))||'_ora_'||p.spid||'.trc' trace_file_name,

d.value||'/'||lower(rtrim(i.instance, chr(0)))||'_ora_'||p.spid||'.trc.gz' trace_file_zipped

from

( select

p.spid

from

sys.v_$mystat m,

sys.v_$session s,

sys.v_$process p

where

m.statistic# = 1 and

s.sid = m.sid and

p.addr = s.paddr

) p,

( select

t.instance

from

sys.v_$thread t,

sys.v_$parameter v

where

v.name = 'thread' and

(

v.value = 0 or

t.thread# = to_number(v.value)

)

) i,

( select

value

from

sys.v_$parameter

where

name = 'user_dump_dest'

) d

select

d.value || 'ora' || lpad(p.spid, 5, '0') || '.trc' trace_file_name,

d.value || 'ora' || lpad(p.spid, 5, '0') || '_trc.gz' trace_file_zipped

from

( select

p.spid

from

sys.v_$mystat m,

sys.v_$session s,

sys.v_$process p

where

m.statistic# = 1 and

s.sid = m.sid and

p.addr = s.paddr

) p,

( select

value

from

sys.v_$parameter

where

name = 'user_dump_dest'

) d

clear columns

backup_controlfile.sql

-------------------------------------------------------------------------------

-- Script.: backup_controlfile.sql

-- Purpose: to save a create controlfile statement

-- Copyright: (c) Ixora Pty Ltd

-- Author: Steve Adams

-- Description: This script. uses the backup controlfile to trace command to

-- save a create controlfile statement, and then moves the trace

-- file into the APT create directory.

-- The SQL*Plus connection is closed, because its trace file has

-- been moved.

-------------------------------------------------------------------------------

alter database backup controlfile to trace

set termout off

@trace_file_name

set termout on

disconnect

host mv &Trace_Name $CREATE/create_controlfile.sql

exit

自www.ixor.com.au

篇2：有关日志压缩数据库教程

压缩

SET QUOTED_IDENTIFIER OFF

SET ANSI_NULLS OFF

CREATE PROCEDURE strink_logspace

SET NOCOUNT ON

DECLARE @LogicalFileName sysname,

@MaxMinutes INT,

@NewSize INT

SELECT @LogicalFileName = rtrim(name),

@MaxMinutes = 10, -- 最大执行时间

@NewSize = 10 -- 最小空间

from sysfiles where status & 0x40 = 0x40

-- Setup / initialize

DECLARE @OriginalSize int

SELECT @OriginalSize = size -- in 8K pages

FROM sysfiles

WHERE name = @LogicalFileName

SELECT db_name() +'日志原始大小' +

CONVERT(VARCHAR(30),@OriginalSize) + ' pages/ 8K 或 ' +

CONVERT(VARCHAR(30),(@OriginalSize*8/1024)) + 'MB'

FROM sysfiles

WHERE name = @LogicalFileName

CREATE TABLE DummyTrans

(DummyColumn char (8000) not null)

-- Wrap log and truncate it.

DECLARE @Counter INT,

@StartTime DATETIME,

@TruncLog VARCHAR(255)

SELECT @StartTime = GETDATE(),

@TruncLog = 'BACKUP LOG ['+ db_name() + '] WITH TRUNCATE_ONLY'

-- Try an initial shrink.

DBCC SHRINKFILE (@LogicalFileName, @NewSize)

EXEC (@TruncLog)

-- Wrap the log if necessary.

WHILE @MaxMinutes > DATEDIFF (mi, @StartTime, GETDATE()) -- time has not expired

AND @OriginalSize = (SELECT size FROM sysfiles WHERE name = @LogicalFileName) -- the log has not shrunk

AND (@OriginalSize * 8 /1024) > @NewSize -- The value passed in for new size is smaller than the current size.

BEGIN -- Outer loop.

SELECT @Counter = 0

WHILE ((@Counter < @OriginalSize / 16) AND (@Counter < 50000))

BEGIN -- update

INSERT DummyTrans VALUES ('Fill Log') -- Because it is a char field it inserts 8000 bytes.

DELETE DummyTrans

SELECT @Counter = @Counter + 1

END -- update

EXEC (@TruncLog) -- See if a trunc of the log shrinks it.

END -- outer loop

DBCC SHRINKFILE (@LogicalFileName, @NewSize)

SELECT db_name() +'日志最后大小' +

CONVERT(VARCHAR(30),size) + ' pages/ 8K 或 ' +

CONVERT(VARCHAR(30),(size*8/1024)) + 'MB'

FROM sysfiles

WHERE name = @LogicalFileName

DROP TABLE DummyTrans

PRINT '*** 数据库日志压缩成功 ***'

SET NOCOUNT OFF

SET QUOTED_IDENTIFIER OFF

SET ANSI_NULLS ON

--used

exec strink_logspace

篇3：浅析SQL Server数据库的性能优化性能调优

在一个大型的数据库中，性能成为人们关注的焦点之一，如何让数据库高效有效的运行成为广大数据库管理人员和开发人员必须要考虑的问题，性能是一个应用或多个应用在相同的环境下运行时对效率的衡量。性能常用响应时间和工作效率来表示。响应时间是指完成一个任务花费的时间，可以从以下三方面来减少响应时间：

· 减少竞争和等待的次数，尤其是磁盘读写等待次数

· 利用更快的部件

· 减少利用资源所需的时间

绝大多数性能的获得来自于优秀的数据库设计、精确的查询分析和适当的索引。最好性能的获得能够通过确立优秀的数据库设计，在开发时学会使用SQL Server查询优化器来实现。

为了取得更好的数据库性能，我们就需要对数据库进行优化，减少系统资源的竞争，如对数据cache，过程cache，系统资源和CPU的竞争。

在SQL Server中，有如下优化层次：

·应用层——大部分性能的获得来自于对你的SQL应用中查询的优化，这必须是以好的数据库设计为基础的。

·数据库层——应用共享在数据库层中的资源，这些资源包括硬盘，事务日志和数据cache。

·服务器层——在服务器层有许多共享的资源，包括数据高速缓存，过程高速缓存，锁，CPU等。

·设备层——指的是存储数据的磁盘及其控制器，在这一层，你应尤其关注磁盘的I/O。

·网络层——指连接用户和SQL Server的网络。

·硬件层——指可利用的CPU。

·操作系统层——理想地，SQL Server是一台机器的唯一主要应用，它必须和操作系统以及其他sybase软件，如Backup Server或SQL Server Monitor共享处理器、内存以及其他资源。

在大多数情况下面，我们是对应用层进行优化，，因为对应用性能的优化是大家最乐于接受的功能，其结果能被观测及检验，查询的性能是SQL应用的整个性能的一个关键。

应用层上的问题包括以下内容：

·决策支持VS.和在线事务处理(OLTP)需要不同的性能策略

·事务设计能够减少并发，因为长的事务保持占用锁，也就减少了其他用户对相关数据的存取

·关联一致性对数据修改需要join操作

·支持Select操作的索引增加了修改数据的时间

·为了安全而设立的审计限制了性能

在应用层优化的选项包括：

·远程处理或复制处理能够把决策支持从OLTP机器中分离出来

·利用存储过程来减少编译时间和网络的利用

·利用最少量的锁去满足你的应用需要

数据库层的问题包括：

·建立备份和恢复方案

·在设备上分布存储数据

·审计操作影响性能;仅审计你所需的

·日常的维护活动将导致性能的降低和导致用户不能操作数据库表

在数据库层上优化选择包括：

·利用事务日志的阀值来自动转储事务日志防止其超出使用空间

·在数据段中用阀值来监视空间的使用

·利用分区来加速数据的装入

·对象的定位以避免硬盘的竞争

·把重要表和索引放入cache中，保证随时取得

服务器层的问题有：

·应用的类型——服务器是支持OLTP还是DSS，或者两者都支持

·所支持的用户数影响优化决策——随着用户数的增加，对资源的竞争会发生改变

关键字：MYSQL

篇4：SQL Server数据库性能优化技巧性能调优

设计1个应用系统似乎并不难，但是要想使系统达到最优化的性能并不是一件容易的事，在开发工具、数据库设计、应用程序的结构、查询设计、接口选择等方面有多种选择，这取决于特定的应用需求以及开发队伍的技能。本文以SQL Server为例，从后台数据库的角度讨论应用程序性能优化技巧，并且给出了一些有益的建议。

1 数据库设计

要在良好的SQL Server方案中实现最优的性能，最关键的是要有1个很好的数据库设计方案。在实际工作中，许多SQL Server方案往往是由于数据库设计得不好导致性能很差。所以，要实现良好的数据库设计就必须考虑这些问题。

1.1 逻辑库规范化问题

一般来说，逻辑数据库设计会满足规范化的前3级标准：

1.第1规范：没有重复的组或多值的列。

2.第2规范：每个非关键字段必须依赖于主关键字，不能依赖于1个组合式主关键字的某些组成部分。

3.第3规范：1个非关键字段不能依赖于另1个非关键字段。

遵守这些规则的设计会产生较少的列和更多的表，因而也就减少了数据冗余，也减少了用于存储数据的页。但表关系也许需要通过复杂的合并来处理，这样会降低系统的性能。某种程度上的非规范化可以改善系统的性能，非规范化过程可以根据性能方面不同的考虑用多种不同的方法进行，但以下方法经实践验证往往能提高性能。

1.如果规范化设计产生了许多4路或更多路合并关系，就可以考虑在数据库实体(表)中加入重复属性(列)。

2.常用的计算字段(如总计、最大值等)可以考虑存储到数据库实体中。

比如某一个项目的计划管理系统中有计划表，其字段为：项目编号、年初计划、二次计划、调整计划、补列计划…，而计划总数(年初计划+二次计划+调整计划+补列计划)是用户经常需要在查询和报表中用到的，在表的记录量很大时，有必要把计划总数作为1个独立的字段加入到表中。这里可以采用触发器以在客户端保持数据的一致性。

3.重新定义实体以减少外部属性数据或行数据的开支。相应的非规范化类型是：

(1)把1个实体(表)分割成2个表(把所有的属性分成2组)。这样就把频繁被访问的数据同较少被访问的数据分开了。这种方法要求在每个表中复制首要关键字。这样产生的设计有利于并行处理，并将产生列数较少的表。

(2)把1个实体(表)分割成2个表(把所有的行分成2组)。这种方法适用于那些将包含大量数据的实体(表)。在应用中常要保留历史记录，但是历史记录很少用到。因此可以把频繁被访问的数据同较少被访问的历史数据分开。而且如果数据行是作为子集被逻辑工作组(部门、销售分区、地理区域等)访问的，那么这种方法也是很有好处的。

1.2 生成物理数据库

要想正确选择基本物理实现策略，必须懂得数据库访问格式和硬件资源的操作特点，主要是内存和磁盘子系统I/O。这是一个范围广泛的话题，但以下的准则可能会有所帮助。

1.与每个表列相关的数据类型应该反映数据所需的最小存储空间，特别是对于被索引的列更是如此。比如能使用smallint类型就不要用integer类型，这样索引字段可以被更快地读取，而且可以在1个数据页上放置更多的数据行，因而也就减少了I/O操作。

2.把1个表放在某个物理设备上，再通过SQL Server段把它的不分簇索引放在1个不同的物理设备上，这样能提高性能。尤其是系统采用了多个智能型磁盘控制器和数据分离技术的情况下，这样做的好处更加明显。

3.用SQL Server段把一个频繁使用的大表分割开，并放在2个单独的智能型磁盘控制器的数据库设备上，这样也可以提高性能。因为有多个磁头在查找，所以数据分离也能提高性能。

4.用SQL Server段把文本或图像列的数据存放在1个单独的物理设备上可以提高性能。1个专用的智能型的控制器能进一步提高性能。

2 与SQL Server相关的硬件系统

与SQL Server有关的硬件设计包括系统处理器、内存、磁盘子系统和网络，这4个部分基本上构成了硬件平台，Windows NT和SQL Server运行于其上。

2.1 系统处理器(CPU)

根据自己的具体需要确定CPU结构的过程就是估计在硬件平台上占用CPU的工作量的过程

关键字：MYSQL

篇5：如何修改MySQL日志文件位置?数据库教程

MySQL日志文件相信大家都有很多的了解，MySQL日志文件一般在:/var/log/mysqld.log，下面就教您修改MySQL日志文件位置的方法，供您参考，

今天需要改MySQL日志文件的位置，发现在/etc/my.cnf中怎么也改不了。

后来发现MySQL日志位是指定的:

[root@localhost etc]# ps auxgrep mysqld

root 11830 0.5 0.0 4524 1204 pts/0 S 03:03 0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/data/mysql --socket=/var/lib/mysql/mysql.sock --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid

mysql 11890 3.7 0.1 40456 9076 pts/0 Sl 03:03 0:00 /usr/libexec/mysqld --basedir=/usr --datadir=/data/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --port=3306 --socket=/var/lib/mysql/mysql.sock

root 11909 0.0 0.0 3908 664 pts/0 S+ 03:03 0:00 grep mysqld

chkconfig --list发现是chkconfig on指定的，天是

vim /etc/init.d/mysqld得知这里的已经配置

get_mysql_option mysqld datadir “/var/lib/mysql”

datadir=“$result”

get_mysql_option mysqld socket “$datadir/mysql.sock”

socketfile=“$result”

get_mysql_option mysqld_safe log-error “/var/log/mysqld.log”

errlogfile=“$result”

get_mysql_option mysqld_safe pid-file “/var/run/mysqld/mysqld.pid”

mypidfile=“$result”

更改这里应该就行了

篇6：MS Sql Server 日志清理数据库教程

server

SET NOCOUNT ON

DECLARE @LogicalFileName sysname,@MaxMinutes INT,@NewSize INT

USE grades -- 要操作的数据库名

SELECT @LogicalFileName = 'grades_log', -- 日志文件名

@MaxMinutes = 10, -- Limit on time allowed to wrap log.

@NewSize = 1 -- 你想设定的日志文件的大小(M)

-- Setup / initialize

DECLARE @OriginalSize int

SELECT @OriginalSize = size FROM sysfiles WHERE name = @LogicalFileName

SELECT 'Original Size of ' + db_name + ' LOG is ' +

CONVERT(VARCHAR(30),@OriginalSize) + ' 8K pages or ' +

CONVERT(VARCHAR(30),(@OriginalSize*8/1024)) + 'MB'

FROM sysfiles

WHERE name = @LogicalFileName

CREATE TABLE DummyTrans(DummyColumn char (8000) not null)

DECLARE @Counter INT,@StartTime DATETIME,@TruncLog VARCHAR(255)

SELECT @StartTime = GETDATE(),@TruncLog = 'BACKUP LOG ' + db_name() + ' WITH TRUNCATE_ONLY'

DBCC SHRINKFILE (@LogicalFileName, @NewSize)

EXEC (@TruncLog)

-- Wrap the log if necessary.

WHILE @MaxMinutes > DATEDIFF (mi, @StartTime, GETDATE()) -- time has not expired

AND @OriginalSize = (SELECT size FROM sysfiles WHERE name = @LogicalFileName)

AND (@OriginalSize * 8 /1024) > @NewSize

BEGIN -- Outer loop.

SELECT @Counter = 0

WHILE ((@Counter < @OriginalSize / 16) AND (@Counter < 50000))

BEGIN -- update

INSERT DummyTrans VALUES ('Fill Log')

DELETE DummyTrans

SELECT @Counter = @Counter + 1

END

EXEC (@TruncLog)

END

SELECT 'Final Size of ' + db_name() + ' LOG is '+

CONVERT(VARCHAR(30),size) + ' 8K pages or ' +

CONVERT(VARCHAR(30),(size*8/1024)) + 'MB'

FROM sysfiles

WHERE name = @LogicalFileName

DROP TABLE DummyTrans

SET NOCOUNT OFF

篇7：用脚本缩小数据库日志数据库教程

脚本|数据|数据库

因为客户使用的数据库时常因为日志过大而导致硬盘空间不够，或者备份出来的文件太大无法通过邮件传送，

闲下有余，参考SQLSERVER的帮助文件，写了如下脚本，可以截断日志，以达到缩小文件的目的。有空大家可以在自己的SQLSERVER上测试下效果哦。。。：）也许对有些情况导致的日志过大没有作用，这点可以同各位同仁互相交流下。

--在MASTER数据库中执行以下脚本（使用查询分析器）

declare @dbname varchar(50)

declare temp_cur cursor scroll for select name from sysdatabases

open temp_cur

fetch first from temp_cur into @dbname

while @@fetch_status =0

begin

exec ('backup log '+@dbname+' with no_log')

exec ('dbcc shrinkdatabase('+@dbname+')')

exec ('dbcc checkcatalog ('+@dbname+')')

exec ('dump transaction '+@dbname+' with no_log')

fetch next from temp_cur into @dbname

end

close temp_cur

deallocate temp_cur

篇8：如何用hash关键字提高数据库性能性能调优

普通的SQL Server应用程序要求支持一个或几个长字符串搜索，（本文中，我们称超过20个字符的字符串为长字符串。）假如前端应用程序希望允许用户提供两个字符串；你启动一个执行这两个字符串搜索任务的存储程序，然后应用两个相关列目录对搜索进行优化。在小型的表格中，你可能注意不到产生的效果。但是，如果表格包含5 000万行，它就会影响存储程序与搜索性能。

应用称为hash关键字（引用单独一个hash）或hash桶（一个hash关键字集合）的字符串目录的优秀方法可大大节省磁盘空间并提高性能。

何为hash（hash）

hash是应用一个指定字符串算法的整数结果。有各式各样的hash算法，但最常用的是内置的SQL函数Checksum。通常，你给这个函数一个字符串，它就返回一个整数（在大型表格中，我们不能保证这个整数的唯一性）。

数据库设计中的hash表格

假设在我们感兴趣的表格中有这些列：

列名

数据类型

名称

Varchar(50)

组名称

Varchar(50)

这两个列的多列目录每行会耗用50+50个字符，加上上面提到的5 000万行，这可是个相当大的难题。

基于这两个列的hash关键字相当的小，即每行四个字节。如果我们不将hash关键字存储在这一列的目录中，它还会更小。相反，我们应该建立一个计算列，该列的公式是这两个列的hash关键字，然后将那个列编入目录并忽视字符串对的目录。

用户（不管是人还是应用程序）查询感兴趣的值；然后我们将参数转换为hash关键字并搜索hash目录。副本集合要比引擎必须访问的行集合小得多，以便对查询值进行精确匹配。然后将hash关键字搜索与两个感兴趣的列的比较结合起来，隔离出一个小型的行子集，并对两个列进行检验，找出匹配值。基于整数列的搜索比基于长字符串关键字的搜索要快得多，同样也比复合关键字搜索快得多。

应用Checksum函数作hash关键字运算

尝试运行这段样本代码，它表明如何获得指定值或值组合的hash关键字：

USE AdventureWorks

SELECT Name, GroupName, Checksum(Name,GroupName)AS HashKey

FROM Adventureworks.HumanResources.Department

ORDER BY HashKey

所得的结果显示在下表中（为求简洁，只选用了10个结果）。

名称

组名称

hash关键字

工具设计

研究与开发