ユーザーのGUIDと実際の名前を文字列で保持するテーブルがあります。私はユーザーに基づいていくつかの情報を取得したいと思います。しかし、どのフィールドを使うべきですか？コードは次のようにします：uniqueidentifierやtsqlの文字列を比較する方が速いのはどれですか？
select *
from userinboxcount
where countDate >= startDate and countDate <= endDate and userid = '<guid here>'
or
select *
from userinboxcount
where countDate >= startDate and countDate <= endDate and username = "FirstName LastName"
最も大きな違いは、1つのフィールドにデータベースで使用できるインデックスがあり、もう1つのフィールドにインデックスがない場合です。値をスキャンするためにデータベースがテーブル内のすべてのデータを読み取る必要がある場合、ディスクアクセスには多くのリソースが必要なため、データ型の違いは関係ありません。
両方のフィールドにインデックスが設定されている場合、インデックスのサイズが小さくなると、読み込みが高速になり、キャッシュに残る可能性が高くなります。
理想的には、条件に含まれるすべてのフィールドのインデックスがあります。このインデックスには、含まれているフィールドとして返すフィールドがあります。このようにして、クエリはインデックスのみから結果を生成することができ、実際のテーブルから読み込む必要はありません。もちろん、select *は使用しないでください。ただし、実際に返す必要のあるフィールドを指定してください。
それ以外の場合は、単純な数値比較であり、レキシカルルールを考慮する必要がないため、GUID値を比較する方がいくぶん高速です。
クエリプランを参照すると、あなた自身でそれを見ることができます。
しかし、一意識別子には通常インデックスがあり、文字列（username）には含まれていない可能性があります。もしそうなら、多くのレコードがあれば、一意的な識別子がより早くなるでしょう！
クエリプランには、THISの記事をチェックしてください。
useridがプライマリキーの場合は、それを使用する必要があります。姓と名字を使用する場合はにはに2つのJohn Smithエントリがある可能性があり、問題が発生する可能性があります。 PKの使用はより安全でなければなりません
パフォーマンス側では、クエリの実行計画（実行パス？）に精通することをお勧めします。私はuseridを使う方が早いだろうと思っていますが、計画をチェックすることで確実にあなたに伝えるべきです。
GUIDで十分です。
1. GUID will produce unique values in the table.
2. Create Non Clustered Index on this column.
あなたは、GUIDを完全に結婚していますか？複数のシステムで一意のプライマリキーが必要な場合は、GUIDを使用する必要があります。私は、GUIDをスキップし、複合キーを使用することをお勧めします。たとえば、複合キーとしてIDとGETDATE（）を使用できます。これにより、データを簡単に照会できます（整数以上のGUIDを覚えてみてください）。これはGUIDよりもはるかに優れたパフォーマンスを発揮します。恐らく2倍の速さでしょう。
ええ、guidとユーザー名はサードパーティ製のテーブル/ソフトウェアからのものです。 – dotnetN00b