語法結構：
1. Cast
語法結構：CAST ( expression AS data_type [ ( length ) ] )
2. Convert
語法結構：CONVERT ( data_type [ ( length ) ] , expression [ , style ] )
3. Parse
語法結構：PARSE ( string_value AS data_type [ USING culture ] )
其中，Parse 為 Sql Server 的新特性 expression 必須要為被轉換類型的字符串形式
性能分析：
總結：
1. Convert 和 Cast 的區別
CONVERT是專對SQL Server使用的，使日期與時間值，小數之間轉換具有更寬的靈活性。
CAST是兩種功能中更具ANSI標準的功能，即雖然更具便攜性（比如，使用CAST的函數能更容易的被其它數據庫軟件使用），但功能相對弱一些。不過，當小數轉化為數值，并保留原始表達式中的小數數值時，仍然需要使用CAST
2. Convert 和 Parse 的區別
兩者除了語法的區別，就是功能上面的區別，Convert 功能更強大，Parse 則為 Sql Server 2012 新增的功能，同時功能弱小很多的，只能將 字符串 轉換為 數字類型 或者 日期類型，因為數字類型 或 日期類型長度都很小的，所以 Parse 所帶來的性能幾乎不可能有大的改變的，之后我也做了大量的比較，發現 Parse 是在絕大多數情況下都是可以替代的
3. 綜合比較
a. 如果 是做針對 Sql Server 的做開發，建議只用 Convert 方法
b. 如果考慮語句跨平臺，則盡量用 Cast，如 SQL 語句既能在 Sql Server 上執行，又能在 MySql 上面執行
c. Parse 在 Sql Server 2012 中就是一個雞肋，經過1 下午的實戰研究和翻閱MSDN，都沒有找到它的優勢，如果比語法，Cast 的語法結構和它一樣，如果比功能，又太弱小，完全不能和Cast 和 Convert 做比較，所以，您就把 Parse 忘記掉吧
性能分析所做的實驗：
1. Convert 和 Parse 轉換為字符串的比較
復制代碼 代碼如下:
DBCC FreeProcCache
set statistics profile on
select top 1 parse(name as bigint) from test_Parse
select top 1 convert(bigint,name) from test_Parse
其中 name 為 nvarchar(1000) 的一個一段，值為：1231238912378912128
執行過之后，會發現，兩者的執行計劃完全相同，無論是對 CPU 的消耗，還是對 IO的消耗，沒有任何性能差別
2. Money 和 DateTime 類型的轉換比較
復制代碼 代碼如下:
-- DateTime
DBCC FreeProcCache
declare @date varchar(100) = '2012/07/19 14:57:09.760'
select CONVERT(datetime,@date) as date
select Parse(@date as datetime using 'zh-CN') as date
--Money
SELECT PARSE('345,98' AS money USING 'de-DE') AS Result
Select Convert(money,'345,98',1) AS Result
3. Parse 的專利，字符型日期到 datetime 的轉換
復制代碼 代碼如下:
SELECT PARSE('Monday, 13 December 2010' AS datetime2 USING 'en-US') AS Result
SELECT PARSE('Monday, 13 December 2010' AS datetime2 USING 'zh-CN') AS Result
-- Cast 和 Convert 對這種類型的字符串都是不支持的
--SELECT cast('Monday, 13 December 2010' AS datetime2) AS Result
--SELECT Convert(datetime,'Monday, 13 December 2010') AS Result
在性能方面同樣沒什么區別，但是比較功能時，Parse 卻要比 Convert 錯太多
嚴重懷疑， Parse 本人并沒有找到太多的優勢和應用場景，或者由于本人才疏學淺，找不到更好的，有懂得，請賜教
