Remusが指摘したように、質問は一般的すぎて回答を得ることができません。回答は、使用する機能のコンテキストとその使用方法に依存するためです。
「セキュリティ」について：
でマークされたアセンブリで実行できることについて質問している場合PERMISSION_SET = SAFE、私がこれまでに発見した問題はありません。また、SQLCLRはxp_cmdshell、すばらしい（皮肉な）sp_OA*プロシージャ（または拡張ストアドプロシージャ）を使用するよりも "安全"ですが、誰も作成していないことを願っています。
「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への階段：セキュリティ（EXTERNALおよびUNSAFEアセンブリ）（無料登録が必要です）。
「パフォーマンス」について：
これは、あなたが何をしようとしているか、どうやってそれをどうやってやるかの問題です。あるいくつかのものがありますずっと速くSQLCLRで、かつ遅いいくつかのものは。しかし、T-SQLの場合と同様に、やや単純で効率的なタスクを実行し、誤った処理を行うことで、タスクを複雑かつ/または非効率的にすることができます。ただし、SQL CLRを使用しても、本質的に低速ではありません。