回答:
1）はい、選択NOLOCK速く、通常の選択よりも完了します。
2）はい、あります。選択をNOLOCK使用すると、影響を受けるテーブルに対する他のクエリが通常の選択よりも速く完了します。
これはなぜでしょうか？
NOLOCK通常（DBエンジンによって異なります）はデータを提供することを意味します。データがどのような状態にあるかは気にしません。また、データを読み取っている間も気にしないでください。一度に速く、リソースをあまり消費せず、非常に危険です。
システムクリティカルな更新、またはNOLOCK読み取りから発生したデータを使用して絶対的な正確さが要求される場合は、絶対に更新を行わないでください。このデータには、クエリの実行中に削除された行、またはまだ確定されていない他のセッションで削除された行が含まれている可能性があります。このデータには、部分的に更新された行が含まれている可能性があります。このデータには、外部キーの制約に違反するレコードが含まれている可能性があります。このデータから、テーブルに追加されたがまだコミットされていない行が除外される可能性があります。
データの状態を知る方法はありません。
行数やその他の要約データなど、ある程度の誤差が許容できるものを取得しようとしている場合NOLOCKは、これらのクエリのパフォーマンスを向上させ、データベースのパフォーマンスに悪影響を与えないようにするための良い方法です。
NOLOCKヒントは常に細心の注意を払って使用し、返されたデータは疑わしく処理してください。
共有ロックがないため、NOLOCKを指定すると、ほとんどのSELECTステートメントが高速になります。また、ロックが発行されないことは、ライターがSELECTによって妨害されないことを意味します。
NOLOCKは、機能的にはREAD UNCOMMITTEDの分離レベルと同等です。主な違いは、選択した場合、一部のテーブルではNOLOCKを使用できるが、他のテーブルでは使用できないことです。複雑なクエリのすべてのテーブルでNOLOCKを使用する場合は、すべてのテーブルにヒントを適用する必要がないため、SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTEDを使用する方が簡単です。
これは、自由に使用できるすべての分離レベルと、テーブルのヒントに関する情報です。
上記の内容に加えて、nolockは実際には、selectの前にコミットされた行を取得しないというリスクがあることを十分に認識しておく必要があります。
http://blogs.msdn.com/sqlcat/archive/2007/02/01/previously-committed-rows-might-be-missed-if-nolock-hint-is-used.aspxを参照してください
ロックを待つ必要がないため、より高速になります。
各トランザクションは他のトランザクションが完了するのを待つ必要がないため、クエリが一度に複数回実行される場合、答えは「はい」です。ただし、クエリが1回で実行されると、答えは「いいえ」になります。
はい。WITH（NOLOCK）を注意深く使用すると、データベース全体の速度が上がる可能性がかなりあります。つまり、他のトランザクションはこのSELECTステートメントの終了を待つ必要はありませんが、その一方で、他のトランザクションは新しいトランザクションと処理時間を共有しているため、速度が低下します。
のみに注意してくださいWITH (NOLOCK)クラスタ化インデックスを持つテーブルのSELECTステートメントで使用するように。
WITH（NOLOCK）は、データベースの読み取りトランザクションを高速化する魔法の方法としてよく利用されます。
結果セットには、まだコミットされていない、後でロールバックされることが多い行を含めることができます。
WITH（NOLOCK）が非クラスター化インデックスを持つテーブルに適用される場合、行データが結果テーブルにストリーミングされるときに、他のトランザクションによって行インデックスが変更される可能性があります。これは、結果セットが行を欠落するか、同じ行を複数回表示する可能性があることを意味します。
READ COMMITTEDは、複数のユーザーが同じセルを同時に変更する単一の列内でデータが破損するという追加の問題を追加します。