注：以下指标取自Oracle的性能分析工具Statspack所提供的性能分析指标。

1．关于实例效率（Instance Efficiency Percentages）的性能指标

缓冲区未等待率(Buffer Nowait %)       

• 指在缓冲区中获取Buffer的未等待比率。
• 该指标的值应接近100%，如果该值较低，则可能要增大buffer cache。

Redo缓冲区未等待率(Redo NoWait %)       

• 指在Redo缓冲区获取Buffer的未等待比率。       
• 该指标的值应接近100%，如果该值较低，则有2种可能的情况：
  1）online redo log没有足够的空间；
  2）log切换速度较慢。       

缓冲区命中率(Buffer Hit %)       

• 指数据块在数据缓冲区中的命中率。       
• 该指标的值通常应在90%以上，否则，需要调整。如果持续小于90%，可能要加大db_cache_size。但有时，缓存命中率低并不意味着cache设置小了，可能是潜在的全表扫描降低了缓存命中率。       

内存排序率(In-memory Sort %)       

• 指排序操作在内存中进行的比率。当查询需要排序的时候，数据库会话首先选择在内存中进行排序，当内存大小不足的时候，将使用临时表空间进行磁盘排序，但磁盘排序效率和内存排序效率相差好几个数量级。       
• 该指标的值应接近100%，如果指标的值较低，则表示出现了大量排序时的磁盘I/O操作，可考虑加大sort_area_size参数的值。        

共享区命中率(Library Hit %)       

• 该指标主要代表sql在共享区的命中率。       
• 该指标的值通常应在95%以上，否则需要考虑加大共享池（修改shared_pool_size参数值），绑定变量，修改cursor_sharing等参数。       

软解析的百分比(Soft Parse %)       

• 该指标是指Oracle对sql的解析过程中，软解析所占的百分比。软解析（soft parse）是指当Oracle接到Client提交的Sql后会首先在共享池（Shared Pool）里面去查找是否有之前已经解析好的与刚接到的这一个Sql完全相同的Sql。当发现有相同的Sql就直接用之前解析好的结果，这就节约了解析时间以及解析时候消耗的CPU资源。       
• 该指标的值通常应在95%以上，如果低于80%，那么就可能sql基本没被重用，sql没有绑定变量，需要考虑绑定变量。       

闩命中率(Latch Hit %)       

• 指获得Latch的次数与请求Latch的次数的比率。
• 该指标的值应接近100%，如果低于99%，可以考虑采取一定的方法来降低对Latch的争用。       

SQL语句执行与解析的比率(Execute to Parse %)       

• 指SQL语句执行与解析的比率。SQL语句一次解析后执行的次数越多，该比率越高，说明SQL语句的重用性很好。
• 该指标的值应尽可能到高，如果过低，可以考虑设置session_cached_cursors参数。       

共享池内存使用率(Memory Usage %)       

• 该指标是指在采集点时刻，共享池（share pool）内存被使用的比例。       
• 这指标的值应保持在75%~90%,如果这个值太低，就浪费内存，如果太高，会使共享池外部的组件老化，如果SQL语句被再次执行，则就会发生硬分析。       

2．关于等待事件（Wait events）的性能指标

文件分散读取(db file scattered read (cs))       

• 该等待事件通常与全表扫描有关。因为全表扫描是被放入内存中进行的进行的，通常情况下它不可能被放入连续的缓冲区中，所以就散布在缓冲区的缓存中。       
• 如果这个等待事件比较显著，可能说明对于某些全表扫描的表，没有创建索引或没有创建合适的索引。尽管在特定条件下执行全表扫描可能比索引扫描更有效，但如果出现这种等待时，最好检查一下这些全表扫描是否必要。       

文件顺序读取(db file sequential read (cs))       

• 该等待事件通常与单个数据块相关的读取操作有关。       
• 如果这个等待事件比较显著，可能表示在多表连接中，表的连接顺序存在问题，或者可能不合适地使用了索引。对于大量事务处理、调整良好的系统，这一数值大多是很正常的，但在某些情况下，它可能暗示着系统中存在问题。应检查索引扫描，以保证每个扫描都是必要的，并检查多表连接的连接顺序。另外DB_CACHE_SIZE 也是这些等待出现频率的决定因素。

缓冲区忙(buffer busy (cs))       

• 当一个会话想要访问缓存中的某个块，而这个块正在被其它会话使用时，将会产生该等待事件。这时候，其它会话可能正在从数据文件向缓存中的这个块写入信息，或正在对这个块进行修改。       
• 出现这个等待事件的频度不应大于1%。如果这个等待事件比较显著，则需要根据等待事件发生在缓存中的哪一块（如字段头部、回退段头部块、回退段非头部块、数据块、索引块等），采取相应的优化方法。

(enqueue (cs))       

• enqueue 是一种保护共享资源的锁定机制。该锁定机制保护共享资源，如记录中的数据，以避免两个人在同一时间更新同一数据。enqueue 包括一个排队机制，即FIFO(先进先出)排队机制。注意：Oracle 的latch 机制不是FIFO。Enqueue 等待通常指的是ST enqueue、HW enqueue、TX4 enqueue 和TM enqueue。       
• 如果enqueue等待事件比较显著，则需要根据enqueue等待类型，采取相应的优化方法。

