朋友的一個checksum計算列建立的索引：

在數(shù)據(jù)庫設計中需要一列標注網(wǎng)頁的URL地址，LINK NVARCHAR(1000）。在INSERT的時候需要判斷之前有無同樣的URL地址記錄被插入。
也就是用select top 1 @ID=ID from Table where Link=@Link，然后判斷@ID值是否大于0。
如果數(shù)據(jù)量過大，需要給LINK加為索引，但是這時會發(fā)現(xiàn)SQL SERVER的索引對那么大的NVARCHR是無法建立的，限制在200字符以內(nèi)。
我在最早的時候解決這個問題是采用了對LINK進行MD5化，MD5的值只有幾十個字符長，然后對MD5結果進行索引。但這樣做性能其實一般，而且大字段的數(shù)據(jù)庫索引同樣會占用不少存儲空間。
其實在SQL SERVER中可以設置計算字段，就是說該字段是可以是其他字段的計算結果。這樣的話就用CHECKSUM來優(yōu)化上述的索引問題。
做法范例:

      alter table tablename add csLink as CHECKSUM(Link)。
    

?

這樣就建立一個csLink列，生成的CHECKSUM值是一個大的整數(shù)。對該列進行索引，相當于對BITINT型進行索引，索引存儲空間也非常節(jié)約。這樣在判別有無重復LINK的時候就使用:

      select top 1 @ID=ID from Table where csLink=CHECKSUM(@Link) And Link=@Link
    

?

數(shù)據(jù)庫會優(yōu)先判斷csLink索引字段，而實際測試100萬條記錄的CHECKSUM，無一重復，所以第一次匹配的返回條數(shù)是極少的，基本可以做到一批匹配，而考慮肯能會有重復記錄，因此再加上And Link=@Link，這樣是在小的數(shù)據(jù)集中再次做無索引匹配，這樣性能損耗幾乎沒有感覺。

計算字段給我感覺就好像視圖，計算字段的靈活度除了簡化查找SELECT語句之外，對索引優(yōu)化的作用是非常大的。CHECKSUM的用法只是發(fā)現(xiàn)之一，在今后一定會發(fā)現(xiàn)更多的有用的TIPS

checksum建立的索引