下面是小编为大家收集的sybase数据库性能调整，本文共3篇，仅供参考，欢迎大家阅读，一起分享。
篇1：sybase数据库性能调整
数据库性能调优的一些小方面:
1．1 性能指标
数据库性能一般用两个方面的指标来衡量：响应时间和吞吐量，响应越快，吞吐量越大，数据库性能越好。响应时间和吞吐量有些情况下不能一起得到改善。 1．2 调优级别
对Sybase数据库性能调优，可以从四个方面进行：
一) 操作系统级：对网络性能、操作系统参数、硬件性能等作改进。
二) SQL Server级：调整存取方法，改善内存管理和锁管理等。
三) 数据库设计级：采用降范式设计，合理设计索引，分布存放数据等。
四) 应用程序级：采用高效SQL语句，合理安排事务，应用游标，处理锁。
本文对第一、第三、第四方面的内容不做讨论，第二方面提到的概念只适用于Sybase数据库。
1．3 调优工具
在分析Sybase数据库的性能时，要用到一些数据库系统本身提供的性能调优工具，包括几个系统存储过程：
名称 功能简要介绍
sp_sysmon 企业级系统性能报告工具
sp_lock 查看锁的情况
sp_who 查看线程的活动情况
sp_procqmode 存储过程的查询处理模式
sp_configure 配置SQL Server系统级参数
sp_estspace 估计创建一个表需要的空间和时间
sp_spaceused 估计表的总行数及表和索引占用的空间
sp_monitor 监视CPU、I/O的统计活动情况
在利用isql等一些工具时，还可以设置查询会话中的几个选项，来显示SQL语句执行时的各种统计分析结果：
指令 On 的含义
set noexec on/off 分析SQL语句后，还要执行
set statistics io on/off 统计SQL执行所需I/O
set statistics time on/off 统计SQL语句执行耗时
set showplan on/off 显示查询计划
1．4 sp_sysmon 的使用
企业级性能报告工具、系统存储过程 sp_sysmon 的使用方法：
在isql 下，首先输入 sp_sysmon 'begin_sample' 启动一个报告采样过一段时间后，再输入 sp_sysmon 'end_sample' 结束上次报告采样
或者紧跟一参数 sp_sysmon 'end_sample', “dcache” 结束上次报告采样， 但只显示数据缓冲（Data Cache Management）这一部分的情况。
能替换dcache的可选参数如下表所示：
参数 参数全称，内容范围解释
Dcache Data Cache Management，数据缓冲
Kernel Kernel Utilization，有关引擎、网络和I/O等情况
Wpm Worker Process Management
Parallel Parallel Query Management
Taskmgmt Task Management
Appmgmt Application Management
Esp ESP Management
Housekeeper Housekeeper Task Activity
Monaccess Monitor Access to Executing SQL
Xactsum Transaction Profile
Xactmgmt Transaction Management
Indexmgmt Index Management，索引管理
Mdcache Metadata Cache Management
Locks Lock Management，锁管理
Pcache Procedure Cache Management
Memory Memory Management
Recovery Recovery Management
Diskio DiskI/OManagement，磁盘I/O管理
Netio NetworkI/OManagement
1．5
用sp_sysmon可以得到数据库系统的性能基准报告，但要在比较稳定的状态下产生，方可作为参考和对照的依据。
1．6 理解存储方法
只有清楚数据库存储数据的底层细节，如数据页、索引页的物理结构，每一行的大小计算，不同类型列占用的宽度等等问题，才能对各种调优措施有个深入领会。关于这个问题，比较复杂和细致，请自行参阅有关书籍。
一般地，对于更改数据的操作，要尽量促进数据库进行直接更新（ Direct Updates ），所以要遵守以下几条原则：
1）除非必要，避免使用允许null值的列和可变长度的列。
2）如果varchar 和 varbinary 列填充得比较满，毫不犹豫转成 char 和 binary 列。对于建表时指定的页填充率（page fillfactor）参数，要权衡确定数值大小。一般：小值，适合于有许多随机插入的表，该表的数据经常被删除，又经常被增加；大值，适合于大多数的数据被增加到表末尾，如客票系统的售票存根和退票存根表。
2 SQL Server级的调优
2．1 管理共享内存
数据库性能优化的首要方面是最优管理内存。数据库占用的共享内存分成数据缓冲（data cache）、存储过程缓冲（Procedure cache）等几块。在isql 下使用 sp_configure 'cache' 可以看到存储过程缓冲所占百分比（procedure cache percent），整个数据缓冲大小（total data cache size） 等参数。
2．1．1 存储过程缓冲（Procedure cache）
存储过程缓冲保持以下对象的查询计划：
Procedures ：存储过程
Triggers ：触发器
Views ：视图
Rules ：规则
Defaults ：缺省
Cursors ：游标
存储过程不可重入，意即每个并发用户调用都会在内存中产生一个拷贝。
Procedure, triggers, and views 当它们被装载到procedure cache中时，被查询优化器优化，建立查询计划。如果存储过程在缓冲中，被调用时就不需要重新编译。如果procedure cache太小，存储过程就会经常被其他调入内存的存储过程冲洗掉，当再次被调用时，存储过程又被调入内存，再重新编译，用户请求因此不得不等待。最严重的情况，如果procedure cache不够，存储过程甚至都不能运行。所以在内存足够的情况下，procedure cache percent 参数尽可能大一些。
2．1．2 数据缓冲（Data Cache）
数据缓冲用来缓存数据页和索引页，是除去存储过程缓冲，系统其他占用的缓冲外的剩余内存空间。通过给服务器增加物理内存扩大数据缓冲，是最有效的方法。当然，如果不能加内存，就只能通过减少存储过程缓冲的比例等方法来扩大数据缓冲了。通过 sp_configure “extentI/Obuffers”, 20（可调） 命令，在Data Cache中保留一些页专用于创建索引时使用，可以显著提高创建索引的性能。但要注意每开辟一个缓冲占用16K 字节的系统内存。
2．1．3 命名缓冲
通过如下的命令：
1>sp_helpcache
2>go
查看某客票数据库中命名缓冲，得到的结果如下：
Cache Name Config Size Run Size Overhead
------------------------ ------------- ---------- ----------
DS30_Tran_Log 20.00 Mb 20.00 Mb 2.05 Mb
Systemtable 20.00 Mb 20.00 Mb 2.05 Mb
default data cache 0.00 Mb 4462.86 Mb 464.97 Mb
left_base_center 16.00 Mb 16.00 Mb 1.57 Mb
price_cache 8.00 Mb 8.00 Mb 0.85 Mb
可以看出有4个命名缓冲，分别绑定客票系统的应用日志表、一些重要且常用的系统表、余票表、票价系列表，另外1个是缺省数据缓冲。这种配置还不是最合理，应该进一步把Systemtable这个命名缓冲细分成很多个，每一个单独存放一张系统表。
2．1．4 缓冲策略
缓冲策略是指把数据提前读入内存的机制，分预取策略(Prefetch rategy，即大I/O策略)和取后马上丢弃策略(Fetch-and-Discard)、提示策(Hints)等几种。可以在三个级别上设置表数据的预取策略(Prefetch Strategy，即大I/O策略)于：对象级，会话级，查询级。如果三个级别上都有设置，它们发生作用的优先顺序是：对象级 >会话级 >查询级。对于如何在查询级利用指定的缓冲池，可以查看下面例子（使用4K缓冲池）：
select au_fname, au_lname
from authers (prefetch 4)
where au_id in ( A37631, ..., A1887081515 )
go
DSS应用往往得益于大的I/O，应该放开largeI/Ostrategy预取策略。
如果一个应用倾向于OLTP特征，用户能在会话级关掉Prefetch来提高性能。对于OLTP应用，关闭largeI/Ostrategy预取策略。对于所取到的页不会有重用的情况，放开fetch-and-discard策略。客票系统对存根数据进行统计的应用，如财收日结账，营销分析数据整理模块和综合查询等，都可以利用这一结论。查看几个操作频繁且较大的表上的缓冲策略，用如下命令：
sp_cachestrategy center,seat_area
sp_cachestrategy center,sale_record0505
2．2 管理锁
2．2．1 页锁升级阀限
优化锁的重要考虑是设置页级锁升级升级成表级锁的阀限，
要尽量避免页锁很快升级成表级锁。在某客票数据库中，用sp_configure ‘lock’可以看到如下结果：
deadlock checking period 500 0 1000 1000
number of locks 5000 46875 00 200000
page lock promotion HWM 200 0 10000 10000
page lock promotion LWM 200 0 200 200
page lock promotion PCT 100 0 90 90
可以看到页锁升级的阀限有三个：HWM（最高点） 为10000，LWM（最低点）为200，PCT为90。Sybase数据库内部根据PCT值按公式PCT*TAB_SZ/100得出计算阀限，如果计算阀限 < LWM, 锁升级发生在LWM值；如果计算阀限 < HWM，锁升级发生在HWM值。如果 LWM < 计算阀限 < HWM ，锁升级发生在PCT*TAB_SZ/100值。
锁升级阀限设置分对象级和服务器级两种。
针对对象级设置（数据库上的表或表上的索引），配置命令是：
sp_setpglockpromote {“database” | “table”}, objname, new_lwm,new_hwm, new_pct
针对服务器级设置，配置命令是：
sp_setpglockpromote server, NULL, new_lwm, new_hwm, new_pct。
如果要删除掉对象级上的页锁升级阀限，用：
sp_dropglockpromote {“database” | “table”}, objname
2．2．2 减少锁争夺的方法：
1）降范式设计数据库，创建冗余表。
2）把堆表（没有聚族索引的表）分区。
3）对于小表，使用fillfactor和max_rows_per_page来减少行密度，从而使各行数据分布到许多页（此方法适用于SQL Server 11版，对于11.9.2版以后的Sybase数据，有了行级锁，此方法必要性不大）。
2．3 管理临时库(tempdb)
管理临时库一个重要原则是要避免临时表跨多个设备，可以把tempdb从master设备中分离出来，放到一个单独的设备上去。这样可以减少存取系统表时对I/O资源的争夺。用sp_dropsegment 存储过程从master设备中移除tempdb的default段和system段。为了进一步提高tempdb的I/O速度，可以考虑把tempdb整个放在RAM 驱动器或固态存储设备上，存取速度是一般磁盘的1000倍。一般情况下，tempdb会非常频繁地争夺和占用缺省数据缓冲，因为查询会话中有许多临时表要创建、计算和删除。所以推荐把tempdb绑定到它自己的命名缓冲，这样可以防止临时对象在内存中的活动冲洗掉缺省数据缓冲中的其他对象，利于在多个缓冲间展开I/O。在使用临时表的时候，还有一个原则：尽量缩小表规模和行的宽度，每一行只包括必要的列。例如在用select * into生成临时表时，如果只需要几个列的数值，就不要用这样的语句，而直接选取需要的列。
2．4 使用多引擎（Multiple Network Engines）
如果操作系统使用了多个CPU，那么用sp_configure 配置数据库的参数：在线引擎数(max online engines)，可以扩展系统的网络I/O容量，分布网络I/O到各个引擎，从而提高性能，允许更多的用户连接。
在用户登录数据库时，总是先登录到引擎0，由引擎0在可用引擎队列中选择一个挂最少连接的引擎来传递socket描述符，从而重定向连接到那个引擎，由该引擎去处理跟此用户连接相关的所有网络活动。
对于多引擎SMP结构，SQL Server引入了自旋锁(spinlock)的一种数据结构，在多个引擎间共享。对于不同类型的任务，在哈希表上分配不同的自旋锁，有页锁自旋锁、表锁自旋锁和地址自旋锁。
自旋锁的配置：
sp_configure “page lock spinlock ratio”, newval
sp_configure “table lock spinlock ratio”, newval
sp_configure “address lock spinlock ratio”, newval
增大数值，可以减少碰撞，提高并发操作度。但是每一个自旋锁结构要占用256字节的内存。
如果数据库发生1279错，可能原因：
1）不允许足够的锁，解决办法是用sp_configure 调大 number of locks 数值
2）在engine freelock 缓冲中没有足够的锁，解决办法是用sp_configure调大 max engine freelocks 数值。
如果数据库系统使用了4个引擎，那么每个引擎的自由锁缓冲中包含：each engine-specific freelock cache 包含 5000 * .20 /4 = 250 个锁。
在平时，经常用sp_monitor和sp_sysmon监视CPU使用率，如果所有CPU的利用率高于85%，增加CPU，然后增大数据库的引擎数，可以改善性能。
2．5 设备使用的优化
把最常插入的表分区，放在多个设备上，这样可以创建多个页链，从而改善多个并发插入时的性能，因为每一个插入都要找到页链，页链有多个，就允许多个插入同时进行。这一点，尤其适用于客票系统的存根表和订票存根表（CG30_RRT），所带来的性能改善会非常明显。
物理I/O的代价远大于逻辑I/O，所以要尽量减少磁盘进行物理I/O的次数，尽量多进行内存中的逻辑I/O。使用statistics io工具和sp_sysmon，来观察磁盘I/O。可以配置使用大的I/O来减少物理I/O的次数，方法有三个：
1）用更多的磁盘；
2）表和索引分开到不同的磁盘；
3）增加一次I/O系统参数值的大小。
SQL Server总是为I/O请求建立一个磁盘检查的调度环，用sp_configure “I/O polling process count”来提高数值，加长环，可以降低引擎的检查次数，提高吞吐量。但较小的值一般有助于减少响应时间。
对于可用的磁盘I/O控制块，要查看操作系统文档，用sp_configure “diskI/Ostructures”配置，这个数值要尽可能高。
分离日志和数据，到不同的设备；给tempdb自己的设备；分离表和索引到不同的设备。这些方法都可以减少I/O。
2．6 对事务处理的调优
2．6．1 事务类型
事务处理无外乎三种：1,OLTP; 2, DSS; 3, OLTP + DSS 的混合负载
OLTP（联机事务处理）的特点：
数据插入、修改和删除频繁。
经常操作的是单个记录。
当不适当设计时，倾向于碰撞和冲突。
DSS（决策支持系统）的特点：
数据修改不太频繁。
如果有插入和删除，是大批量的。
平时一般是只读操作。
表连接很常见。
有比较特别的查询。
OLTP + DSS 混合负载的特点权衡：
在性能方面要比较，是要吞吐量还是响应时间。
在锁方面要比较，是要并发性强呢还是要数据一致性强。
2．6．2 事务管理原则
一般的事务管理原则有：
1) 分解大的事务成多个小的事务。如客票数据的备份操作中，要删除过期数据，如果设计小事务做循环，便不会影响应用，完全可以做到任何时候备份和删除，不一定非得等服务器闲的时候做。
2) 避免在单个事务中更新或删除大量的数据行。比如客票系统的席位库数据清理，即使在服务器闲的时候做这种操作，也会锁定整个表，影响售票。
3) 尽量用可以接受的最低孤立级(isolation level)，来提高并发度。如在余票查询等功能的应用中，使用这种孤立级，便可以最大程度地降低对售票的影响。
4) 提高事务吞吐量的措施包括：避免延迟更新；尽可能使用存储过程等等。
2．6．3 跟事务特征相关的数据库可调参数或特性
相对于OLTP应用，SQL Server有一些特性来满足要求。
1) 命名缓冲（Named cache）
对于命名缓冲，可以配置多个不同大小的内存池，来满足不同的应用需求。对于多个引擎的情况，命名缓冲还有一项重要的功能是降低自旋锁的内部争夺。
2) 日志I/O缓冲大小可配置
sp_logiosize [“default” | “size” | “all” ]
缺省值是4K，但如果4K内存池没有配置，SQL Server会使用2K大小的内存池
3) 堆表可分区，分布插入操作到各个设备
适用于频繁插入的表和有并发BCP倒入数据的表，如客票系统的售票存根和退票存根表。
4) 锁升级阀限可配置。
相对于DSS应用，SQL Server也有一些特性来满足要求
1) 应用大的I/O缓冲池
用sp_poolconfig来配置。
2) 绑定热表到命名缓冲
如 sysindexes, syslogs, 注意如果把 syslogs 放到单独的缓冲中，可以减少在缺省或其他命名缓冲上的自旋锁争夺。对于客票系统的train_dir, stop_time, 票价表, 取票存储过程相关的表都可以放在单独的命名缓冲上。
3) 取后丢弃缓冲策略 (Fetch-and-discard cache strategy)
不会冲洗掉缓冲中的常用对象，可以减少MRU链的争夺，较少对OLTP事务的干扰。
对于收入统计应用，统计过往存根表中的数据，可以应用这一策略。
2．7 网络方面的调优
Sybase客户和服务器之建传递的是TDS包，缺省大小是512字节。对于要传输大批量数据的应用，如BCP、文本/图像的取用、大结果集SQL语句，要用下面的配置命令配置大的TDS包大小。
sp_configure “default network packet size”, nnn
sp_configure “maximum network packet size”, nnn
对于isql 和bcp，可以在应用级指定TDS包的大小：isql -Usa -P –Annn，bcp -Usa -P –Annn。
注意在调大maximum network packet size的参数后，要增大 additional network memory 参数，来适应 maximum network packet size 的要求。
篇2：如何通过调整Windows 参数提高数据库服务器性能
提示：提高数据库服务器性能 数据库SQL Server 跟Windows 操作系统 是同一个父母生的，他们在一些技术上具有共通性，这在很多方面都有体现。如在日常工作中，我们可以通过调整Windows操作系统的一些参数来提高SQLServer数据库服务器的性能。 一、提高虚拟内存来提高数据库服
提高数据库服务器性能
数据库SQL Server跟Windows操作系统是同一个父母生的，他们在一些技术上具有共通性。这在很多方面都有体现。如在日常工作中，我们可以通过调整Windows操作系统的一些参数来提高SQLServer数据库服务器的性能。
一、提高虚拟内存来提高数据库服务器性能。
虚拟内存简单的来说就是内盘中的一块空间。当物理内存不够时，操作系统会自动把某些驻留在内存中暂时不用的内容移植到这个在硬盘上的虚拟内存中，以释放更多的空间给新的应用程序使用。也就是说，当物理内存使用完时操作系统会拿出一部分硬盘空间来充当内存使用，以缓解内存的压力。为此从某种程度来说，这个虚拟内存的设置也会影响到数据库服务器的性能。那么这个虚拟内存到底该设置多少为好呢?这没有一个固定的标准。这需要数据库管理员根据部署的应用来确定。
如数据库没有一些高级的应用，如数据仓库、全文索引或者不适多个应用服务一身的话，笔者认为只要把虚拟内存设置为物理内存的1.5倍即可。但是，如果在数据库服务器上配置了数据仓库或者全文索引的话，则这个1.5倍的虚拟内存往往是不够的。此时笔者建议需要把虚拟内存配置为物理内存的3倍到四倍。同时，需要调整数据库中的最大服务器内存选项，将其设置为物理内存的1.5倍。也就是说，其在使用内存的时候，可以使用虚拟内存大小的一半。注意这个设置时必须的，否则的话，调整数据库虚拟内存很难起到应有的效果。而且当以后内存升级了，则也需要同时更改这个两个参数。
最后需要说明的一点就是，虚拟内存并不是越大越好。如果设置为10倍、20倍，那么这是浪费。以往内存中没有这么多的内容可以往虚拟内存中存放。所以，针对SQL Server数据库与Windows服务器来说，4倍于物理内存的虚拟内存已经足够了。设置的再大的话，就没有多少的实际意义了。
二、调整本地客户端的任务优先级。
在数据库初始化的过程中，有大部分的任务需要在本地客户端上完成。即时在后续维护中，出于某种原因仍然要在本地客户端上操作。那么什么是本地客户端呢?其实本地客户端就是跟数据库服务器部署在同一台计算机上的客户端。如我们在导入期初数据的时候，为了方便会在本地客户端上直接进行操作。因为这可以节省数据在网络上传输的时间。
不过在本地客户端上进行操作的时候，往往分为前台运行与后台运行。操作系统这么设计的本意是为了提高远程客户端的执行效率。如在远程客户端生成物料需求计划的时候，由于运算量比较大，其花费的时间可能比较久，如可能需要20分钟。为了提高工作效率，对于类似的作业，应用程序可以把这个运算放置在后台运行。不过需要注意的是，把某个作业放置在后台运行，并不能够节省其运行的时间，而往往由于放置在后台的作业其优先级比较低，往往实际花费的时间还会延长，如会延长到23分钟等等。之所以要把这个长时间运行的作业放置在后台，主要是为了让用户不用干等，可以先作其他事情。等到运行完成后，系统会自动把相关的结果返回给用户。这在感觉上是缩短了运行的时间(往往在等待的过程中时间过得特别慢)，而实际上其运行的时间根本没有缩短，甚至会更长。
这个处理策略对于远程客户端来说确实有用，至少可以在感觉上缩短用户的等待时间。而且可以让用户先进行其他的操作。但是如果在本地客户端上，处理某些作业的时候，可能并不希望如此。如在本地客户度进行物料需求计划测试，数据库管理员希望即时把这个计划放置在后台运行，其也能够与前台应用程序具有相同的优先级，以减少这个处理时间。所以，当数据库管理员遇到类似情况时，就需要调整操作系统的相关设置，让作为在后台运行的应用程序，也能够与前台运行的其他应用程序具有相同的优先级。
通常情况下，安装完干净的SQL Server数据库时，服务器任务调度设置为“务”，即前后台应用程序没有优先级的分别。也就是说，此时将为前台应用程序与后台应用程序提供相等的处理时间。但是有时候为了兼顾远程客户端，在部署实例的时候，会改变这设置。如把降低后台应用程序的优先级，让更多的资源能够服务于前台应用程序。在大部分情况下，这个设置是必要的。不过如果出于某些原因需要在本地客户端执行某些操作的话，则数据库管理员需要暂时调整这个配置，以节省某些作业的运行时间。有时候甚至可以将服务器任务调度设置为最大或者应用程序，这就可以为前台应用程序提高最大的处理器时间，
可见，任务调度计划设置也没有一个统一的优劣标准。主要还是需要看数据库服务器到底用来做什么?为此这也对数据库管理员提出了比较高的要求。此时数据库管理员必须要理解各种优先级设置对于数据库服务器性能的影响。然后再根据当时的实际应用来合理的调整任务级别的优先级，以取得本地客户端操作的最大性能。
提高数据库服务器性能
数据库SQL Server跟Windows操作系统是同一个父母生的，他们在一些技术上具有共通性。这在很多方面都有体现。如在日常工作中，我们可以通过调整Windows操作系统的一些参数来提高SQLServer数据库服务器的性能。
一、提高虚拟内存来提高数据库服务器性能。
虚拟内存简单的来说就是内盘中的一块空间。当物理内存不够时，操作系统会自动把某些驻留在内存中暂时不用的内容移植到这个在硬盘上的虚拟内存中，以释放更多的空间给新的应用程序使用。也就是说，当物理内存使用完时操作系统会拿出一部分硬盘空间来充当内存使用，以缓解内存的压力。为此从某种程度来说，这个虚拟内存的设置也会影响到数据库服务器的性能。那么这个虚拟内存到底该设置多少为好呢?这没有一个固定的标准。这需要数据库管理员根据部署的应用来确定。
如数据库没有一些高级的应用，如数据仓库、全文索引或者不适多个应用服务一身的话，笔者认为只要把虚拟内存设置为物理内存的1.5倍即可。但是，如果在数据库服务器上配置了数据仓库或者全文索引的话，则这个1.5倍的虚拟内存往往是不够的。此时笔者建议需要把虚拟内存配置为物理内存的3倍到四倍。同时，需要调整数据库中的最大服务器内存选项，将其设置为物理内存的1.5倍。也就是说，其在使用内存的时候，可以使用虚拟内存大小的一半。注意这个设置时必须的，否则的话，调整数据库虚拟内存很难起到应有的效果。而且当以后内存升级了，则也需要同时更改这个两个参数。
最后需要说明的一点就是，虚拟内存并不是越大越好。如果设置为10倍、20倍，那么这是浪费。以往内存中没有这么多的内容可以往虚拟内存中存放。所以，针对SQL Server数据库与Windows服务器来说，4倍于物理内存的虚拟内存已经足够了。设置的再大的话，就没有多少的实际意义了。
二、调整本地客户端的任务优先级。
在数据库初始化的过程中，有大部分的任务需要在本地客户端上完成。即时在后续维护中，出于某种原因仍然要在本地客户端上操作。那么什么是本地客户端呢?其实本地客户端就是跟数据库服务器部署在同一台计算机上的客户端。如我们在导入期初数据的时候，为了方便会在本地客户端上直接进行操作。因为这可以节省数据在网络上传输的时间。
不过在本地客户端上进行操作的时候，往往分为前台运行与后台运行。操作系统这么设计的本意是为了提高远程客户端的执行效率。如在远程客户端生成物料需求计划的时候，由于运算量比较大，其花费的时间可能比较久，如可能需要20分钟。为了提高工作效率，对于类似的作业，应用程序可以把这个运算放置在后台运行。不过需要注意的是，把某个作业放置在后台运行，并不能够节省其运行的时间，而往往由于放置在后台的作业其优先级比较低，往往实际花费的时间还会延长，如会延长到23分钟等等。之所以要把这个长时间运行的作业放置在后台，主要是为了让用户不用干等，可以先作其他事情。等到运行完成后，系统会自动把相关的结果返回给用户。这在感觉上是缩短了运行的时间(往往在等待的过程中时间过得特别慢)，而实际上其运行的时间根本没有缩短，甚至会更长。
这个处理策略对于远程客户端来说确实有用，至少可以在感觉上缩短用户的等待时间。而且可以让用户先进行其他的操作。但是如果在本地客户端上，处理某些作业的时候，可能并不希望如此。如在本地客户度进行物料需求计划测试，数据库管理员希望即时把这个计划放置在后台运行，其也能够与前台应用程序具有相同的优先级，以减少这个处理时间。所以，当数据库管理员遇到类似情况时，就需要调整操作系统的相关设置，让作为在后台运行的应用程序，也能够与前台运行的其他应用程序具有相同的优先级。
通常情况下，安装完干净的SQL Server数据库时，服务器任务调度设置为“务”，即前后台应用程序没有优先级的分别。也就是说，此时将为前台应用程序与后台应用程序提供相等的处理时间。但是有时候为了兼顾远程客户端，在部署实例的时候，会改变这设置。如把降低后台应用程序的优先级，让更多的资源能够服务于前台应用程序。在大部分情况下，这个设置是必要的。不过如果出于某些原因需要在本地客户端执行某些操作的话，则数据库管理员需要暂时调整这个配置，以节省某些作业的运行时间。有时候甚至可以将服务器任务调度设置为最大或者应用程序，这就可以为前台应用程序提高最大的处理器时间。
可见，任务调度计划设置也没有一个统一的优劣标准。主要还是需要看数据库服务器到底用来做什么?为此这也对数据库管理员提出了比较高的要求。此时数据库管理员必须要理解各种优先级设置对于数据库服务器性能的影响。然后再根据当时的实际应用来合理的调整任务级别的优先级，以取得本地客户端操作的最大性能。
篇3：InnoDB 中文参考手册 9 性能调整技巧数据库教程
参考|参考手册|技巧|性能|中文
InnoDB 中文参考手册 --- 犬犬(心帆)翻译 9 性能调整技巧(Performance tuning tips)1. 如果 Unix top 或 Windows 任务管理器(Task Manager) 显示服务的 CPU 占用率小于 70%，(shows that the CPU usage percentage with your workload is less than 70 %,）你的系统瓶颈可能在磁盘读写上，或许你提交了大量的事务，或者是缓冲池(buffer pool)太小了。将缓冲池设大点会有所帮助，但一定要注意不能大于物理内存的 80%。
2. 在一个事务中包含几个修改。如果事务对数据库进行了修改，那么在这个事务提交时 InnoDB 必须刷新日志到磁盘上。因为硬盘的旋转速度通常至多为 167 转/秒，那么只要磁盘不欺骗操作系统，提交的事务数目限止也同样为 167 次/秒・用户。
3. 如果掉失最近的几个事务无所谓的话，可以在 my.cnf 文件中将参数 innodb_flush_log_at_trx_commit 设置为 0。InnoDB 无论如何总是尝试一秒刷新(flush)一次日志，尽管刷新并不能得到保证。
4. 将日志文件(log files)设大一点，使日志文件的总和正好与缓冲池(buffer pool)一样大。当 InnoDB 用光日志文件的空间时，它不得不在一个时间点上将缓冲池内修改过的内容写到磁盘上。 小的日志文件可能引起不必要的磁盘写操作。但是大的日志文件的缺点就是在数据恢复时将占用较长的时间。
5. 同样 log buffer 尽量设大点，比如说 8 MB。
6. 如果要存储变长的字符串或字段可能会包含大量的 NULLs，请使用 VARCHAR 型字段代替 CHAR 。一个 CHAR(n) 字段总是使用 n bytes 来存储数据，即使这个字符串很短或是一个 NULL 值。较小的表更加适合缓冲池同时能够减少磁盘 I/O 。
7. (适合从 3.23.41 以上版本) 在某些版本的 Linux 和 Unixes 中，使用 Unix fsync 或其它类似的方法将文件刷新到磁盘是异常地慢的。InnoDB 默认的方法就是 fsync 。如果你对数据库系统的磁盘写性能不能感到满意，你可以尝试在 my.cnf 中将 innodb_flush_method 设置为 O_DSYNC，尽管 O_DSYNC 选项在多数的系统上看起来比较慢。
8. 在向 InnoDB 导入数据时，请确认 MySQL 没有打开 autocommit=1 。否则每个插入语句都要将 log 刷新到磁盘。在你的 SQL 导入文件的第一行加入
set autocommit=0;
并在最后一行加入
commit;
如果使用 mysqldump 选项 --opt，你将会得到一个快速导入 InnoDB 表的转储(dump)文件，甚至可以不再使用上面所提的 set autocommit=0; ... commit; 。
9. 小心 insert 集全的大回滚(roolback)：在插入时 InnoDB 使用插入缓冲来减少磁盘 I/O，但在相应的回滚中却没有使用这样的机制。一个 disk-bound rollback 可能会花费相应插入时间的 30 倍。如果发生一个失控的回滚，你可以查看第 6.1 章节的技巧来停止它。
10. 同样也要小心一个大的 disk-bound 的操作。使用 DROP TABLE 或 TRUNCATE (从 MySQL-4.0 以上) 来清空一个表，而不要使用 DELETE FROM yourtable。
11. 如果需要插入大量记录行可以使用多行(multi-line)的 INSERT 来减少客户端与服务器端的通信开销：
INSERT INTO yourtable VALUES (1, 2), (5, 5);
这个技巧对插入任何表均有效，而不仅仅是 InnoDB。
12. 如果在辅键上有 UNIQUE 约束，从 3.23.52 和 4.0.3 开始，可以通过在一个导入会话中将唯一键检查(uniqueness check)关闭来提高数据导入速度：
SET UNIQUE_CHECKS=0;
一个大的表导入这将减少大量的磁盘 I/O，因为这时 InnoDB 可能使用自身的插入缓冲来分批地记录辅助索引。
13. 如果在表中有一个子 FOREIGN KEY 约束，从 3.23.52 和 4.0.3 开始，可以通过在一个导入会话中将外键检查(foreign key check)关闭来提高数据导入速度：
SET FOREIGN_KEY_CHECKS=0;
对一个大的表导入这将减少大量的磁盘 I/O。
9.1 InnoDB 监视器(Monitors)
从版本 3.23.42 开始，InnoDB 中就包含了 InnoDB Monitors，它可以显示出 InnoDB 的内部状态。从版本 3.23.52 和 4.0.3 开始，你可以使用一个新的 SQL 命令
SHOW INNODB STATUS
来读取标准 InnoDB Monitor 给 SQL client 的输出信息。这些信息对性能调整有益。
另外一个使用 InnoDB Monitors 方法就是让它在服务程序 mysqld 的标准输出上持续地写出信息。当开关打开时，InnoDB Monitors 大约每 15 秒显示一次数据(注意：MySQL 的客户端并不会显示任何东西)。一个简单地使用它的方法就是以一个命令行方式执行 mysqld 。否则输出将会定向到 MySQL 服务错误日志(error log file)中 'yourhostname'.err (在 Windows 下为 mysql.err)，在 Windows 系统中必须在 MS-DOS 使用提示符下以 --console 选项运行 mysqld-max 来指令信息输出在命令提示符窗口上。
显示的信息包含下列信息： 每一个活动的事务(active transaction)保持的表和记录锁定 事务的锁等待 (lock waits of a transactions) 线程的信号量等待 (semaphore waits of threads) 文件 I/O 的等待请求 (pending file i/o requests) 缓冲池(buffer pool)的统计信息 InnoDB 主线程的 purge buffer 和 insert buffer 归并活动(merge activity)
通过下列的 SQL 命令，可以使标准的 InnoDB Monitor 记录到标准的 mysqld 的输出上：
CREATE TABLE innodb_monitor(a int) type = innodb;
通过它来停止：
DROP TABLE innodb_monitor;
CREATE TABLE 句法只不过是为了通过 MySQL SQL 语法分析而提供给 InnoDB 引擎命令的一种方式：那个被创建的表根本与 InnoDB Monitor 无任何关系。如果你在监视器运行着的状态下关闭数据库，并且你需要再次启动监视器， 那么你不得不在发出一个新的 CREATE TABLE 来启动监视器之前先移除(drop)这个表。
与之相类似的，你可以启动 innodb_lock_monitor ，它在某些方面与 innodb_monitor 一致，但是它会显示更多的锁定信息。一个单独的 innodb_tablespace_monitor 将显示在现有表空间内所建立的文件段列表以及可以分配数据结构的有效表空间。从 3.23.44 开始，提供了 innodb_table_monitor ，通过它可以获得 InnoDB 内部数据字典的信息。
3.23.52 中 InnoDB 输出的示例：
===================================== 020805 22:07:41 INNODB MONITOR UTPUT ===================================== Per second averages calculated from the last 3 seconds ---------- SEMAPHORES ---------- OS WAIT ARRAY INFO: reservation count 194, signal count 193 --Thread 7176 has waited at ../include/btr0btr.ic line 28 for 0.00 seconds the s emaphore: X-lock on RW-latch at 44d980bc created in file buf0buf.c line 354 a writer (thread id 7176) has reserved it in mode wait exclusive number of readers 1, waiters flag 1 Last time read locked in file ../include/btr0btr.ic line 28 Last time write locked in file ../include/btr0btr.ic line 28 Mutex spin waits 0, rounds 0, OS waits 0 RW-shared spins 77, OS waits 33; RW-excl spins 188, OS waits 161 ------------ TRANSACTIONS ------------ Trx id counter 0 657853517 Purge done for trx's n:o < 0 657853429 undo n:o < 0 80 Total number of lock structs in row lock hash table 22 020805 22:07:36 LATEST DETECTED DEADLOCK: *** (1) TRANSACTION: TRANSACTION 0 657853503, ACTIVE 0 sec, OS thread id 15373 inserting LOCK WAIT 3 lock struct(s), heap size 336 MySQL thread id 6, query id 3741 localhost heikki update insert into ibtest11b (D, B, C) values (5, 'khdkkkk' ,'khdkkkk') *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 0 page no 104865 n bits 208 table test/ibtest11b index PRI MARY trx id 0 657853503 lock_mode X waiting Record lock, heap no 1 RECORD: info bits 0 0: len 9; hex 73757072656d756d00; asc supremum.;; *** (2) TRANSACTION: TRANSACTION 0 657853500, ACTIVE 0 sec, OS thread id 11275 setting auto-inc lock 19 lock struct(s), heap size 2672, undo log entries 5 MySQL thread id 2, query id 3750 localhost heikki update insert into ibtest11b (D, B, C) values (5, 'khD' ,'khD') *** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 0 page no 104865 n bits 200 table test/ibtest11b index PRI MARY trx id 0 657853500 lock_mode X Record lock, heap no 1 RECORD: info bits 0 0: len 9; hex 73757072656d756d00; asc supremum.;; *** (2) WAITING FOR THIS LOCK TO BE GRANTED: TABLE LOCK table test/ibtest11b trx id 0 657853500 lock_mode AUTO-INC waiting *** WE ROLL BACK TRANSACTION (2) LIST OF TRANSACTIONS FOR EACH SESSION: ---TRANSACTION 0 657853516, ACTIVE 5 sec, OS thread id 15373 setting auto-inc lo ck LOCK WAIT 1 lock struct(s), heap size 336 MySQL thread id 6, query id 3895 localhost heikki update insert into ibtest11b (D, B, C) values (5, 'khdkkkk' ,'khdkkkk') ------- TRX HAS BEEN WAITING 5 SEC FOR THIS LOCK TO BE GRANTED: TABLE LOCK table test/ibtest11b trx id 0 657853516 lock_mode AUTO-INC waiting ------------------ ---TRANSACTION 0 657853514, ACTIVE 5 sec, OS thread id 11275 inserting LOCK WAIT 13 lock struct(s), heap size 2672, undo log entries 2 MySQL thread id 2, query id 3898 localhost heikki update insert into ibtest11d (D, B, C) values (5, 'khdkkkk' ,'khdkkkk') ------- TRX HAS BEEN WAITING 5 SEC FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 0 page no 104879 n bits 384 table test/ibtest11d index B t rx id 0 657853514 lock_mode X gap type lock waiting Record lock, heap no 130 RECORD: info bits 32 0: len 9; hex 6b48646b6b6b6b6b6b; asc kHdkkkkkk;; 1: ------------------ ---TRANSACTION 0 657853512, ACTIVE 5 sec, OS thread id 14348 updating or deletin g 20 lock struct(s), heap size 2672, undo log entries 175 MySQL thread id 5, query id 3874 localhost heikki updating delete from ibtest11a where A = 215 -------- FILE I/O -------- I/O thread 0 state: waiting for i/o request I/O thread 1 state: waiting for i/o request I/O thread 2 state: waiting for i/o request I/O thread 3 state: waiting for i/o request Pending normal aio reads: 0, aio writes: 0, ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0 Pending flushes (fsync) log: 0; buffer pool: 0 272 OS file reads, 56 OS file writes, 29 OS fsyncs 0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s ------------------------------------- INSERT BUFFER AND ADAPTIVE HASH INDEX ------------------------------------- Ibuf for space 0: size 1, free list len 5, seg size 7, 0 inserts, 0 merged recs, 0 merges Hash table size 124633, used cells 1530, node heap has 4 buffer(s) 2895.70 hash searches/s, 126.62 non-hash searches/s --- LOG --- Log sequence number 19 3267291494 Log flushed up to 19 3267283711 Last checkpoint at 19 3266545677 0 pending log writes, 0 pending chkp writes 30 log i/o's done, 0.00 log i/o's/second ---------------------- BUFFER POOL AND MEMORY ---------------------- Total memory allocated 82593970; in additional pool allocated 1406336 Buffer pool size 1920 Free buffers 1711 Database pages 205 Modified db pages 39 Pending reads 0 Pending writes: LRU 0, flush list 0, single page 0 Pages read 178, created 27, written 50 0.00 reads/s, 0.00 creates/s, 0.00 writes/s Buffer pool hit rate 1000 / 1000 -------------- ROW OPERATIONS -------------- 1 queries inside InnoDB, 0 queries in queue; main thread: purging Number of rows inserted 2008, updated 264, deleted 162, read 9 0.00 inserts/s, 0.00 updates/s, 14.66 deletes/s, 0.00 reads/s ---------------------------- END OF INNODB MONITOR UTPUT ============================
输出信息的某些注意点： 如果 TRANSACTIONS 部分报告锁定等待(lock waits)，那么你的应用程序可能有锁争用(lock contention)，
输出信息可以帮助跟踪事务死锁的原因。 SEMAPHORES 部分报告线程等待信号量以及统计出线程需要旋转(spin)或等待(wait)一个互斥(mutex)或 rw-lock 信号量的次数。一个较大的线程等待信号量的次数可能是由于磁盘 I/O 引起，或 InnoDB 内部的争用问题(contention problems)。争用(Contention)可能是由于比较繁重的并发性查询，或操作系统的线程调度的问题。 在这种情形下，可将 innodb_thread_concurrency 设置地小于默认的 8 。 FILE I/O 部分列出了文件 I/O 的等待请求。过大的值就意味着磁盘 I/O 瓶颈。 BUFFER POOL AND MEMORY 部分给出了页面读写的统计。通过这些值可以计算出你的查询通常所需的数据文件 I/O 量。
★sybase数据库中numeric数据类型字段出现跳号的问题
文档为doc格式
