Quando as colunas computadas são computadas?

Isso é muito fácil de provar por conta própria. Podemos criar uma tabela com uma coluna computada que usa uma função escalar definida pelo usuário e, em seguida, verificar planos e estatísticas de função antes e depois de uma atualização e seleção e ver quando uma execução é registrada.

Digamos que temos esta função:

CREATE FUNCTION dbo.mask(@x varchar(32))
RETURNS varchar(32) WITH SCHEMABINDING
AS
BEGIN
  RETURN (SELECT 'XX' + SUBSTRING(@x, 3, LEN(@x)-4) + 'XXXX');
END
GO

E esta tabela:

CREATE TABLE dbo.Floobs
(
  FloobID int IDENTITY(1,1),
  Name varchar(32),
  MaskedName AS CONVERT(varchar(32), dbo.mask(Name)),
  CONSTRAINT pk_Floobs PRIMARY KEY(FloobID),
  CONSTRAINT ck_Name CHECK (LEN(Name)>=8)
);
GO

Vamos verificar sys.dm_exec_function_stats(novidade no SQL Server 2016 e Banco de Dados SQL do Azure) antes e depois de uma inserção e depois de uma seleção:

SELECT o.name, s.execution_count
FROM sys.dm_exec_function_stats AS s
INNER JOIN sys.objects AS o
ON o.[object_id] = s.[object_id]
WHERE s.database_id = DB_ID();

INSERT dbo.Floobs(Name) VALUES('FrankieC');

SELECT o.name, s.execution_count
FROM sys.dm_exec_function_stats AS s
INNER JOIN sys.objects AS o
ON o.[object_id] = s.[object_id]
WHERE s.database_id = DB_ID();

SELECT * FROM dbo.Floobs;

SELECT o.name, s.execution_count
FROM sys.dm_exec_function_stats AS s
INNER JOIN sys.objects AS o
ON o.[object_id] = s.[object_id]
WHERE s.database_id = DB_ID();

Não vejo nenhuma chamada de função no insert, apenas no select.

Agora, solte as tabelas e faça novamente, desta vez mudando a coluna para PERSISTED:

DROP TABLE dbo.Floobs;
GO
DROP FUNCTION dbo.mask;
GO

...
  MaskedName AS CONVERT(varchar(32), dbo.mask(Name)) PERSISTED,
...

E vejo o contrário acontecendo: recebo uma execução logada no insert, mas não no select.

Não tem uma versão moderna o suficiente do SQL Server para usar sys.dm_exec_function_stats? Não se preocupe, isso também é capturado nos planos de execução .

Para a versão não persistente, podemos ver a função referenciada apenas no select:

Enquanto a versão persistida mostra apenas o cálculo acontecendo na inserção:

Agora, Martin traz um grande ponto em um comentário : isso nem sempre será verdade. Vamos criar um índice que não cubra a coluna computada persistente e executar uma consulta que usa esse índice e ver se a pesquisa obtém os dados dos dados persistentes existentes ou calcula os dados em tempo de execução (solte e recrie a função e tabela aqui):

CREATE INDEX x ON dbo.Floobs(Name);
GO

INSERT dbo.Floobs(name) 
  SELECT LEFT(name, 32) 
  FROM sys.all_columns 
  WHERE LEN(name) >= 8;

Agora, vamos executar uma consulta que usa o índice (na verdade ele usa o índice por padrão neste caso específico de qualquer maneira, mesmo sem uma cláusula where):

SELECT * FROM dbo.Floobs WITH (INDEX(x))
  WHERE Name LIKE 'S%';

Vejo execuções adicionais nas estatísticas da função e o plano não mente:

Então, a resposta é DEPENDE . Nesse caso, o SQL Server achou que seria mais barato recalcular os valores do que realizar pesquisas. Isso pode mudar devido a uma variedade de fatores, portanto, não confie nisso. E isso pode acontecer em qualquer direção, seja ou não uma função definida pelo usuário; Eu só o usei aqui porque tornou muito mais fácil ilustrar.

Depende de como você define a coluna calculada. Uma PERSISTEDcoluna computada será calculada e então armazenada como dados dentro da tabela. Se você não definir a coluna como PERSISTED, ela será calculada quando sua consulta for executada.

Por favor, veja a resposta de Aaron para uma ótima explicação e prova.

Pinal Dave também descreve isso em detalhes e mostra provas de armazenamento em sua série:

SQL SERVER – Coluna Calculada – PERSISTIDO e Armazenamento

A resposta a esta pergunta é verdadeiramente "depende". Acabei de encontrar um exemplo em que o SQL Server está usando o índice na coluna computada persistente, mas ainda está executando a função, como se os valores nunca tivessem persistido para começar. Pode ter a ver com o tipo de dados da coluna ( nvarchar(37)) ou possivelmente com o tamanho da tabela (cerca de 7 milhões de linhas), mas o SQL Server decidiu ignorar a persistedpalavra-chave, ao que parece, nesta instância específica.

Nesse caso, a chave primária na tabela é TransactionID, que também é uma coluna computada e persistente. O plano de execução está gerando uma varredura de índice e em uma tabela com apenas 7 milhões de linhas, essa consulta simples está levando mais de 2 a 3 minutos para ser executada porque a função é executada novamente em cada linha e os valores não parecem ser persistentes em o índice.