优化存储过程有很多种方法，下面介绍最常用的7种。

1.使用SET NOCOUNT ON选项

我们使用SELECT语句时，除了返回对应的结果集外，还会返回相应的影响行数。使用SET NOCOUNT ON后，除了数据集就不会返回额外的信息了，减小网络流量。

2.使用确定的Schema

在使用表，存储过程，函数等等时，最好加上确定的Schema。这样可以使SQL Server直接找到对应目标，避免去计划缓存中搜索。而且搜索会导致编译锁定，最终影响性能。比如select * from dbo.TestTable比select * from TestTable要好。from TestTable会在当前Schema下搜索，如果没有，再去dbo下面搜索，影响性能。而且如果你的表是csdn.TestTable的话，那么select * from TestTable会直接报找不到表的错误。所以写上具体的Schema也是一个好习惯。

如果能从备份文件中只恢复一个表的数据，那不是很好吗？比如，你备份了AdventureWorks数据库，现的你只恢复里面Vendor表数据。不幸的是，SQL Server本身并不支持这样还原，你需要从第三方提供的工具中来执行这样的任务。

提供这种功能的程序都是一些SQL Server第三方备份工具。它们可以让你从备份文件中抽取或是读取单个表数据。

但是这里有一点要注意是，假如你选择恢复一个完整数据库，那么你选择要恢复的数据有可能与你获取的数据不同。原因就是因为当你执行完整数据库备份时，备份文件包括数据文件和事务日志文件。有一些已经提交的事务还没有写入数据文件，在这种情况下，事务仅仅存储在事务日志中，或者部份数据存储在数据文件。当你使用第三方程序恢复所选择的单表数据时，仅仅只能从备份文件中的数据库文件中获取数据，事务日志中的新数据将会被忽略。

SQL Server在msdb数据中维护了一系列表，用来存储执行所有备份和还原的细节信息。即使你正在使用第三方的备份应用程序，只要这个应用程序使用SQL Server的虚拟设备接口(Virtual Device Interface---VDI)来执行备份和还原执行，那么执行细节依然被存储在这一系列表中。

存储细节的表包括：

backupset 
backupfile 
backupfilegroup (SQL Server 2005 upwards)
...

你遇到的最糟糕的事莫过于备份文件无法还原数据库了。我这里并不是说缺少磁盘空间或者类似的事导致的无法还原，而是一个100%确认已经被损坏的备份文件。你会问，那我怎么办呢？别着急，SQL Server有一个完善的还原功能来验证备份文件。

举个例子，当你第一次创建了一个备份文件，它应该是好的，但这仅仅是“应该”。每一次，这个文件被拷贝到另一个地方时，文件就会存在被损坏的风险。确认这个备份文件可以继续使用的最好的方法就是还原它，然后立即运行DBCC CHECKDB。如果当时条件不允许持续还原和检查，那么使用RESTORE VERIFYONLY命令就是你另一个最好的选择了。