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資料庫），這個做法就更能顯示出它的價值了。