Remusが指摘したように、質問は一般的すぎて答えを得ることができません。答えは、使用する機能のコンテキストと使用方法に依存するためです。
「セキュリティ」について：
PERMISSION_SET = SAFEでマークされたアセンブリで実行できることについて質問している場合、私がこれまでに発見した問題はありません。そして、SQLCLRはxp_cmdshellまたはすばらしい（皮肉な）sp_OA* procs（または拡張ストアドプロシージャ）を使用するよりも「安全」ですが、誰も作成していないことを願っています。
「SAFE」が実際に何を意味するかについてのウォークスルーが必要な場合は、次の記事を参照してください。 SQLCLRレベル3への階段：セキュリティ（一般およびSAFEアセンブリ） （無料登録が必要です）。
PERMISSION_SET = EXTERNAL_ACCESSでマークされたアセンブリで実行できることについて質問する場合、使用されている機能に応じて、確かにリスクがあります。ディレクトリとファイル名を読み取るルーチン（つまり、読み取り専用）を作成する場合、何を表示するか、何を表示しないかが問題になります。ファイルを削除できるコードを記述している場合、リスクが高まります。しかし、これらの外部リソースでできることは、以下によって制御されます。
- 偽装を使用しているかどうか：
- 偽装がないことは、外部リソースへのアクセスがSQL Serverサービスの「ログオン」アカウントを介して行われることを意味します。そのアカウントがアクセスできるものは何でも、SQLCLR関数で実行できます。
- 偽装の使用とは、関数を実行しているSQL Serverでのログインが、そのログインがWindowsログインに対応している場合、特定のWindowsログインで許可されていることをすべて実行できることを意味します。 SQL ServerのログインがSQL Serverログインの場合、偽装を使用しようとするとエラーが発生します。
- 外部リソースに設定されている権限。ファイルシステムアクセスの場合、これはNTFSドライブのACLによって制御されます。
PERMISSION_SET = UNSAFEでマークされたアセンブリで実行できることについて質問している場合、それはかなり自由回答です。多くの機能は、セキュリティやパフォーマンスよりも安定性や一貫した動作の問題であるため、UNSAFEアセンブリでのみ使用可能と見なされます。たとえば、UNSAFEアセンブリでは、書き込み可能な静的変数を持つことができます。 SQLCLRクラスはすべてのセッションで共有されるため、これは通常、適切なことではありません。すべてのセッションでメモリ内のデータを共有し、競合状態を計画している（そして十分なテストを行っている）場合は、この動作を期待しているので問題ありません。ただし、特定のセッションの値をキャッシュして書き込み可能な静的変数に再検索または再計算する必要がなく、他のセッションがその値を読み取っており、場合によっては上書きしていることを認識していない場合は、それが問題になります。
しかし、誰かがレジストリに書き込むことを心配しているが、実際にレジストリに書き込むコードがない場合は、おそらくこれについて心配する必要はありません;-)。
EXTERNAL_ACCESSとUNSAFEが実際にどのように機能するかのウォークスルー、およびTRUSTWORTHY ON（推奨されない）の設定と非対称キーまたは証明書ベースのログインの使用の違いについては、この記事をご覧ください：- SQLCLRレベル4への階段：セキュリティ（外部およびUNSAFEアセンブリ） （無料登録が必要です）。
「パフォーマンス」について：
これはすべて、あなたが何をしようとしているか、どうやってそれをやろうとしているのかという問題です。 SQLCLRでははるかに高速なものもあれば、低速なものもあります。しかし、T-SQLの場合と同様に、やや単純で効率的なタスクを実行し、誤った処理を行うことで、タスクを複雑かつ/または非効率にすることができます。ただし、SQL CLRを使用しても、本質的に低速ではありません。
SQLCLRアセンブリは、3つのレベルのセキュリティアクセスでインストールできます：_SAFE | EXTERNAL_ACCESS | UNSAFE_。これは十分に文書化されています _CREATE Assembly_ および Designing Assemblies を参照してください：
アセンブリセキュリティの管理
アセンブリがマネージコードを実行するときに、.NETコードアクセスセキュリティによって保護されたリソースにアクセスできる量を制御できます。これを行うには、アセンブリを作成または変更するときに、SAFE、EXTERNAL_ACCESS、またはUNSAFEの3つの許可セットのいずれかを指定します。
SAFE
SAFEはデフォルトのアクセス権セットであり、最も制限的です。 SAFE権限を持つアセンブリによって実行されるコードは、ファイル、ネットワーク、環境変数、レジストリなどの外部システムリソースにアクセスできません。 SAFEコードは、ローカルSQL Serverデータベースのデータにアクセスしたり、ローカルデータベース外のリソースへのアクセスを必要としない計算やビジネスロジックを実行したりできます。
ほとんどのアセンブリは、SQL Serverの外部のリソースにアクセスする必要なく、計算およびデータ管理タスクを実行します。したがって、アセンブリ権限セットとしてSAFEをお勧めします。_
EXTERNAL_ACCESS_
EXTERNAL_ACCESSにより、アセンブリは、ファイル、ネットワーク、Webサービス、環境変数、レジストリなどの特定の外部システムリソースにアクセスできます。 EXTERNAL ACCESS権限を持つSQL ServerログインのみがEXTERNAL_ACCESSアセンブリを作成できます。 SAFEおよびEXTERNAL_ACCESSアセンブリには、検証可能に型保証されているコードのみを含めることができます。つまり、これらのアセンブリは、型定義に有効な明確に定義されたエントリポイントを介してのみクラスにアクセスできます。したがって、コードが所有していないメモリバッファに任意にアクセスすることはできません。さらに、SQL Serverプロセスの堅牢性に悪影響を及ぼす可能性のある操作を実行することはできません。
UNSAFE
UNSAFEは、SQL Server内外のリソースへの無制限のアクセスをアセンブリに提供します。 UNSAFEアセンブリ内から実行されているコードは、アンマネージコードを呼び出すことができます。また、UNSAFEを指定すると、アセンブリ内のコードが、CLRベリファイアによって型が安全でないと見なされる操作を実行できます。これらの操作は、SQL Serverプロセススペースのメモリバッファーに制御されていない方法でアクセスする可能性があります。 UNSAFEアセンブリは、SQL Serverまたは共通言語ランタイムのセキュリティシステムを破壊する可能性もあります。 UNSAFEの権限は、経験豊富な開発者または管理者が非常に信頼できるアセンブリにのみ付与する必要があります。 sysadmin固定サーバーロールのメンバーだけがUNSAFEアセンブリを作成できます。
許可されるCLR属性にはさらに制限があり、.Net Frameworkアセンブリのサブセットのみがサポートされます。再度、リンクされたドキュメントを参照してください。
パフォーマンスに関しては、SQL Serverは協調的なマルチタスク環境ですが、CLRはそうではないことを覚えておくことが最も重要です。 SQLCLRコードはmustcall Thread.BeginThreadAffinity() いつでも（ブロッキングを含む）CPUを独占します。 Adam Machanicがこのトピックについて優れたプレゼンテーションを行っています Data、Faster：Microsoft SQL Server Performance Techniques with SQLCLR をご覧ください。
トピックは広大で、質問は曖昧です。 SQLCLRは、他の機能では対応できない独自のタスクを実行できます。 SQLCLRは、パフォーマンスやセキュリティを駆使してSQL Serverの武器を手に入れることができるもう1つの武器です。ドキュメントをお読みください。