A pergunta, como Remus apontou, é genérica demais para obter uma resposta, pois depende do contexto de qual funcionalidade deve ser usada e como será usada.
Em relação à "Segurança":
Se você está perguntando sobre algo que pode ser feito em uma montagem marcada com PERMISSION_SET = SAFE, não há nenhum problema que eu já tenha encontrado. E o SQLCLR é "mais seguro" do que usar xp_cmdshellou os maravilhosos sp_OA*procs (ou mesmo o sarcasmo) procs (ou mesmo os Procedimentos armazenados estendidos, mas espero que ninguém mais esteja criando nenhum deles).
Se você deseja conhecer o que "SAFE" significa em termos práticos, consulte este artigo: Escada para o SQLCLR Nível 3: Segurança (Assembléias Gerais e SAFE) (é necessário registro gratuito).
Se você estiver perguntando sobre algo que possa ser feito em uma montagem marcada com PERMISSION_SET = EXTERNAL_ACCESS, certamente haverá riscos novamente, dependendo de qual funcionalidade está sendo usada. Se você escrever uma rotina para ler diretórios e nomes de arquivos (isto é, somente leitura), será apenas uma questão do que deve ser visto e não visto. Se você estiver escrevendo um código que permita excluir um arquivo, o risco aumenta. Mas o que pode ser feito com esses recursos externos é controlado por:
- se você está usando ou não representação:
- sem representação significa que o acesso a recursos externos é feito por meio da conta "Fazer logon como" do serviço SQL Server. Qualquer que seja o acesso dessa conta, sua função SQLCLR poderá fazer.
- usar representação significa que o logon no SQL Server que está executando a função, se esse logon corresponder a um logon do Windows, poderá fazer o que esse logon do Windows em particular estiver autorizado a fazer. Se o Logon no SQL Server for um Logon do SQL Server, a tentativa de usar a Representação receberá um erro.
- Quais permissões são configuradas no recurso externo. Para acesso ao sistema de arquivos, isso é controlado através de ACLs em unidades NTFS.
Se você estiver perguntando sobre algo que possa ser feito em uma montagem marcada com PERMISSION_SET = UNSAFE, isso é bastante aberto. Muitas funcionalidades são consideradas apenas utilizáveis em assemblies UNSAFE porque são questões de estabilidade e / ou comportamento consistente mais do que segurança ou desempenho. Por exemplo, em um assembly UNSAFE, é possível ter uma variável estática gravável. Normalmente, isso não é uma coisa boa a ser feita, pois as classes SQLCLR são compartilhadas em todas as sessões. Se sua intenção é compartilhar dados na memória em todas as sessões e tiver planejado condições de corrida (e realizado vários testes), você deve ficar bem, pois espera esse comportamento. Mas se você simplesmente desejasse que uma variável estática gravável armazenasse em cache um valor para uma determinada sessão, não fosse necessário procurá-la novamente ou calculá-la novamente e não estivesse ciente de que outras sessões estão lendo esse valor e possivelmente sobrescrevendo-o, bem, isso seria um problema.
Mas se você está preocupado com alguém escrevendo no Registro, mas ainda não possui nenhum código que grave no Registro, provavelmente não precisa se preocupar com isso ;-).
Se você deseja obter uma explicação detalhada de como EXTERNAL_ACCESS e UNSAFE funcionam em termos práticos, e a diferença entre definir TRUSTWORTHY ON(não preferido) e usar um Login assimétrico ou baseado em certificado ou chave, consulte este artigo: Stairway to SQLCLR Level 4: Segurança (Assembleias EXTERNAS e NÃO-SEGURAS) (é necessário registro gratuito).
Em relação ao "desempenho":
Tudo isso é uma questão do que você está tentando fazer e de como você o faz. Há algumas coisas que são muito mais rápidas no SQLCLR e outras mais lentas. Mas, assim como no T-SQL, é possível executar uma tarefa um tanto simples e / ou eficiente e torná-la complicada e / ou ineficiente, fazendo as coisas incorretamente. Mas o uso do SQL CLR não é inerentemente, por sua própria natureza, mais lento.