闩释放(latch free (cs))       

• 该等待事件意味着进程正在等待其他进程已持有的latch。
• latch是一种低级排队机制(它们被准确地称为相互排斥机制),用于保护系统全局区域(SGA)中共享内存结构。latch 就像是一种快速地被获取和释放的内存锁。latch 用于防止共享内存结构被多个用户同时访问。       
• 对于常见的Latch等待通常的解决方法：
  1）Share pool latch：在OLTP应用中应该更多的使用绑定变量以减少该latch的等待。
  2）Library cache latch：同样的需要通过优化sql语句使用绑定变量减少该latch的等待。       

日志文件同步(log file sync (cs))       

• 这个等待事件是指当一个会话完成一个事务（提交或者回滚数据）时，必须等待LGWR进程将会话的redo信息从日志缓冲区写到日志文件后，才能继续执行下去。       
• 这个等待事件的时间过长，可能是因为commit太频繁或者lgwr进程一次写日志的时间太长（可能是因为一次log io size太大），可调整 _log_io_size，结合log_buffer,使得 (_log_io_size*db_block_size)*n = log_buffer，这样可避免和增大log_buffer引起冲突，或者可以将日志文件存放在高速磁盘上。

Error -27727: Step download timeout (120 seconds)

错误提示:Error -27727: Step download timeout (120 seconds) has expired when downloading resource(s). Set the "Resource Page Timeout is a Warning" Run-Time Setting to Yes/No to have this message as a warning/error, respectively

查阅相关信息

1. 应用服务参数设置太大导致服务器的瓶颈
2. 页面中图片太多
3. 在程序处理表的时候检查字段太大多

原文见：http://blog.csdn.net/zeeslo

问题：

曾经遇到过一个问题，在一次性能测试过程中，使用http协议的多用户向服务器发送请求。设置了持续时间，出现错误为：27796, Failed to connect to server 'hostname';port_ld': 'reason'.10048.（凭记忆写的，不知道写错了没有）

分析:

因为负载生成器的性能太好，发数据包特别快，服务器也响应特别快，从而导致负载生成器的机器的端口在没有timeout之前就全部占满了。在全部占满后，就会出现上面的错误。执行netstat –na命令，可以看到打开了很多端口。所以就调整TCP的time out。即在最后一个端口还没有用到时，前面已经有端口在释放了。

官方的troubleshooting：

查看工具的troubleshooting，如下：

复制内容到剪贴板

代码:

Message Code 27796

Failed to connect to server 'hostname';port_ld': 'reason'.

Unable to connect to the specified server and port.

Troubleshooting

o      Try to address the reason provided for the connection failure.

o      Try to access the application with a browser from the injector machine and from another machine (such as the recording machine).

o      Check that you accurately specified the correct host name and port.

o      Ping the host/port.

o      Check if the server application you are trying to access is running.

o      If you used a hostname, check if it was resolved to the correct address.

o      Check if the server application is listening to the right port.

均不是解决之道。

成功的解决方法：

在注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters里，有如下两个键值：

TcpTimedWaitDelay

MaxUserPort

1,这里的TcpTimedWaitDelay默认值应该中是30s，所以这里，把这个值调小为5s（按需要调整）。

2,也可以把MaxUserPort调大（如果这个值不是最大值的话）。

反复验证，问题解决

通过创建表方式和数据向导方式都可以成功创建数据文件，操作员可以随意选择自己习惯的方式。总之，能坚守数据文件放数据的原则，就不会出问题了。

当回到“参数属性页面”中后，发现数据已经准备好了，而且原来灰色的区域目前也可以选择了。

“选择下一行”共有下面几个选项：

Sequential：

    按照顺序一行行的读取。每一个虚拟用户都会按照相同的顺序读取。

Random：

    任意选择。但是在每一次迭代中，将不发生变化。

Unique：

    唯一的数。当使用该选项时，需要保证准备的数据文件中有足够的数据。比如要做20个虚拟用户，每个用户要进行5次迭代，第一个用户在5次迭代中分别使用数据文件中的数据1~数据5，第二个用户在5次迭代中分别使用数据文件中的数据6~数据10，类推以后20个用户将使用到100个数据。那么必须保证准备的数据文件中有100个以上的数据，否则运行时会出错。

Same line as 某个参数：

和前面定义的参数取同行的记录。通常用在有关联性的数据上面。比如当我做登录密码的参数化时，由于它和UserID是有关联的，所以会用到这种选择方式。

“更新值的时间”共有下面几个选项：

Each iteration：

每次迭代更新一个新的值。

Each occurrence：

每次出现时该参数时更新一个新的值。

Once

不管迭代多少次该参数的值一直保持不变。

*****注意*****

1、  参数类型：

在创建参数的时候，我选择了参数类型为File。参数类型共有9种，现在来简单介绍一下所有的参数类型以及意义。

1.1、DateTime：

