sp_executesql先容和利用

BDB源自BerkeleyDB，事务型数据库的另一种选择，支持COMMIT和ROLLBACK等其他事务特性sp_executesql先容和利用
sp_executesql
实行能够屡次重用或静态天生的Transact-SQL语句或批处置。Transact-SQL语句或批处置能够包括嵌进参数。
语法
sp_executesql[@stmt=]stmt
[
{,[@params=]N@parameter_namedata_type[,...n]}
{,[@param1=]value1[,...n]}
]
参数
[@stmt=]stmt
包括Transact-SQL语句或批处置的Unicode字符串，stmt必需是能够隐式转换为ntext的Unicode常量或变量。不同意利用更庞大的Unicode表达式（比方利用+运算符串连两个字符串）。不同意利用字符常量。假如指定常量，则必需利用N作为前缀。比方，Unicode常量Nsp_who是无效的，可是字符常量sp_who则有效。字符串的巨细仅受可用数据库服务器内存限定。
stmt能够包括与变量名情势不异的参数，比方：
NSELECT*FROMEmployeesWHEREEmployeeID=@IDParameter
stmt中包括的每一个参数在@params参数界说列表和参数值列表中均必需有对应项。
[@params=]N@parameter_namedata_type[,...n]
字符串，个中包括已嵌进到stmt中的一切参数的界说。该字符串必需是能够隐式转换为ntext的Unicode常量或变量。每一个参数界说均由参数名和数据范例构成。n是标明附加参数界说的占位符。stmt中指定的每一个参数都必需在@params中界说。假如stmt中的Transact-SQL语句或批处置不包括参数，则不必要@params。该参数的默许值为NULL。
[@param1=]value1
参数字符串中界说的第一个参数的值。该值能够是常量或变量。必需为stmt中包括的每一个参数供应参数值。假如stmt中包括的Transact-SQL语句或批处置没有参数，则不必要值。
n
附加参数的值的占位符。这些值只能是常量或变量，而不克不及是更庞大的表达式，比方函数或利用运算符天生的表达式。
前往代码值
0（乐成）或1（失利）
了局集
从天生SQL字符串的一切SQL语句前往了局集。
正文
在批处置、称号感化域和数据库高低文方面，sp_executesql与EXECUTE的举动不异。sp_executesqlstmt参数中的Transact-SQL语句或批处置在实行sp_executesql语句时才编译。然后编译stmt中的内容并作为实行企图运转（自力于名为sp_executesql的批处置的实行企图）。sp_executesql批处置不克不及援用挪用sp_executesql的批处置中声明的变量。sp_executesql批处置中的当地游标和变量对换用sp_executesql的批处置是不成见的。对数据库高低文所作的变动只在sp_executesql语句停止前无效。
假如只变动了语句中的参数值，则sp_executesql可用来取代存储历程屡次实行Transact-SQL语句。由于Transact-SQL语句自己坚持稳定仅参数值变更，以是Microsoft

是否碎片会引发效率问题？这都是需要进一步探讨的工具。varbinary(max)代替image也让SQLServer的字段类型更加简洁统一。

而写到本地,我又考虑到效率问题.大家来讨论讨论吧,分数不打紧,就给10分,十全十美,没啥对错,各抒己见,但是要有说服力的哦~

如安全管理、备份恢复、性能监控和调优等，SQL只要熟悉基本操作就可以，只要程序设计部分只要稍加了解即可（如存储过程、触发器等）。

分区表是个亮点！从分区表也能看出微软要做大作强SQLServer的信心。资料很多，这里不详细说。但是重点了解的是：现在的SQLServer2005的表，都是默认为分区表的。因为它要支持滑动窗口的这个特性。这种特性对历史数据和实时数据的处理是很有帮助的。

是否碎片会引发效率问题？这都是需要进一步探讨的东西。varbinary(max)代替image也让SQLServer的字段类型更加简洁统一。

多走走一此相关论坛，多看一些实例开发，多交流0经验，没什么的，我也是刚学没多久!加油

原来的计算字段其实和虚拟字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了计算字段的持久化，这就提高了查询的性能，但是会加重insert和update的负担。OLTP慎用。OLAP可以大规模使用。

Mirror可以算是SQLServer的Dataguard了。但是能不能被大伙用起来就不知道了。