服务器执行存储过程语句时如何优化与排查性能问题

在数据库管理与应用程序开发中，服务器语句执行存储过程是一项核心操作，它不仅能够简化复杂逻辑的调用，还能提升数据处理的效率与安全性，存储过程作为预编译在数据库服务器中的一段SQL语句集合，通过接收参数、执行特定操作并返回结果，为业务逻辑的实现提供了标准化、可复用的解决方案，本文将从存储过程的基本概念、执行方式、参数传递、错误处理及性能优化等方面,系统阐述服务器语句执行存储过程的关键要点。

存储过程的基本概念与优势

存储过程是存储在数据库中的命名PL/SQL（以Oracle为例）或T-SQL（以SQL Server为例）代码块，通过 CREATE PROCEDURE 或 CREATE PROC 语句定义，与直接在应用程序中嵌入SQL语句相比，存储过程具有显著优势：

服务器语句执行存储过程的语法与方式

不同数据库管理系统（DBMS）执行存储过程的语法略有差异，但核心逻辑一致，以下以SQL Server和MySQL为例，说明基本执行方式。

SQL Server中执行存储过程

在SQL Server中，使用或简写语句调用存储过程，基本语法为：

EXEC 存储过程名 [参数1 [=值1] [OUTPUT], 参数2 [=值2] [OUTPUT], ...]

MySQL中执行存储过程

MySQL使用语句调用存储过程，语法为：

CALL 存储过程名 (参数1, 参数2, ...);

参数传递的类型与注意事项

参数传递是存储过程执行的核心，可分为输入参数（）、输出参数（）和输入输出参数（），不同DBMS的参数声明方式略有不同：

注意事项 ：

错误处理与调试技巧

存储过程执行过程中可能因SQL语法错误、数据冲突或逻辑问题导致异常，合理的错误处理机制至关重要。

SQL Server的错误处理

SQL Server使用 TRY...CATCH 块捕获错误，通过 ERROR_NUMBER() 、 ERROR_MESSAGE() 等函数获取错误信息：

BEGIN TRYEXEC Proc_InvalidOperation;END TRYBEGIN CATCHSELECT '错误号: ' + CAST(ERROR_NUMBER() AS VARCHAR(10)) +', 错误信息: ' + ERROR_MESSAGE();END CATCH

MySQL的错误处理

MySQL通过 DECLARE ... HANDLER 定义错误处理器，

DELIMITER //CREATE PROCEDURE Proc_SafeInsert()BEGINDECLARE EXIT HANDLER FOR SQLEXCEPTIONBEGINSELECT '执行失败: ' + MESSAGE_TEXT;END;INSERT INTO Logs (Content) VALUES ('测试数据');END //DELIMITER ;

调试建议 ：

性能优化与最佳实践

为提升存储过程的执行效率，需遵循以下优化原则：

实际应用场景举例

存储过程广泛应用于企业级系统中，典型场景包括：

服务器语句执行存储过程是数据库应用开发的重要技能，通过合理设计参数、完善错误处理、优化性能，能够显著提升系统的稳定性与效率，开发者需结合业务需求，遵循最佳实践，充分发挥存储过程在逻辑封装、安全控制及性能优化方面的优势，为构建高效、可靠的数据库应用奠定基础。

寻求SQL数据库的有关论文