在需要输入日期/时间的地方，可以用DateTime 类型来替代。其属性设置也很简单，选择一种格式即可。当然也可以定制格式。

1.2、Group Name：

很少用到。在实际运行中，LoadRunner使用该虚拟用户所在的Vuser Group 来代替。但是在VuGen 中运行时，Group Name将会是None。

1.3、Load Generator Name：

在实际运行中，LoadRunner 使用该虚拟用户所在LoadGenerator 的机器名来代替。

1.4、Iteration Number：

在实际运行中，LoadRunner 使用该测试脚本当前循环的次数来代替。

1.5、Random Number：

随机数。很简单。在属性设置中可以设置产生随机数的范围。

1.6、Unique Number：

唯一的数。在属性设置中可以设置第一个数以及递增的数的大小。注意：使用该参数类型必须注意可以接受的最大数。例如：某个文本框能接受的最大数为99。当使用该参数类型时，设置第一个数为1，递增的数为1，但100 个虚拟用户同时运行时，第100 个虚拟用户输入的将是100，这样脚本运行将会出错。这里说的递增意思是各个用户取第一个值的递增数，每个用户相邻的两次循环之间的差值为1。举例说明：假如起始数为1，递增为5，那么第一个用户第一次循环取值1，第二次循环取值2；第二个用户第一次循环取值为6，第二次为7；依次类推。

1.7、Vuser ID：

设置比较简单。在实际运行中，LoadRunner 使用该虚拟用户的ID 来代替，该ID 是由Controller 来控制的。但是在VuGen 中运行时，Vuser ID 将会是 –1。

1.8、File：

需要在属性设置中编辑文件，添加内容，也可以从现成的数据库中取数据（就是我用到的那种类型）。

1.9、User Defined Function：

从用户开发的dll 文件提取数据。

有关各种参数类型属性的详细设置这里就不多介绍了，到用到的时候大家可以多看看帮助文档。

本文来自CSDN博客，转载请标明出：http://blog.csdn.net/windone0109/archive/2009/03/27/4028586.aspx

昨天在研究脚本的时候偶然遇到一个问题，今天正好有了点时间，就拿来再研究一下。
问题是这样的：我想用strcpy函数把一个字符串赋给一个变量，再将这字符串做一个参数化，然后我想看看参数化是否成功，于是我用了lr_message函数把它打印出来。脚本代码很简单，如下所示：
  Action()
{
    char a[10];
    strcpy(a,"{a}");
    lr_message(a);
    return 0;
} 
其中，{a}我已经做了参数化，参数值为11。
运行这个脚本后，发现运行日志里打印出来的a值显示为{a}。
在尝试了N遍以后，我把lr_message(a);这句代码改成lr_message(lr_eval_string(a));后问题解决，运行日志里打印出了我所期望的值11。
问题虽然解决了，但我还是很纳闷，为什么在用lr_message的时候不能直接引用参数，而我记得之前在web_url、web_submit_data等函数里都是可以直接引用参数化的值，而从来没有出现过问题。也许是在LoadRunner里，这几个函数对参数值的引用方式不同吧，不知道我这样想是否正确，希望大家批评指正！
昨天和Zee讨论了一个下午，结论还是没有明确。今天上午继续试验，试验结果表明Zee说的是正确的，不能直接将C语言里的变量直接当作LR变量使用，而需要做一些转换。事实上，执行strcpy(a,"{a}");后，并没有真正将参数值传给a。需要这样写：strcpy(a,lr_eval_string("{a}"));这样就没问题了。

转载自http://guanfengde.blog.163.com/blog/static/2947162200711654611664/

不过，问题还没有结束，在tuxedo协议中，用 lrt_strcpy函数则没有这个问题存在，例如：lrt_strcpy(sendBuf1, sendBuf);则可以成功地将sendBuf中的参数值赋值给sendBuf1。目前怀疑是该函数在内部已经进行过转换，但并不肯定，尚待证实。

再次针对以上问题进行试验，我在lrt_strcpy(sendBuf1, sendBuf);语句的前后各加了一句调试信息：lr_output_message("sendBuf:%s",sendBuf);
和lr_output_message("sendBuf1:%s",sendBuf1);
打印出来的结果截然不同，前者的输出显示没有传入参数值，而后者则成功传入参数。这表明确实是lrt_strcpy这个函数在搞鬼。
至此，这个问题可以圆满结束了！感谢Zee同学的热情解答！^_^

一般情况下，Oracle默认的最大session为150.

• 查看数据库最大会话数：show parameter sessions
• 查询当前会话数：select count(*) from v$session
• 查询当前进程数：select count(*) from v$process
• 查看数据库最大进程数：show parameter processes
• 备注：session值=processes值*1.1+5

修改processes和sessions值：

• alter system set processes=300 scope=spfile
• alter system set sessions=300 scope=spfile
• 备注：一般只执行第一个命令就可以，session自动更改

创建pfile：create pfile from spfile;
备注：如果不做此步，可能会导致更改最大连接数之后数据库不能启动现象

重启数据库，使更改生效

