為什麼SQL的篩選條件的字串多加一個N，就會造成Select出來的資料順序跟沒加N的不同呢?
今天同事在詢問說為什麼SQL的篩選條件的字串多加一個N，就會造成Select出來的資料順序跟沒加N的不同呢? 如下，
看來是因為隱含轉換所以SQL選擇的執行計畫不同，所以就選擇了不同的Index，就造成結果的順序不同(該Where欄位為Char(10))，如下，
那要如何解決呢?
其實最好的是加在Order By中去明確要由那個欄位排序，就不會有這種問題! 不然，那裡會知道那天SQL會不會選另一個Index呢?
但是因為這個專案是說要跟舊系統的資料順序一樣(加上Index也跟舊的順序不同)!
所以......那就不要讓查詢條件加上N呀~~
但問題又來了，因為敝公司的底層元件在設定置換參數時，一設定Unicode就會自動加上N ~~
所以另一個解法是，再把它Convert成Char(10)，如下，
AND HRM833.CMPCOD = N'A0XXX'
改成
AND HRM833.CMPCOD = CAST(N'A0XXX' AS CHAR(10))
資料的順序就跟舊系統產生出來的一致了!
原本以為這樣就OK了! 但是將結果Insert到Temp Table之中，又不對了~~
於是測試了一下，如果先建立Temp Table再 Insert Into … Select … ，資料順序就不對。
如果直接 Select …. Into …. 就OK。 但如果使用 Select … Into … 的方式，SQL 有些就要調整…….
後來測試，如果在建立Temp Table時，多加入 Identity 的欄位，順序就對了，如下，
所以下次如果有相似的問題，可以查一下執行計畫，或是在建立Temp Table時，多加入 Identity 的欄位哦!
當然，最好還是要什麼排序，還是要定義清楚，寫在Order By之中。
Hi,
亂馬客Blog已移到了 「亂馬客 : Re:從零開始的軟體開發生活」
請大家繼續支持 ^_^