ORACLE中SQL查询优化研究摘 要 数据库性能问题一直是决策者及技术人员共同关注的焦点，影响数据库性能的一个重要因素就是SQL查询语句的低效率。 论文首先分析了导致SQL查询语句性能低下的四个常见原因以及SQL调优的一般步骤，然后分别针对如何降低I/O操作、在查询语句中如何避免对查询结果的高成本操作以及在多表连接时如何提高查询效率进行了分析。 关键词 ORACLE；SQL；优化；连接1 引言　随着网络应用不断发展，系统性能已越来越引起决策者的重视。 影响系统性能的因素很多，低效的SQL语句就是其中一个不可忽视的重要原因。 论文首先分析导致SQL性能低下的常见原因，然后分析SQL调优应遵循的一般步骤，最后从如何降低I/O、避免对查询结果的高成本操作和多表连接中如何提高SQL性能进行了研究。 鉴于目前ORACLE在数据库市场上的主导地位，论文将只针对ORACLE进行讨论。 2 影响SQL性能的原因　影响SQL性能的因素很多，如初始化参数设置不合理、导入了不准确的系统及模式统计数据从而影响优化程序(CBO)的正确判断等，这些往往和DBA密切相关。 纯粹从SQL语句出发，笔者认为影响SQL性能不外乎以下四个重要原因：　(1)在大记录集上进行高成本操作，如使用了引起排序的谓词等。 (2)过多的I/O操作(含物理I/O与逻辑I/O)，最典型的就是未建立恰当的索引，导致对查询表进行全表扫描。 (3)处理了太多的无用记录，如在多表连接时过滤条件位置不当导致中间结果集包含了太多的无用记录。 (4)未充分利用数据库提供的功能，如查询的并行化处理等。 第(4)个原因处理起来相对简单。 论文将针对前三个原因论述如何提高SQL查询语句的性能。 3 SQL优化的一般步骤　SQL优化一般需经过发现问题、分析问题、提出解决措施、应用措施、测试性能几个步骤，如图1所示。 “发现问题就是解决问题的一半”，因此在SQL调优过程中，定位问题SQL是非常重要的一步，一般可借助于ORACLE自带的性能优化工具如STATSPACK、TKPROF、AUTOTRACE等辅助用户进行，同时还应该重视动态性能视图如V$SQL、V$MYSTAT、V$SYSSTAT等的研究。 图1 SQL优化的一般步骤　4 SQL语句的优化　4.1 优化排序操作　排序的成本十分高昂，当在查询语句中使用了引起结果集排序的谓词时，SQL性能必然受到影响。 4.1.1 排序过程分析　当待排序数据集不是太大时，服务器在内存(排序区)完成排序操作，如果排序需要更多的内存空间，服务器将进行如下处理：　(1) 将数据分成多个小的集合，对每一集合进行排序。 (2) 服务器向磁盘申请临时空间，将排好序的中间结果写入临时段，再对另外的集合进行排序。 (3) 在所有的集合均排好序后，服务器再将它们进行合并得到最终的结果，如果排序区尺寸太小，合并无法一次完成时，将分多次进行。 从上述分析可知，排序是一种十分昂贵的操作，它消耗大量的CPU时间和内存，触发磁盘分页和交换操作，因此只要有可能，我们就应该在SQL语句中尽量避免排序操作。 4.1.2 SQL中引起排序的操作　SQL查询语句中引起排序的操作大致有：ORDER BY 和GROUP BY 从句；DISTINCT修饰符；UNION、INTERSECT、MINUS集合操作符；多表连接时的排序合并连接(SORT MERGE JOIN)等。 4.1.3 如何避免排序　1)建立恰当的索引　对经常进行排序和连接操作的字段建立索引。 在建立索引后，当服务器向这些字段发出排序请求时，将直接引用索引而不进行排序操作；当进行等值连接查询操作时，若建立连接的字段未建立索引，服务器进行的是排序合并连接(SORT MERGE JOIN)，连接操作的过程如下：　对进行连接的两个或多个表分别进行全扫描；　对每一个表中的行集分别进行全排序；　合并排序结果。 如果建立连接的字段已建立索引，服务器进行嵌套循环连接(NESTED LOOP JOINS)，该连接方式不需要任何排序，其过程如下：　对驱动表进行全表扫描；　对返回的每一行利用连接字段值实施索引惟一扫描；　利用从索引扫描中返回的ROWID值在从表中定位记录；　合并主、从表中的匹配记录。 因此，建立索引可避免多数排序操作。 2)用UNIION ALL替换UNION　UNION在进行表链接后会筛选掉重复的记录，所以在表链接后会对所产生的结果集进行排序运算，删除重复的记录再返回结果。 大部分应用中是不会产生重复记录的，最常见的是过程表与历史表UNION 。 因此，采用UNION ALL操作符替代UNION，因为UNION ALL操作只是简单的将两个结果合并后就返回。 4.2 优化I/O　过多的I/O操作会占用CPU时间、消耗大量内存和占用过多的栓锁，因此有必要对SQL的I/O进行优化。 优化I/O的最有效方式就是用索引扫描代替全表扫描。 4.2.1 应用基于函数的索引　基于函数的索引(FUNCTION BASED INDEX，简记为FBI)提供了索引计算列并在查询中使用这些索引的能力。 FBI的实质是对查询所需中间结果进行预处理。 如果一个FBI与查询语句中的内嵌函数完全匹配，CBO在生成查询计划时，将自动启用索引范围扫描(INDEX RANGE SCAN)替换全表扫描(FULL TABLE SCAN)。 考察下面的代码段并用AUTOTRACE观察创建FBI前后执行计划的变化。 select * from emp where upper(ename)=’SCOTT’　创建FBI前，很明显是全表扫描。 Execution Plan　……　1 0 TABLE ACCESS (FULL) OF EMPLOYEES (Cost=2 Card=1 Bytes=22)　idle>CREATE INDEX EMP_UPPER_FIRST_NAME ON EMPLOYEES(UPPER(FIRST_NAME))；　索引已创建。 再次运行相同查询，　Execution Plan　……　1 0 TABLE ACCESS (BY INDEX ROWID) OF EMPLOYEES (Cost=1 Card=1 Bytes=22)　2 1 INDEX (RANGE SCAN) OF EMP_UPPER_FIRST_NAME (NON-UNIQUE) (Cost=1 Card=1)　这一简单的例子充分说明了FBI在SQL查询优化中的作用。 FBI所用的函数可以是用户自己创建的函数，该函数越复杂，基于该函数创建FBI对SQL查询性能的优化作用越明显。 4.2.2 应用物化视图和查询重写　物化视图是一个预计算结果集，其中通常包含聚集与多表连接等复杂操作。 数据库自动维护物化视图，且随用户的要求进行刷新。 查询重写机制就是用数据库中的替代对象(如物化视图)将用户提交的查询重写为完全不同但功能等价的查询。 查询重写对用户透明，用户完全按常规编写访问数据库的查询语句，优化程序(CBO)自动决定是否对用户提交的查询进行重写。 查询重写是提高查询性能的一种非常有效的方法，尤其是在数据仓库环境中针对汇总、多表连接以及其它高成本的操作方面。 下面以一个非常简单的例子来演示物化视图和查询重写在优化SQL查询性能方面的作用。 select ，，count(*)　from emp，dept　where =　group by ，　查询计划及主要统计数据如下：　执行计划：　-----------------------------------------　……　2 1 HASH JOIN (Cost=5 Card=14 Bytes=224)　3 2 TABLE ACCESS (FULL) OF DEPT (Cost=2 Card=4 Bytes=52)　4 2 TABLE ACCESS (FULL) OF EMP (Cost=2 Card=14 Bytes=42)　主要统计数据：　-----------------------------------------　305 recursive calls　46 consistent gets　创建物化视图EMP_DEPT：　create materialized view emp_dept build immediate　refresh on demand　enable query rewrite　as　select ，，count(*)　from emp，dept　where =　group by ，　/　再次执行查询，执行计划及主要统计数据如下：　执行计划：　-------------------------------------　……　1 0 TABLE ACCESS (FULL) OF EMP_DEPT (Cost=2 Card=327 Bytes=)　主要统计数据：　------------------------------------　79 recursive calls　28 consistent gets　可见，在建立物化视图之前，首先执行两个表的全表扫描，然后进行HASH连接，再进行分组排序和选择操作；而建立物化视图后，CBO自动将上述复杂操作转换为对物化视图EMP_DEPT的全扫描，相关的统计数据也有了很大的改善，递归调用(RECURSIVE CALLS)由305降到79，逻辑I/O(CONSISTENT GETS)由46降为28。 4.2.3 将频繁访问的小表读入CACHE　逻辑I/O总是快于物理I/O。 如果数据库中存在被应用程序频繁访问的小表，可将这些表强行读入KEEP池，从而避免物理I/O的发生。 4.3 多表连接优化　最能体现查询复杂性的就是多表连接，多表连接操作往往要耗费大量的CPU时间和内存，因此多表连接查询性能优化往往是SQL优化的重点与难点。 4.3.1 消除外部连接　通过消除外部连接，不仅使得到的查询更易于读取，而且性能也经常可以得到改善。 一般的思路是，有以下形式的查询：　SELECT …，OUTER_JOINED_　FROM SOME_TABLE，OUTER_JOINED_TO_TABLE　WHERE …=OUTER_JOINED_TO_TABLE(+)　可转换为如下形式的查询：　SELECT …，(SELECT COLUMN FROM OUTER_ JOINED_TO_TABLE WHERE …)FROM SOME_TABLE；　4.3.2 谓词前推，优化中间结果　多表连接的性能低下多数是因为连接操作与过滤操作的次序不合理，大多数用户在编写多表连接查询时，总是先进行连接操作再应用过滤条件，这导致服务器做了太多的无用功。 针对这类问题，其优化思路就是尽可能将过滤谓词前推，使不符合条件的记录提前被筛选掉，只对符合条件的少数记录进行连接处理，这样可成倍的提高SQL查询效能。 标准连接查询如下：　Select _name，sum(_quant)，　sum(_quant)，sum(_quant)　From product a，tele_sale b，online_sale c，store_sale d　Where _id=_id and _id=_id　and _id=_id And _date>sysdate-90　Group by _id；　启用内嵌视图，且将条件_date>sysdate-90前移，优化后代码如下：　Select _name，_sale_sum，_sale_sum，_sale_sum From product a，　(select sum(sal_quant) tele_sale_sum from product，tele_sale　Where _date>sysdate-90 and _id =tele__id) b，　(select sum(sal_quant) online_sale_sum　from product，tele_sale　Where _date>sysdate-90 and _id =online__id) c，　(select sum(sal_quant) store_sale_sum　from product，store_sale　Where _date>sysdate-90 and _id =store__id) d，　Where _id=_id and　_id=_id and _id=_id；　5 结束语　SQL语言在数据库应用中占有非常重要的地位，其性能的优劣直接影响着整个信息系统的可用性。 论文从影响SQL性能的最主要的三个方面入手，分析了如何优化SQL查询的I/O、避免高成本的排序操作和优化多表连接。 需要强调的一点是，理解SQL语句所解决的问题比SQL调优本身更重要，因此SQL调优需要系统分析人员、开发人员和数据库管理员密切协作。 参考文献　[1]Thomas Oracle by Design：Design and Build High-performance Oracle Application[M]，The McGral- Hill Companies，Inc，2003　[2]Kevin LOney，George Koch，Oracle 9i：The Complete Reference[M]，The McGral-Hill Companies，Inc，2002　[3] Oracle9i SQL Reference release 2(9.2)[OL/M]，2002.10. http：///technology/　[4] Oracle9i Data Warehousing Guide release 2(9.2) [OL/M]，2002.03. http：///technology/　[5]Alexey Danchenkov，Donald Burleson，Oracle Tuning：The Definitive Reference[OL/M]，Rampant Techpress，2006.　[6] Oracle9i Database Concepts release 2(9.2) [OL/M]，2002.08. http：///technology/　[7] Oracle9i supplied plsql packages and types reference release 2(9.2) [OL/M]，2002.12. http：/// technology/

