1. sql server中，N''表示什么意思
N'string' 表示string是个Unicode字符串
Unicode 字符串的格式与普通字符串相似，但它前面有一个 N 标识符（N 代表 SQL-92 标准中的国际语言 (National Language)）。N 前缀必须是大写字母。例如，'Michél' 是字符串常量而 N'Michél' 则是 Unicode 常量。Unicode 常量被解释为 Unicode 数据，并且不使用代码页进行计算。Unicode 常量确实有排序规则，主要用于控制比较和区分大小写。
Unicode字符串常量支持增强的排序规则。
(1)sql数据类型前缀扩展阅读：
Unicode是国际组织制定的可以容纳世界上所有文字和符号的字符编码方案。目前的Unicode字符分为17组编排，0x0000 至 0x10FFFF，每组称为平面（Plane），而每平面拥有65536个码位，共1114112个。然而目前只用了少数平面。UTF-8、UTF-16、UTF-32都是将数字转换到程序数据的编码方案。
通用字符集（Universal Character Set, UCS）是由ISO制定的ISO 10646（或称ISO/IEC 10646）标准所定义的标准字符集。UCS-2用两个字节编码，UCS-4用4个字节编码。
历史上存在两个独立的尝试创立单一字符集的组织，即国际标准化组织（ISO）和多语言软件制造商组成的统一码联盟。前者开发的 ISO/IEC 10646 项目，后者开发的统一码项目。因此最初制定了不同的标准。
2. SQL Server数据库中的系统表的表名通常以什么为前缀
SQL Server数据库中的系统表的表名通常以sys为前缀
3. transact-sql支持的变量有几种分别用什么前缀来标识
变量只有2种
全局变量：又称系统变量，格式为@@变量名
自定义变量：即用户变量,格式为@变量名
4. SQL Server的常用数据类型（字符型）有哪些
对于程序中的string型字段，SQLServer中有char、varchar、nchar、nvarchar四种类型来对应（暂时不考虑text和ntext），开建立数据库中，对这四种类型往往比较模糊，这里做一下对比。
定长或变长
所谓定长就是长度固定的，当输入的数据长度没有达到指定的长度时将自动以英文空格在其后面填充，使长度达到相应的长度；有var前缀的，表示是实际存储空间是变长的，比如varchar,nvarchar变长字符数据则不会以空格填充，比较例外的是，text存储的也是可变长。
Unicode或非Unicode
数据库中，英文字符只需要一个字节存储就足够了，但汉字和其他众多非英文字符，则需要两个字节存储。如果英文与汉字同时存在，由于占用空间数不同，容易造成混乱，导致读取出来的字符串是乱码。Unicode字符集就是为了解决字符集这种不兼容的问题而产生的，它所有的字符都用两个字节表示，即英文字符也是用两个字节表示。而前缀n就表示Unicode字符，比如nchar,nvarchar，这两种类型使用了Unicode字符集。
基于以上两点来看看字段容量
char，varchar 最多8000个英文，4000个汉字
nchar，nvarchar 可存储4000个字符，无论英文还是汉字
使用(个人偏好)
如果数据量非常大，又能100%确定长度且保存只是ansi字符，那么char
能确定长度又不一定是ansi字符或者，那么用nchar；
对于超大数据，如文章内容，使用nText
其他的通用nvarchar
char、varchar、nchar、nvarchar特点比较
CHAR
CHAR存储定长数据很方便，CHAR字段上的索引效率级高，比如定义char(10)，那么不论你存储的数据是否达到了10个字节，都要占去10个字节的空间。
VARCHAR
存储变长数据，但存储效率没有CHAR高,如果一个字段可能的值是不固定长度的，我们只知道它不可能超过10个字符，把它定义为 VARCHAR(10)是最合算的。VARCHAR类型的实际长度是它的值的实际长度+1。为什么"+1"呢？这一个字节用于保存实际使用了多大的长度。
从空间上考虑，用varchar合适；从效率上考虑，用char合适，关键是根据实际情况找到权衡点。
TEXT
text存储可变长度的非Unicode数据，最大长度为2^31-1(2,147,483,647)个字符。
NCHAR、NVARCHAR、NTEXT
这三种从名字上看比前面三种多了个"N"。和char、varchar比较起来，nchar、nvarchar最多存储4000个字符，不论是英文还是汉字；而char、varchar最多能存储8000个英文，4000个汉字。可以看出使用nchar、nvarchar数据类型时不用担心输入的字符是英文还是汉字，较为方便，但在存储英文时数量上有些损失。
所以一般来说，如果含有中文字符，用nchar/nvarchar，如果纯英文和数字，用char/varchar
5. 如何用sql语句把某一列的所有值前面加一个前缀
修改(为该列的值加上前缀-修改数据库):
update table set column1=concat('wz',column1) where column='xxxx'
查询加上前缀（不修改数据库）：
select *，concat('wz',column1) as column1 from table where column='xx'
6. SQL什么符号开头的变量是局部变量
局部变量必须以标记@作为前缀 ，如@age 局部变量的使用也是先声明，再赋值。
局部变量局部变量是用户可自定义的变量，它的作用范围仅在程序弯禅内部。在程序中通常用来储存从表中查询到的数据，或当作程序执行过程中暂存变量使用。局部变量必须以“@”开头，而且必须先用埋激尘DECLARE命令说明后才可使用。
其说明形式如下：DECLARE @变量名 变量类型 [@变量名 变量类型…]其中变量类型可以是sql server(WINDOWS平台上强大的数据库平台) 2000支持的所有数据类型，也可以是用户自定义的数据类型。铅镇DECLARE命令的详细用法请参见“4.6其它命令”。
7. SQL系统存储过程名字以什么为前缀 cp_ ZP_ SP_ XP_
1系统存储过程以sp_开头,用来进行系统的各项设定.取得信息.相关管理工作。
2本地存储过程
用户创建的存储过程是由用户创建并完成某一特定功能的存储过程，事实上一般所说的存储过程就是指本地存储过程。
3临时存储过程
分为两种存储过程：
一是本地临时存储过程，以井字号(#)作为其名称的第一个字符，则该存储过程将成为一个存放在tempdb数据库中的本地临时存储过程，且只有创建它的用户才能执行它;
二是全局临时存储过程，以两个井字号(##)号开始，则该存储过程将成为一个存储在tempdb数据库中的全局临时存储过程，全局临时存储过程一旦创建，以后连接到服务器的任意用户都可以执行它，而且不需要特定的权限。
4远程存储过程
在SQL Server2005中，远程存储过程(Remote
Stored Proceres)是位于远程服务器上的存储过程，通常可以使用分布式查询和EXECUTE命令执行一个远程存储过程。
5
扩展存储过程
扩展存储过程(Extended Stored
Proceres)是用户可以使用外部程序语言编写的存储过程，而且扩展存储过程的名称通常以xp_开头。
8. sql语句什么情况下使用N前缀
一开始就提到了与数据源无关的问题。当时只是从泛化的角度出发，利用ADO.net的DbProviderFactory根据不同的数据提供程序的名称来实现一个与数据库无关的数据访问基类。但仅仅做到这一步还不能实现真正意义上的与数据源无关。 在程序的开发过程中，如果不考虑使用DbParameter的情况，绝大部分应用都可以用Transact-SQL来搞定，而不需要用到与具体数据源相关的特性。但是，现实总是比较残酷的。DbParameter的应用也是如此广泛，最容易想到的情况就是利用DbParameter来防止注入和用来处理一些不容易写在SQL语句中的值。SQL语句中的参数名随着数据提供程序的不同，也会不同，MS SQL Server用的是“@”，Oracle用的是“:”，到了OleDb基本清一色地改成了“?”。如果不解决这个问题，就没法做到真正的与数据源无关。 如果用NHibernate，可以考虑HQL来解决此问题。HQL代替SQL再经过NHibernate的词法分析器处理，转换为SQL语句。如此一下，就不必考虑数据提供程序的参数前缀到底是啥了。可是本人始终不太喜欢NHibernate（从看到Hibernate时候开始），觉得配置文件太多了，而且体系又比较庞大，因此总寻思着怎么干些所谓的“重复造轮子”的事情。本人的想法很简单，咱不发明新语言，只是简单地针对那绝大部分的情况，将使用Transact-SQL的开发时，把语句中那些五花八门的参数名统一使用“@”，在执行的时候根据具体的数据提供程序进行替换。如此一来，既可以满足与数据源无关的目标，又不需要费太多的力气。 首先要考虑的问题是，如何获取参数的前缀。可以用这个方式来获取参数的前缀“DbConnection.GetSchema("DataSourceInformation").Rows[0]["ParameterMarkerFormat"]”。摘一段MSDN的说明：ParameterMarkerFormat表示如何格式化参数的格式化字符串。如果数据源不支持命名的参数，此字符串中的第一个占位符应是格式化参数名的位置。例如，如果数据源期望使用‘:’为前缀命名参数，此字符串将为“:{0}”。在使用参数名“p1”格式化此字符串时，生成的字符串为“:p1”。如果数据源期望参数以‘@’为前缀，但是名称中已包含该符号，此字符串将为‘{0}’，格式化名为“@p1”的参数的结果将只是“@p1”。如果数据源不期望使用命名参数，而期望使用‘?’字符，格式字符串可以只指定为‘?’，这样将忽略参数名。对于 OLE DB，将返回‘?’。更详细的信息可以参考MSDN中的“通用架构集合 (ADO.NET)”。按照之前的说法，有了参数前缀后，剩下的问题就是如何将SQL语句和DbParameter.ParameterName中的“@”替换掉。DbParameter.ParameterName比较简单，直接String.Replace就OK，但是SQL语句中的情况比较复杂。“@”可能不仅仅出现在参数名中，也可能出现在字符里。简单的Replace可能无法满足要求。最初觉得比较好的做法有2种：正则表达式和词法分析器。但后来考虑到，字符串中 “@” 出现的情况也相当难以预料且参数名比较特殊，为了支持一些特殊字符（比如：中文<总觉得有些人喜欢用>），再加上之前用Antlr2实现了一个基本的Select词法分析器，所以就不考虑使用正则表达式，而是直接在之前的基础上做了些简化，生成了一个仅针对参数的词法分析器。因为有Select语句词法分析器的基础，所以搞定参数的时候就简单得多了。参数的规则可以定义为“@”+标识符，antlr2所需的主要规则2条：1、标识符：(('_' | 'a'..'z' | 'A'..'Z' | '\u2e81'..'\u2eca' |'\u3447'..'\u4dae' | '\u4e00'..'\u9fa5' | '\uf92c'..'\ufa29')+ ('0'..'9' | 'a'..'z' | 'A'..'Z' | '_' | '\u2e81'..'\u2eca' |'\u3447'..'\u4dae' | '\u4e00'..'\u9fa5' | '\uf92c'..'\ufa29')*) {$setType(Token.SKIP);}2、参数：('@' N_QUOTED_STRING)=>(('@' N_QUOTED_STRING) {_ttype=PARAMETER;}) | (('@' '@' N_QUOTED_STRING)=>('@' '@' N_QUOTED_STRING){_ttype=SYS_VAR;$setType(Token.SKIP);}) | (':' N_QUOTED_STRING)=>((':' N_QUOTED_STRING) {_ttype=PARAMETER;}) | '?'还必须注意的是，要替换的目标只是参数，所以没有必要将其他如：保留字、字符串、数字、符号之类的东西取出来，通通加上“{$setType(Token.SKIP);}”跳过之。 利用词法分析器对SQL语句进行解析，逐个替换掉原来SQL语句中的参数，最后得到的就是可以在目标数据源上执行的SQL语句。虽然有人会提出说，如果执行1000条SQL语句，那不是得执行1000此解析、替换，效率何存？但是，按照经验来说，1次执行1000条SQL语句一般情况下只是参数的值不同，但SQL语句本身并不会有什么差异；如果使用实体进行持久化，碰到这种情况的几率更加减少。所以，本人认为，上述这种替换的做法还是可取的，特别是在某些情况下，一个应用程序运行在两套不同的数据库上时（连线时用服务器数据Oracle，离线时暂时使用本地Access数据库），这个做法就更能显示出它的价值了。