データ型の優先順位 により、これは完全に予測可能であり、予想されます。
このため、UI 列は decimal(25,0) に変更されます
where UI = 2011040773395012950010370
こちらはほぼ正解です。右側は varchar で、nvarchar に変更されます
where UI = '2011040773395012950010370'
これは本当に 両方のタイプが同じ正しいバージョン
where UI = N'2011040773395012950010370'
UI 列に decimal(25,0) にキャストされない値が含まれるため、エラーが発生します。
関連のないメモ:
- UI 列にインデックスがある場合、暗黙の CAST が必要なため、最初のバージョンでは無視されます
- 数字を格納するために Unicode が必要ですか? 深刻なオーバーヘッド があります ストレージとパフォーマンスに Unicode データ型を使用
char(25)を使用しない理由 またはnchar(25)値は常に固定長ですか?あなたのクエリは 多すぎますオプティマイザとしてのメモリnvarchar(256)に基づいて、平均の長さを 128 文字と想定しています
編集、コメントの後に
わからない場合でも、「なぜうまくいくのか」と思い込まないでください。 それが機能すること
例:
- 値が削除され、後で追加された可能性があります
- TOP 句または SET ROWCOUNT は、問題の値に達していないことを意味する可能性があります
- クエリは実行されていないため、失敗することはありません
- エラーは他のコードによって黙って無視されますか?
うまくいけばより明確にするために2を編集
チャット
gbn:
ランダム:
gbn
タオが言及したように 、これが問題なくても、別の無関係なクエリがクエリを壊す可能性があることを理解することが重要です.