• shutdown immediate
• startup
• 备注：shutdown normal正常关闭数据库可能会相当相当的慢；shutdown abort 可能会导致启动数据库时很慢
  

查询具体应用的连接数：select  b.MACHINE, b.PROGRAM , count(*) from v$process a , v$session b where a.ADDR = b.PADDR and  b.USERNAME is not null  group by  b.MACHINE , b.PROGRAM order by count(*) desc;

查询是否有死锁：select * from v$locked_object;

备注1：session的状态说明

1. active 处于此状态的会话，表示正在执行，处于活动状态。
2. killed 处于此状态的会话，表示出现了错误，正在回滚，当然，也是占用系统资源的。killed的状态一般会持续较长时间，而且用windows下的工具pl/sql developer来kill掉，是不管用的，要用命令：alter system kill session 'sid,serial#' 。
3. inactive 处于此状态的会话表示不是正在执行的，比如select语句已经完成。

备注2：inactive对数据库本身没有什么影响，但是如果程序没有及时commit，那么就会造成占用过多会话。解决inactive的方法最好的就是在oracle中直接设置超时时间，也是有两种方法，区别暂时还不清楚：

1. 修改sqlnet.ora文件，新增expire_time=x(单位是分钟)。
2. 通过ALTER PROFILE DEFAULT LIMIT IDLE_TIME 10; 命令修改,记得重启下oracle。

本次通过loadrunner录制Sql Server介绍一下如何测试一个sql语句或存储过程的执行性能。

主要分如下几个步骤完成：

第一步、测试准备

第二步、配置ODBC数据源51Testing软件测试网T'?Z!_ zrI

第三步、录制SQL语句在Sql Server查询分析器中的运行过程

第四步、优化录制脚本，设置事务51Testing软件测试网/iR Gg+x$aTv1N

第五步、改变查询数量级查看SQL语句的性能51Testing软件测试网 DP*F!y;{a ^F-o

第六步、在controller中运行脚本51Testing软件测试网$m&jxFY2fy ^

转载请注明出处：http://www.51testing.com/?41972

下面开始具体的介绍：51Testing软件测试网;SAT#W k-O(Y$a$|$Y

测试准备阶段我们首先要确认测试数据库服务器：我们可以在本地安装SQL SERVER数据库服务端及客户端，也可以确定一台装好的SQL SERVER服务器。51Testing软件测试网$MNy0[ ~ l
fGG4_

接下来，准备测试数据：对数据库测试时我们要考虑的不是SQL语句是否能够正确执行，而是在某数量级的情况下SQL语句的执行效率及数据库服务的运行情况，所以我们分别准备不同数量级的测试数据，即根据实际的业务情况预估数据库中的记录数，在本次讲解中我们不考虑业务逻辑也不考虑数据表之间的关系，我们只建立一张表，并向此表中加入不同数量级的数据，如分别加入1000条、10000条、50000条、100000条数据查看某SQL语句的执行效率。

在查询分析器中运行如下脚本：51Testing软件测试网+G~"W9N6r*gT

--创建测试数据库

create database loadrunner_test;51Testing软件测试网V)Z,ek8o(Kp

use loadrunner_test51Testing软件测试网l/BB5mx1c+m

--创建测试数据表

create table test_table

(username varchar(50),sex int,age int,address varchar(100),post int)

--通过一段程序插入不同数量级的记录，具体的语法在这里就不多说了

declare  @i  int  

 set  @i=0  

 while  @i<1000   //循环1000次，可以根据测试数据情况改变插入条数51Testing软件测试网x4N8}$l
Rm*y{

 begin

     BEGIN TRAN T151Testing软件测试网 lg8p0YH"V

     insert into test_table (username,sex,age,address,post) values ('户瑞海'+cast(@i as varchar),@i-1,@i+1,'北京市和平里'+cast(@i as varchar)+'号',123456); 51Testing软件测试网+imX],a&I

     IF @@ERROR <> 0

        begin

          rollback;

          select @@error

        end51Testing软件测试网 } g(t'aS7r9S.JP S

     else51Testing软件测试网D~._ h6K

        begin51Testing软件测试网ft7~X;G

          commit;51Testing软件测试网v^.s4Z1v.@3^s

          set  @i  =  @i+1

        end    

 end

转载请注明出处：http://www.51testing.com/?4197251Testing软件测试网\W#r0q B,eP/N

好了，执行完上述语句后，建立的数据表中已经有1000条记录了，下面进行第二步的操作，配置ODBC数据源，为了能让loadrunner能够通过ODBC协议连接到我们建立的SQL SERVER数据路，我们需要在本机上建立ODBC数据源，建立方法如下：51Testing软件测试网a^_0_"H {7V

控制面板—性能和维护—管理工具—数据源（ODBC）--添加，在列表中选择SQL SERVER点击完成，根据向导输入数据源名称，链接的服务器，下一步，输入链接数据库的用户名和密码，更改链接的数据库，完成ODBC的配置，如果配置正确的话，在最后一步点击“测试数据源”，会弹出测试成功的提示。

配置好ODBC数据源后就要录制SQL语句在查询分析器中的执行过程了：

1、 打开loadrunner，选择ODBC协议51Testing软件测试网Kd6Y S)eR;wn

2、 在start recording中的application type选择win32 application；program to record中录入SQL SERVER查询分析器的路径“..\安装目录\isqlw.exe”51Testing软件测试网Z c|*~G$E7@6]0d