mysql数据库性能测试

我理解的是你希望了解mysql性能测试的方法：其实常用的一般：选取最适用的字段属性MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。 因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。 例如，在定义邮政编码这个字段时，如果将其设置为CHAR(255),显然给数据库增加了不必要的空间，甚至使用VARCHAR这种类型也是多余的，因为CHAR(6)就可以很好的完成任务了。 同样的，如果可以的话，我们应该使用MEDIUMINT而不是BIGIN来定义整型字段。 另外一个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOT NULL，这样在将来执行查询的时候，数据库不用去比较NULL值。 对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。 因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。 这样，我们又可以提高数据库的性能。 2、使用连接（JOIN）来代替子查询(Sub-Queries)MySQL从4.1开始支持SQL的子查询。 这个技术可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。 例如，我们要将客户基本信息表中没有任何订单的客户删除掉，就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来，然后将结果传递给主查询，如下所示：DELETE FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作，同时也可以避免事务或者表锁死，并且写起来也很容易。 但是，有些情况下，子查询可以被更有效率的连接（JOIN）.. 替代。 例如，假设我们要将所有没有订单记录的用户取出来，可以用下面这个查询完成：SELECT * FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )如果使用连接（JOIN）.. 来完成这个查询工作，速度将会快很多。 尤其是当salesinfo表中对CustomerID建有索引的话，性能将会更好，查询如下：SELECT * FROM customerinfo LEFT JOIN salesinfoON =salesinfo. CustomerID WHERE IS NULL连接（JOIN）.. 之所以更有效率一些，是因为 MySQL不需要在内存中创建临时表来完成这个逻辑上的需要两个步骤的查询工作。 3、使用联合(UNION)来代替手动创建的临时表MySQL 从 4.0 的版本开始支持 UNION 查询，它可以把需要使用临时表的两条或更多的 SELECT 查询合并的一个查询中。 在客户端的查询会话结束的时候，临时表会被自动删除，从而保证数据库整齐、高效。 使用 UNION 来创建查询的时候，我们只需要用 UNION作为关键字把多个 SELECT 语句连接起来就可以了，要注意的是所有 SELECT 语句中的字段数目要想同。 下面的例子就演示了一个使用 UNION的查询。 SELECT Name, Phone FROM client UNION SELECT Name, BirthDate FROM authorUNIONSELECT Name, Supplier FROM product4、事务尽管我们可以使用子查询（Sub-Queries）、连接（JOIN）和联合（UNION）来创建各种各样的查询，但不是所有的数据库操作都可以只用一条或少数几条SQL语句就可以完成的。 更多的时候是需要用到一系列的语句来完成某种工作。 但是在这种情况下，当这个语句块中的某一条语句运行出错的时候，整个语句块的操作就会变得不确定起来。 设想一下，要把某个数据同时插入两个相关联的表中，可能会出现这样的情况：第一个表中成功更新后，数据库突然出现意外状况，造成第二个表中的操作没有完成，这样，就会造成数据的不完整，甚至会破坏数据库中的数据。 要避免这种情况，就应该使用事务，它的作用是：要么语句块中每条语句都操作成功，要么都失败。 换句话说，就是可以保持数据库中数据的一致性和完整性。 事物以BEGIN 关键字开始，commit关键字结束。 在这之间的一条SQL操作失败，那么，ROLLBACK命令就可以把数据库恢复到BEGIN开始之前的状态。 BEGIN;INSERT INTO salesinfo SET CustomerID=14;UPDATE inventory SET Quantity=11WHERE item=book;COMMIT;事务的另一个重要作用是当多个用户同时使用相同的数据源时，它可以利用锁定数据库的方法来为用户提供一种安全的访问方式，这样可以保证用户的操作不被其它的用户所干扰。 5、锁定表尽管事务是维护数据库完整性的一个非常好的方法，但却因为它的独占性，有时会影响数据库的性能，尤其是在很大的应用系统中。 由于在事务执行的过程中，数据库将会被锁定，因此其它的用户请求只能暂时等待直到该事务结束。 如果一个数据库系统只有少数几个用户来使用，事务造成的影响不会成为一个太大的问题；但假设有成千上万的用户同时访问一个数据库系统，例如访问一个电子商务网站，就会产生比较严重的响应延迟。 其实，有些情况下我们可以通过锁定表的方法来获得更好的性能。 下面的例子就用锁定表的方法来完成前面一个例子中事务的功能。 LOCK TABLE inventory WRITESELECT Quantity FROM inventoryWHEREItem=book; inventory SET Quantity=11WHEREItem=book;UNLOCK TABLES这里，我们用一个 SELECT 语句取出初始数据，通过一些计算，用 UPDATE 语句将新值更新到表中。 包含有 WRITE 关键字的 LOCK TABLE 语句可以保证在 UNLOCK TABLES 命令被执行之前，不会有其它的访问来对 inventory 进行插入、更新或者删除的操作。 6、使用外键锁定表的方法可以维护数据的完整性，但是它却不能保证数据的关联性。 这个时候我们就可以使用外键。 例如，外键可以保证每一条销售记录都指向某一个存在的客户。 在这里，外键可以把customerinfo 表中的CustomerID映射到salesinfo表中CustomerID，任何一条没有合法CustomerID的记录都不会被更新或插入到salesinfo中。 CREATE TABLE customerinfo( CustomerID INT NOT NULL , PRIMARY KEY ( CustomerID )) TYPE = INNODB;CREATE TABLE salesinfo( SalesID INT NOT NULL, CustomerID INT NOT NULL, PRIMARY KEY(CustomerID, SalesID), FOREIGN KEY (CustomerID) REFERENCES customerinfo (CustomerID) ON DELETECASCADE) TYPE = INNODB;注意例子中的参数“ON DELETE CASCADE”。 该参数保证当 customerinfo 表中的一条客户记录被删除的时候，salesinfo 表中所有与该客户相关的记录也会被自动删除。 如果要在 MySQL 中使用外键，一定要记住在创建表的时候将表的类型定义为事务安全表 InnoDB类型。 该类型不是 MySQL 表的默认类型。 定义的方法是在 CREATE TABLE 语句中加上 TYPE=INNODB。 如例中所示。 7、使用索引索引是提高数据库性能的常用方法，它可以令数据库服务器以比没有索引快得多的速度检索特定的行，尤其是在查询语句当中包含有MAX(), MIN()和ORDERBY这些命令的时候，性能提高更为明显。 那该对哪些字段建立索引呢？一般说来，索引应建立在那些将用于JOIN, WHERE判断和ORDER BY排序的字段上。 尽量不要对数据库中某个含有大量重复的值的字段建立索引。 对于一个ENUM类型的字段来说，出现大量重复值是很有可能的情况，例如customerinfo中的“province”.. 字段，在这样的字段上建立索引将不会有什么帮助；相反，还有可能降低数据库的性能。 我们在创建表的时候可以同时创建合适的索引，也可以使用ALTER TABLE或CREATE INDEX在以后创建索引。 此外，MySQL从版本3.23.23开始支持全文索引和搜索。 全文索引在MySQL 中是一个FULLTEXT类型索引，但仅能用于MyISAM 类型的表。 对于一个大的数据库，将数据装载到一个没有FULLTEXT索引的表中，然后再使用ALTER TABLE或CREATE INDEX创建索引，将是非常快的。 但如果将数据装载到一个已经有FULLTEXT索引的表中，执行过程将会非常慢。 8、优化的查询语句绝大多数情况下，使用索引可以提高查询的速度，但如果SQL语句使用不恰当的话，索引将无法发挥它应有的作用。 下面是应该注意的几个方面。 首先，最好是在相同类型的字段间进行比较的操作。 在MySQL 3.23版之前，这甚至是一个必须的条件。 例如不能将一个建有索引的INT字段和BIGINT字段进行比较；但是作为特殊的情况，在CHAR类型的字段和VARCHAR类型字段的字段大小相同的时候，可以将它们进行比较。 其次，在建有索引的字段上尽量不要使用函数进行操作。 例如，在一个DATE类型的字段上使用YEAE()函数时，将会使索引不能发挥应有的作用。 所以，下面的两个查询虽然返回的结果一样，但后者要比前者快得多。 SELECT * FROM order WHERE YEAR(OrderDate)<2001;SELECT * FROM order WHERE OrderDate<2001-01-01;同样的情形也会发生在对数值型字段进行计算的时候：SELECT * FROM inventory WHERE Amount/7<24;SELECT * FROM inventory WHERE Amount<24*7;上面的两个查询也是返回相同的结果，但后面的查询将比前面的一个快很多。 第三，在搜索字符型字段时，我们有时会使用 LIKE 关键字和通配符，这种做法虽然简单，但却也是以牺牲系统性能为代价的。 例如下面的查询将会比较表中的每一条记录。 SELECT * FROM booksWHERE name like MySQL%但是如果换用下面的查询，返回的结果一样，但速度就要快上很多：SELECT * FROM booksWHERE name>=MySQLand name