3、 开始录制，首先通过查询分析器登录SQL SERVER，在打开的查询分析器窗口中输入要测试的SQL语句，如“select * from test_table;”51Testing软件测试网'A"wJ4VA w)d;l

4、 在查询分析器中执行该语句，执行完成后，结束录制

好了，现在就可以看到loadrunner生成的脚本了（由于脚本过长，在这里就不粘贴了，有需要的朋友可以加我QQ，我把脚本发给你们），通过这些语句，我们可以看出，登录数据库的过程、执行SQL语句的过程

转载请注明出处：http://www.51testing.com/?41972

接下来，我们来优化脚本，我们分别为数据库登录部分和执行SQL语句的部分加一个事物，在增加一个double的变量获取事务执行时间，简单内容如下：51Testing软件测试网 ^@*qv.y7K.od/Z)a

Action()

{ double trans_time; //定义一个double型变量用来保存事务执行时间

  lr_start_transaction("sqserver_login"); //设置登录事务的开始51Testing软件测试网8J%@MP+`&Gzr

lrd_init(&InitInfo, DBTypeVersion);  //初始化链接（下面的都是loadrunner生成的脚本了，大家可以通过帮助查到每个函数的意思）51Testing软件测试网$wT/s0U+o#}X

      lrd_open_context(&Ctx1, LRD_DBTYPE_ODBC, 0, 0, 0);51Testing软件测试网3m,o*UpFW/i MR

      lrd_db_option(Ctx1, OT_ODBC_OV_ODBC3, 0, 0);

      lrd_alloc_connection(&Con1, LRD_DBTYPE_ODBC, Ctx1, 0 /*Unused*/, 0);

   ………………51Testing软件测试网.p#Q8u S&_

trans_time=lr_get_transaction_duration( "sqserver_login" ); //获得登录数据库的时间

   lr_output_message("sqserver_login事务耗时%f秒", trans_time); //输出该时间

   lr_end_transaction("sqserver_login", LR_AUTO); //结束登录事务

lr_start_transaction("start_select");//开始查询事务

lrd_cancel(0, Csr2, 0 /*Unused*/, 0);

lrd_stmt(Csr2, "select * from test_table;\r\n", -1, 1, 0 /*None*/, 0);//此句为执行的SQL51Testing软件测试网~]%C$Q#df#IW

lrd_bind_cols(Csr2, BCInfo_D42, 0);51Testing软件测试网/| e6[6l p%Gp?*@

lrd_fetch(Csr2, -10, 1, 0, PrintRow24, 0);51Testing软件测试网S{ `5H;B5Z

……………..

trans_time=lr_get_transaction_duration( "start_select" ); //获得该SQL的执行时间

lr_output_message("start_select事务耗时%f秒", trans_time); //输出该时间

lr_end_transaction("start_select", LR_AUTO); //结束查询事务51Testing软件测试网&_5S\:Ys#v!\

优化后，在执行上述脚本后，就可以得到登录到数据库的时间及运行select * from test_table这条语句的时间了，当然我们也可以根据实际情况对该条语句进行参数化，可以测试多条语句的执行时间，也可以将该语句改为调用存储过程的语句来测试存储过程的运行时间。51Testing软件测试网1Ii6\2X+YVt YO&`

接下来把该脚本在controller中运行，设置虚拟用户数，设置集合点，这些操作我就不说了，但是值得注意的是，没有Mercury授权的SQL SERVER用户license，在运行该脚本时回报错，提示“You do not have a license for this Vuser type.51Testing软件测试网8lE%r |KCUt

Please contact Mercury Interactive to renew your license.”我们公司穷啊买不起loadrunner，所以我也无法继续试验，希望有license朋友们监控一下运行结果！51Testing软件测试网dj.TE:g+wv
{

最起码在VUGen中运行该脚本我们可以得到任意一个SQL语句及存储过程的执行时间，如果我们测试的B/S结构的程序，我们也可以通过HTML协议录制的脚本在CONTROLLER中监控SQL SERVER服务器的性能情况，这样两方面结合起来就可以对数据库性能做一个完整的监控了。

本人对LOADRUNNER也是在摸索中，如果文章有写的不对，或理解错误的地方请指出，不甚感激

转载请注明出处：http://www.51testing.com/?41972

聚集索引：一种索引，该索引中键值的逻辑顺序决定了表中相应行的物理顺序。

建立原则：既不能绝大多数都相同，又不能只有极少数相同。

聚集索引的好处：就是能够根据查询要求，迅速缩小查询范围，避免全表扫描。

一张表只能有一个聚焦索引，但该索引可以包含多个列（组合索引）。

组合索引：在多个列上建立索引。

主键 不等于 聚焦索引。

并非只要建立索引就能显著提高查询速度。

聚集索引的前导列一定要是使用最频繁的列。

适用情况：

1. 含有大量非重复值的列。
2. 使用BETWEEN,>,>=,<或<=返回一个范围值的列
3. 被连续访问的列
4. 返回大型结果集的查询
5. 经常被使用连接或GROUP BY子句的查询访问的列

MyISAM：默认的MySQL插件式存储引擎，它是在Web、数据仓储和其他应用环境下最常使用的存储引擎之一。注意，通过更改STORAGE_ENGINE配置变量，能够方便地更改MySQL服务器的默认存储引擎。

InnoDB：用于事务处理应用程序，具有众多特性，包括ACID事务支持。

BDB：可替代InnoDB的事务引擎，支持COMMIT、ROLLBACK和其他事务特性。

Memory：将所有数据保存在RAM中，在需要快速查找引用和其他类似数据的环境下，可提供极快的访问。

Merge：允许MySQL DBA或开发人员将一系列等同的MyISAM表以逻辑方式组合在一起，并作为1个对象引用它们。对于诸如数据仓储等VLDB环境十分适合。

Archive：为大量很少引用的历史、归档、或安全审计信息的存储和检索提供了完美的解决方案。

Federated：能够将多个分离的MySQL服务器链接起来，从多个物理服务器创建一个逻辑数据库。十分适合于分布式环境或数据集市环境。

Cluster/NDB：MySQL的簇式数据库引擎，尤其适合于具有高性能查找要求的应用程序，这类查找需求还要求具有最高的正常工作时间和可用性。

Other：其他存储引擎包括CSV（引用由逗号隔开的用作数据库表的文件），Blackhole（用于临时禁止对数据库的应用程序输入），以及Example引擎（可为快速创建定制的插件式存储引擎提供帮助）。

MyISAM

默认存储引擎，基于传统的ISAM类型。

ISAM：Indexed Sequential Access Method (有索引的顺序访问方法)，它是存储记录和文件的标准方法。

每张MyISAM表被存放在三个文件：

• frm文件存放表格定义。
• 数据文件是MYD(MYData)。
• 索引文件是MYI(MYIndex)引伸。

MyISAM表是保存成文件的形式，在跨平台的数据转移中使用MyISAM存储会省去不少的麻烦。

MyISAM特点：

• 具有检查和修复表格的大多数工具。
• MyISAM表格可以被压缩。
• 支持全文搜索。
• 不是事务安全的，也不支持外键。

缺点：

• 事务回滚将造成不完全回滚

InnoDB

具有提交、回滚和崩溃恢复能力的事务安全（ACID兼容）存储引擎。InnoDB是为处理巨大数据量时的最大性能设计。

InnoDB特点：

• InnoDB不支持FULLTEXT类型的索引。
• InnoDB中不保存表的具体行数。执行select count(*) from table时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。
• 对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引。
• DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。
• LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性（例如外键）的表不适用。
• InnoDB表的行锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表。

多并发操作时，一般情况下InnoDB比MyISAM性能优秀些。

紧急情况下，没有足够时间设计测试用例时，如何保证测试的覆盖率和完整性能？

测试点列表：

罗列产品的功能点，根据需要功能模块逐级细分，相当于是用例的标题。

没有具体的测试步骤、预期结果等，只是保证测试时不会漏测需求功能点，保证测试的完整性。

采用这种方法，测试人员的经验和水平对测试结果有很大影响。经验不够的测试人员可能还要就测试检查点进行细分。

模块功能树：

设计依据可以分为：需求文档、页面、测试检查点等。

上述方法是非常情况下的应急方法。一般情况下，项目开发测试过程中，还是应该注重用例的设计，好的测试用例设计完毕后，可以缩小由于测试人员水平的差异而产生的测试质量问题。

参考：http://bbs.51testing.com/redirect.php?tid=397010&goto=lastpost#lastpost

testlink：适用于测试过程中管理。含：需求管理、测试计划、测试用例管理和执行（组件、分类、用例）、测试结果（数据统计、分析）

mantis、bugzilla：bug管理系统。bugzilla 英文，功能更齐全，使用范围广。

testlink可以配合mantis或bugzilla使用。

testdirector：

包含需求管理、测试过程管理和bug管理，但感觉在bug管理部分不如bugzilla。

可以个性化设置Bug和用例的导入导出。

WAP

wirelss application proctol 无线应用协议。是一种向移动终端提供互联网内容和先进增值服务的全球统一的开放式协议标准， 是简化了的无线Internet 协议。

WAP定义通用的平台，把目前Internet网上HTML语言的信息转换成用WML描述的信息，显示在移动电话或者其他手持设备的显示屏上。适应多种网络，即不依赖某种网络而存在。

WML

wireless markup language 无线标记语言。继承自HTML，但比HTML严格；基于XML，是XML的子集。一般用来创建可显示在WAP浏览器的页面（无线终端显示屏上显示、人机交互）。

WML文件结构

WML的页面通常叫做桌面（DECK），由一组互相链接的卡片（CARD）组成。当移动电话访问一个WML页面的时候，页面的所有CARD都会从WAP服务器下载到设备里。CARD之间的切换由电话内置的计算机处理，不需要再到服务器上取信息了。CARD里可以包含文本、标记、链接、输入控制、任务（TASK）、图像等等。CARD之间可以互相链接。

命令：top

命令执行后显示：

top - 16:34:45 up 20 days, 22:49, 10 users,  load average: 0.16, 0.15, 0.10
Tasks: 372 total,   1 running, 371 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.6%us,  1.0%sy,  0.0%ni, 98.3%id,  0.2%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   3745792k total,  3719544k used,    26248k free,    11992k buffers
Swap:  4192924k total,  2073508k used,  2119416k free,   935288k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                      

    1 root      15   0  2088  548  524 S  0.0  0.0   1:10.83 init              
    2 root      RT  -5     0    0    0 S  0.0  0.0   0:01.40 migration/0       
    3 root      34  19     0    0    0 S  0.0  0.0   0:00.09 ksoftirqd/0       
    4 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/0        
    5 root      RT  -5     0    0    0 S  0.0  0.0   0:01.10 migration/1       
    6 root      34  19     0    0    0 S  0.0  0.0   0:00.13 ksoftirqd/1       
    7 root      RT  -5     0    0    0 S  0.0  0.0   0:00.00 watchdog/1        
    8 root      RT  -5     0    0    0 S  0.0  0.0   0:01.03 migration/2       
    9 root      34  19     0    0    0 S  0.0  0.0   0:00.07 ksoftirqd/2       

统计信息内容解释：

第一行是任务队列信息，同 uptime 命令的执行结果。

第二行为进程信息。
　　total 进程总数
　　running 正在运行的进程数
　　sleeping 睡眠的进程数
　　stopped 停止的进程数
　　zombie 僵尸进程数

第三行为CPU信息。
    us 用户空间占用CPU百分比
　　sy 内核空间占用CPU百分比
　　ni 用户进程空间内改变过优先级的进程占用CPU百分比
　　id 空闲CPU百分比
　　wa 等待输入输出的CPU时间百分比
　　hi 硬件中断
　　si 软件中断

最后两行为内存信息。

Mem:total 物理内存总量
　　used 使用的物理内存总量
　　free 空闲内存总量
　　buffers 用作内核缓存的内存量

Swap:total 交换区总量
　　used 使用的交换区总量
　　free 空闲交换区总量
　　cached 缓冲的交换区总量

进程信息区

    默认情况下仅显示比较重要的 PID、USER、PR、NI、VIRT、RES、SHR、S、%CPU、%MEM、TIME+、COMMAND 列。

PID  进程id
USER 进程所有者的用户名
PR   优先级
NI   nice值。负值表示高优先级，正值表示低优先级
VIRT 进程使用的虚拟内存总量，单位kb。VIRT=SWAP+RES
RES  进程使用的、未被换出的物理内存大小，单位kb。RES=CODE+DATA
SHR  共享内存大小，单位kb
S 进程状态：
  　 D=不可中断的睡眠状态
　　 R=运行
　　 S=睡眠
　　 T=跟踪/停止
　　 Z=僵尸进程
%CPU    上次更新到现在的CPU时间占用百分比
%MEM    进程使用的物理内存百分比
TIME+   进程使用的CPU时间总计，单位1/100秒
COMMAND 命令名/命令行

top：交互式工具，用于监视性能，包含整个Linux系统的性能概要和进程信息。

vmstat：报告内存和交换区的使用信息，也可以报告部分CPU和I/O信息。

free：主要是报告内存和交换区信息。

RPM:Red Hat Package Manager，Red Hat 软件包管理，包含procs rpm和sysstat rpm两种。proc rpm包含top、vmstat和free。sysstat rmp包含iostat和sar。

转载自：http://www.bitscn.com/os/linux/200802/128193.html

vmstat是Virtual Meomory Statistics（虚拟内存统计）的缩写, 是实时系统监控工具。该命令通过使用knlist子程序和/dev/kmen伪设备驱动器访问这些数据，输出信息直接打印在屏幕。vmstat反馈的与CPU相关的信息包括：

    1.多少任务在运行

    2.CPU使用的情况

    3.CPU收到多少中断

    4.发生多少上下文切换

vmstat的语法如下： vmstat [delay [count]]

参数 解释

delay 相邻的两次采样的间隔时间

count 采样的次数，count只能和delay一起使用

当没有参数时，vmstat则显示系统启动以后所有信息的平均值。有delay时，第一行的信息自系统启动以来的平均信息。从第二行开始，输出为前一个delay时间段的平均信息。当系统有多个CPU时，输出为所有CPU的平均值。

参数 解释

任务的信息(procs)

   r 在internal时间段里，运行队列里等待CPU的任务的个数，即不包含vmstat进程 procs_running-1

   b 在internal时间段里，被资源阻塞的任务数（I/0，页面调度，等等.），通常情况下是接近0的procs_blocked

CPU信息(cpu)

    us 在internal时间段里，用户态的CPU时间(%)，包含 nice值为负进程 (?user+?nice)/?total*100

    sy 在internal时间段里，核心态的CPU时间(%) (?system+?irq+?softirq)/?total*100

    id 在internal时间段里，cpu空闲的时间，不包括等待i/o的时间(%) ?idle/?total*100

    wa 在internal时间段里，等待i/o的时间(%) ?iowait/?total*100

系统信息(system)

    in 在internal时间段里，每秒发生中断的次数 ?intr/interval

    cs 在internal时间段里，每秒上下文切换的次数，即每秒内核任务交换的次数 ?ctxt/interval

范例1：average mode (粗略信息)

当vmstat不带参数时，对应的输出值是从系统启动以来的平均值，而r和b则对应的是完成这一命令时，系统的值。从下面例子，可以看出系统基本出去闲置状态（idle）。自启动以来，CPU在用户态消耗时间为5%，在核心态消耗为本1%，剩下的为闲置时间。需要指出的是：这里的用户态时间包括nice值为负的进程的时间。

CODE:

[root@localhost ~]# vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 0 4580 428 98516 0 0 49 6 15 19 2 1 96 1
[root@localhost ~]#

范例2：average mode (详细信息)

命令格式： vmstat –s

这里只讨论与CPU相关信息。“CPU ticks”表示自系统启动CPU运行时间，这里以tick为时间单位。用tick来西安市us,sy id 和wa的时间；forks指自从系统启动以来，所创建的新任务的个数。这些信息从/proc/stat 的第一行和”processes”行获得。

CODE:

[root@localhost ~]# vmstat -s
255280 total memory
244216 used memory
206624 active memory
21208 inactive memory
11064 free memory
628 buffer memory
91396 swap cache
255992 total swap
24 used swap
255968 free swap
973400 non-nice user cpu ticks
477 nice user cpu ticks
206168 system cpu ticks
43567714 idle cpu ticks
373234 IO-wait cpu ticks
62732 IRQ cpu ticks
1972 softirq cpu ticks
22366502 pages paged in
88756936 pages paged out
0 pages swapped in
0 pages swapped out
135634319 interrupts
137288441 CPU context switches
1134440368 boot time
208990 forks
[root@localhost ~]#
 

结果解释

non-nice user cpu ticks 自系统启动以来，CPU在用户态下运行非nice进程的时间，单位为jiffies user

nice user cpu ticks 自系统启动以来，CPU在用户态下运行nice进程的时间，单位为jiffies nice

system cpu ticks 自系统启动以来，CPU处于系统状态的时间，单位为jiffies sys

idle cpu ticks 自系统启动以来，CPU处于闲置状态的时间，单位为jiffies idle

IO-wait cpu ticks 自系统启动以来，CPU处理IO中断的时间，单位为jiffies iowait

IRQ cpu ticks 自系统启动以来，CPU处理硬中断的时间，单位为jiffies irq

softing cpu ticks 自系统启动以来，CPU处理软中断的时间，单位为jiffies Softirq

interrupts 自系统启动以来，发生的所有的中断的次数目 Intr

CPU context switches 自系统启动以来，发生的上下文交换的次数 Ctxt

boot time 自系统启动以来到现在运行的时间，单位为秒。 btime

forks 自系统启动以来所创建的任务的个数目。 Process

范例3：定期采样(delay [count])

定期采样数据是指每隔delay时间，采样一次。当count 为0时，vmstat 将不停地定期报告信息；否则当报告count次后，vmstat 命令停止运行。

第一行的信息如同范例1，是自系统启动以来的平均信息。从第二行开始，每行的意思是：r和b采样那一时刻系统运行队列和等待队列的情况；而usystem参数（in,cs）以及CPU参数（us,sy,id,wa）对应的输出值是系统在前一个delay的情况。

从下面例子可以看出上下文交换的次数小于中断的发生次数。当系统大部分时间是空闲并且中断大部分是时间中断时，这种现象极可能发生。当时间中断发生时, 因为调度器没有什么任务可调度，所以很少发生上下文切换。

CODE:

[root@localhost ~]# vmstat 2 4
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 24 11032 652 91396 0 0 49 6 15 19 2 1 96 1
0 0 24 11032 652 91396 0 0 0 0 377 464 1 0 99 0
0 0 24 11024 652 91396 0 0 0 0 387 476 1 0 100 0
0 0 24 11024 652 91396 0 0 0 0 323 377 0 0 100 0
[root@localhost ~]#

转载自：http://www.bitscn.com/os/linux/200802/128193.html

uptime是Linux系统常用的命令，用来报告系统已经运行多长时间，依此显示的信息：现在时间，系统已经运行了的时间，目前有多少登陆用户， 1分钟系统平均负载，5分钟系统平均负载，15分钟系统平均负载。该命令从/proc/loadavg 中获得load average的信息。

范例1：系统只用一个CPU

[root@localhost ~]# uptime

12:20:49 up 3 days,9:20, 5 users, load average 1.10 1.32 1.15

对于一个CPU的系统来说，范例1中的平均负载高了些。通常来说：如果系统有n个CPU而且平均负载小于n,则说明某些CPU还有空闲的时间片。通过该命令，你能知道CPU是否繁忙，但是无法知道为什么忙。