如何做SQL Server性能测试

对于DBA来讲，我们都会做新服务器的性能测试。 我会从TPC的基准测试入手，使用HammerDB做整体性能评估（前身是HammerOra），跟厂商数据对比。 再使用DiskSpd针对性的测试磁盘IO性能指标（前身是SQLIO），再到SQLIOSIM测试存储的完整性，再到ostress并发压力测试，对于数据库服务器迁移，我们还会收集和回放Profiler Trace，并收集期间关键性能计数器做对比。 下面我着重谈谈使用HammerDB的TPC-C来做SQL Server基准测试。 自己写负载测试代码很困难为了模拟数据库的负载，你想要有多个应用程序用户和混合数据读写的语句。 你不想总是对单一行更新相同的值，或者只是重复插入假的值。 自己动手使用Powershell、C#等语言写负载测试脚本也不是不可能，只是太消耗时间，你需要创建或者恢复数据库，并做对应的测试。 免费而简单的压测SQL Server：使用HammerDB模拟OLTP数据库负载HammerDB是一个免费、开源的工具，允许你针对SQL Server、Oracle、MySQL和PostgreSQL等运行TPC-C和TPC-H基准测试。 你可以使用HammerDB来针对一个数据库生成脚本并导入测试。 HammerDB也允许你配置一个测试运行的长度，定义暖机阶段，对于每个运行的虚拟用户的数量。 首先，HammerDB有一个自动化队列，让你将多个运行在不同级别的虚拟用户整合到一个队列--你可以以此获得在什么级别下虚拟用户性能平稳的结果曲线。 你也可以用它来模拟用于示范或研究目的的不同负载。 用于SQL Server上的HammerDB的优缺点HammerDB是一个免费工具，它也极易访问和快速的启动基准测试和模拟负载的方法。 它的自动程序特性也是的运行工作负载相当自动。 主要缺点是它有一个学习曲线。 用户界面不是很直观，需要花费时间去习惯。 再你使用这个工具一段时间之后，将会更加容易。 HammerDB也不是运行每一个基准测试。 它不运行TPC-E基准，例如，SQL Server更热衷于当前更具发展的OLTP基准TPC-E。 如果你用HammerDB运行一个TPC-C基准，你应该理解它不能直接与供应商提供的TPC-C基准结果相比较。 但是，它是免费的、快速的、易用的。 基准测试使用案例基准测试负载不能精确模拟你的应用程序的特点。 每个负载是唯一的，在不同的系统有不同的瓶颈。 对于很多使用案例，使用预定义的基准测试仍然是非常有效的,包括以下性能的比较：多个环境（例如：旧的物理服务器，新的虚拟环境）使用各种因素的不同及时点（例如：使用共享存储和共享主机资源的虚拟机的性能）在配置改变前后的点当然，对一个数据库服务器运行基准测试可以影响其他SQL Server数据库或者相同主机上其他虚拟机的性能，在生产环境你确保有完善的测试计划。 对于自学和研究来说，有预配置的负载非常棒。 开始使用基准测试你可以从阅读HammerDB官方文档的“SQL Server OLTP Load Testing Guide”开始。