Perguntas[sql-server](dba)

Configurar

-- Create a heap table of numbers from 1 to 100
SELECT TOP (100)
    i = IDENTITY(int, 1, 1)
INTO #T
FROM master.dbo.spt_values;

-- Add a clustered primary key
ALTER TABLE #T
    ADD PRIMARY KEY CLUSTERED (i);

Consulta de teste

Exibir 9% das linhas na ordem da chave primária:

SELECT TOP (9e) PERCENT 
    i 
FROM #T 
ORDER BY 
    i ASC;

DROP TABLE #T;

db<>demonstração de violino

Resultados

Plano de execução

Pergunta

Por que o SQL Server classifica a coluna quando o índice clusterizado fornece exatamente essa ordem?

Mais linhas

Se eu aumentar o número de linhas na tabela, obtenho um Eager Spool em vez de uma Sort e o índice é escaneado em ordem:

-- Create a heap table of numbers from 1 to 1,000
SELECT TOP (1000)
    i = IDENTITY(int, 1, 1)
INTO #T
FROM master.dbo.spt_values;

-- Add a clustered primary key
ALTER TABLE #T
    ADD PRIMARY KEY CLUSTERED (i);

-- 0.9% now
SELECT TOP (9e-1) PERCENT 
    i 
FROM #T 
ORDER BY 
    i ASC;

DROP TABLE #T;

Estou observando um impacto significativo no desempenho de listas de seleção em UNIONconsultas classificadas.

O formato geral das UNIONconsultas com as quais estou trabalhando é:

SELECT * FROM (
  SELECT <select_list> FROM <table>
  UNION ALL
  ...
) q
ORDER BY <column>

A seleção externa é usada porque melhora significativamente o desempenho na presença de ORDER BY, mas isso está fora do escopo desta questão. UNION ALLé sempre usado, em vez de UNION.

Vou me referir ao desempenho como "rápido" (instantâneo) ou "lento" (5 segundos ou mais).

O desempenho foi medido executando consultas no console do DBeaver, que por padrão recupera apenas a primeira página, cujo tamanho é 200.

Alterar a lista de seleção afeta o desempenho das seguintes maneiras:

1. Quando <select_list> = <column>(ou seja, somente a coluna de classificação é selecionada), as consultas são rápidas. O plano de execução mostra varreduras de índice para a coluna de classificação e junções de mesclagem para concatenação.
2. Quando a lista de seleção inclui outras colunas além da coluna de classificação, as consultas podem ser rápidas ou lentas. Foi observado que quando as seguintes condições são todas verdadeiras, as consultas são rápidas:
   • A lista de seleção inclui a coluna de índice agrupado.
   • A lista de seleção começa com a coluna de índice agrupado ou com a coluna de classificação imediatamente seguida pela coluna de índice agrupado.

As observações foram feitas usando o Microsoft SQL Server 2019 (RTM-CU26) (KB5035123) - 15.0.4365.2 (X64).

Não consegui encontrar nada sobre os efeitos das listas de seleção no desempenho UNIONna documentação do SQL Server.

Uma descrição simplificada do ambiente em que os experimentos foram conduzidos e as próprias consultas são fornecidas abaixo.

CREATE TABLE AUDIT1 (
    ID bigint NOT NULL,
    AUDITDATE datetime2 NULL,
    [USER] bigint NULL,
  -- Implies clustered index.
    CONSTRAINT PK_AUDIT1 PRIMARY KEY (ID)
);
CREATE INDEX I_AUDIT1_AUDITDATE ON AUDIT1 (AUDITDATE);

CREATE TABLE AUDIT2 (
    ID bigint NOT NULL,
    AUDITDATE datetime2 NULL,
    [USER] bigint NULL,
  -- Implies clustered index.
    CONSTRAINT PK_AUDIT2 PRIMARY KEY (ID)
);
CREATE INDEX I_AUDIT2_AUDITDATE ON AUDIT2 (AUDITDATE);

• A tabela AUDIT1contém 10 milhões de registros.
• A tabela AUDIT2contém 1 milhão de registros.
• Os valores de AUDITDATEin AUDIT2são maiores que aqueles em AUDIT1.
• Os valores de AUDITDATEsão alinhados com IDem uma sequência crescente, ou seja, IDestá sempre aumentando, e assim é AUDITDATE.

Consulta 1 : a lista de seleção contém apenas a coluna de classificação ( rápida ).

SELECT * FROM (
  SELECT AUDITDATE FROM AUDIT2
  UNION ALL 
  SELECT AUDITDATE FROM AUDIT1
) q
ORDER BY AUDITDATE

Plano de execução:

|--Merge Join(Concatenation)
   |--Index Scan(AUDIT2.I_AUDIT2_AUDITDATE), ORDERED BACKWARD
   |--Index Scan(AUDIT1.I_AUDIT1_AUDITDATE), ORDERED BACKWARD

Consulta 2 : seleciona lista de tamanho > 1, contém a coluna de classificação, não contém a coluna de índice agrupado ( lento ).

SELECT * FROM (
  SELECT [USER], AUDITDATE FROM AUDIT2
  UNION ALL 
  SELECT [USER], AUDITDATE FROM AUDIT1
) q
ORDER BY AUDITDATE

Observe que colocar a coluna de classificação primeiro não teve efeito.

Consulta 3 : selecione uma lista de tamanho > 1, contenha a coluna de classificação, contenha a coluna de índice agrupado, a primeira coluna não é a coluna de classificação nem a coluna de índice agrupado ( lento ).

SELECT * FROM (
  SELECT [USER], ID, AUDITDATE FROM AUDIT2
  UNION ALL 
  SELECT [USER], ID, AUDITDATE FROM AUDIT1
) q
ORDER BY AUDITDATE

Consulta 4 : selecione uma lista de tamanho > 1, contenha a coluna de classificação, contenha a coluna de índice agrupado, a primeira coluna é a coluna de classificação ou a coluna de índice agrupado ( rápido ).

SELECT * FROM (
  SELECT ID, [USER], AUDITDATE FROM AUDIT2
  UNION ALL 
  SELECT ID, [USER], AUDITDATE FROM AUDIT1
) q
ORDER BY AUDITDATE

Esta consulta mostra que se a primeira coluna for ID, a consulta é rápida.

Os planos de execução para as consultas 2, 3, 4 são os mesmos:

|--Parallelism(Gather Streams, ORDER BY:([Union1007] ASC))
   |--Sort(ORDER BY:([Union1007] ASC))
      |--Concatenation
         |--Parallelism(Distribute Streams, RoundRobin Partitioning)
         |--Clustered Index Scan(OBJECT:(AUDIT2.PK_AUDIT2))
         |--Clustered Index Scan(OBJECT:(AUDIT1.PK_AUDIT1))

Com o SQL Server 2022 Standard, se eu criar uma replicação transacional e inicializar a assinatura por meio de (A) um instantâneo ou (B) um backup de banco de dados, preciso garantir que o banco de dados de publicação fique inativo enquanto o banco de dados de assinatura é inicializado?

Ou seja, se ocorrerem alterações no banco de dados de publicação DEPOIS que o snapshot/backup for feito, mas ANTES que a replicação seja totalmente configurada e inicializada no banco de dados de assinatura, essas alterações serão aplicadas no banco de dados de assinatura?

Este não será um cenário Always ON AG, será uma replicação direta. Sei que não preciso de uma nova chave de licenciamento devido ao novo Software Assurance que a Microsoft oferece.

Mas, novamente, não tenho certeza se devo usar a mesma chave de licença da produção ou apenas criar uma Developer Edition.

Por "standby", quero dizer que esse nó não será consultado e só estará lá como standby caso o primário fique inativo.

Tenha paciência comigo, tenho muita preparação antes de chegar às perguntas.

SQL Server 2016, 13.0.7050.2 (mas isso também aconteceu em compilações anteriores). Acho que é o SQL Enterprise Edition (mas pode ser Standard). O servidor é o Windows 2016(?) com montes de RAM, um monte de núcleos e armazenamento SAN de alto desempenho (desculpe, não tenho todos os detalhes sobre isso, mas provavelmente não importa - não é limitado por recursos).

Banco de dados grande - mais de 1e12 bytes. A maior tabela tem mais de 1e9 linhas. DBCOMPAT é 130 e a estimativa de cardinalidade legada está ON. Este banco de dados foi atualizado há mais de um ano de uma versão anterior do SQL Server, provavelmente 2012 ou 2014.

Um processo ETL é executado - o aplicativo envia linhas para tabelas de preparação (via BulkCopyC#), então invoca um procedimento armazenado para enviar os dados para as tabelas de produção. As tabelas de preparação são limpas (via delete) antes de cada lote ser carregado. O tamanho do lote varia de zero linhas a vários milhões de linhas. Este procedimento armazenado tem quase 20 anos de uso, este banco de dados em particular está se aproximando dos 10 anos e teve bilhões de linhas inseridas e excluídas ao longo dos anos.

Alguns meses atrás, começamos a ter alguns lotes que demoravam muito para carregar - como horas para um lote de apenas algumas centenas de linhas. Os lotes imediatamente anteriores e imediatamente subsequentes tinham milhões de linhas cada e eram carregados normalmente.

Uma conclusão óbvia seria que esses lotes às vezes são executados com um plano ruim, devido a estimativas de cardinalidade, etc. Um rastreamento do SQL Profiler de um desses lotes lentos foi capturado e mostrou que uma consulta que foi executada por mais de uma hora, na verdade, foi executada em 6 segundos, com o restante do tempo sendo gasto na compilação da consulta (de acordo com os dados visíveis no arquivo XML .sqlplan).

Isso está em um ambiente de produção em uma grande instituição, então os experimentos estão em algum lugar entre difícil e impossível de fazer. Depois de muitas semanas de obstáculos, finalmente conseguimos obter uma cópia do banco de dados de produção em um ambiente de não produção onde poderíamos experimentar. Encontramos algumas coisas interessantes:

• Todas as consultas que tiveram tempos de execução ruins tinham uma tabela em comum - ItemStage(usada exatamente como o nome sugere - para preparar itens durante um lote ETL). As consultas em questão não são complexas - simples insert ... from ...com algumas junções (todas são pesquisas de chave em chaves primárias da tabela de destino).
• A tabela não tem chave primária ou índice clusterizado - é uma tabela heap.
• A tabela tem cerca de uma dúzia de relacionamentos de chave estrangeira de saída, mas todos eles são NOCHECK. Nenhuma dessas chaves estrangeiras faz referência a tabelas grandes - talvez 40.000 linhas no máximo.
• update statistics ItemStagecausou 500+ mb/s sustentados de E/S de banco de dados (em uma tabela de algumas 100 linhas). Nós paramos antes que terminasse.
• dbcc checkallocnão encontrei problemas
• dbcc checkcatalognão encontrei problemas
• dbcc checktable(ItemStage)nunca concluído. Paramos depois de mais de 15 minutos. A tabela neste ponto tinha 842 linhas.
• Tentamos adicionar uma chave primária agrupada, mas o tempo desta operação expirou. Não foi possível criar a chave primária.
• Nós descartamos a tabela e a recriamos com a definição que ela tinha o tempo todo - ainda uma pilha.
• O problema não é mais reproduzível: remover e recriar a tabela de preparação aparentemente resolveu o problema.

Então, perguntas...

• Esse problema vai reaparecer mais tarde? Em teoria, as operações que realizamos são um "no-op" lógico (mas, é claro, na prática, excluir e recriar a tabela fez com que sua alocação fosse liberada e então reconstruída, então não é um no-op no nível físico).
• Alguém já viu algo assim?
• Alguma teoria sobre o que realmente estava acontecendo?
• Alguma teoria sobre como evitar que isso aconteça novamente?

A documentação sobre os benefícios do particionamento lista o seguinte como o primeiro benefício de desempenho do particionamento de tabelas

o otimizador de consultas pode processar consultas de junção equivalente entre duas ou mais tabelas particionadas mais rapidamente quando as colunas de particionamento são as mesmas que as colunas nas quais as tabelas são unidas.

A mesma página fala um pouco mais sobre esse tópico mais adiante , mas não chega a nada além de dizer que unir tabelas particionadas que não são particionadas exatamente da mesma forma não obtém as mesmas otimizações que unir tabelas particionadas equivalentemente. Isso é, claro, irrelevante para o que a seção anterior alegou; qualquer comparação de desempenho entre duas formas de particionar tabelas não tem nada a ver com os benefícios do particionamento quando comparado a não particionar.

Isso me faz perguntar: unir tabelas particionadas equivalentemente é mais rápido do que unir duas tabelas com a mesma chave de índice clusterizado líder? Eu ficaria feliz com uma resposta experimental ou uma que usasse a teoria relevante para chegar a uma conclusão.

Eu li sobre os internos e li muitos white papers e blogs, mas acho que não vi isso abordado em lugar nenhum. Meu entendimento dos internos me leva a concluir que a abordagem particionada deve ser mais lenta do que a abordagem não particionada. Afinal, tudo o que o particionamento realmente faz é colocar outra chave de índice na frente da sua lista de chaves. Meus próprios experimentos descobriram o mesmo.

Tenho uma tabela de quase um milhão de linhas com duas colunas de datatype varbinary. Essas duas colunas armazenam dados binários que fazem o banco de dados crescer para 1 TB.

Como esse banco de dados também é restaurado em outros ambientes de controle de qualidade e em um ambiente de desenvolvimento, agora temos a tarefa de recuperar o máximo de espaço possível para economizar custos.

Após envolver o fornecedor, eles informaram que essas duas colunas podem ser descartadas, pois não estão mais em uso. A escrita do aplicativo para essas duas colunas foi modificada de acordo.

Eu segui duas opções para abordar a situação no meu ambiente de desenvolvimento, mas preciso de ajuda sobre a abordagem correta.

Opção 1

1. Solte as duas colunas binárias
2. Executar DBCC CLEANTABLE- Esta etapa levou quase 24 horas. Tive que pará-la porque não terei tanto tempo no ambiente de produção.
3. Encolher o sistema de arquivos - Estou um pouco relutante em fazer isso por causa da fragmentação.

Fiquei preso no número 2 acima e então tentei a segunda opção abaixo.

Opção 2

1. Solte as duas colunas binárias
2. Crie uma nova tabela e copie os dados usando o SSIS - Esta operação levou quase 12 horas para ser concluída (não terei tanto tempo em produção)
3. Crie um sistema de arquivos diferente e mova todas as tabelas e outros objetos para este novo sistema de arquivos de tabela, exceto a tabela antiga em questão, usando o CREATE INDEX…WITH DROP_EXISTING = ON, ONLINE = ONcomando
4. Solte a tabela antiga no sistema de arquivos primário
5. Encolher o sistema de arquivos primário - Espero que isso encolha mais rápido, pois não há muitos objetos nele.

O item 2 levou quase 12 horas para ser concluído. Alguém conhece uma abordagem melhor para se livrar dessas duas colunas e recuperar o espaço?

O ambiente de produção tem AOAG (Always On), o que significa que preciso estar em recuperação total.

O uso DBCC CLEANTABLEdemorou muito e meu log estava crescendo. Tive que parar para tentar a opção 2. Depois de correr por mais de 24 horas, parei. Demorou muito para finalmente parar. Foi nesse ponto que pensei que DBCC CLEANTABLEnão era uma boa opção para mim.

Atualizei recentemente uma tabela no meu banco de dados salvando pequenas imagens em miniatura em byte[]uma varbinary(max)coluna.

Isso melhorou significativamente a velocidade de carregamento de miniaturas (antes eu as carregava do sistema de arquivos), mas devido a um erro no meu código em que as imagens em miniatura estavam sendo redimensionadas, mas não compactadas, as imagens tinham cerca de 140-160 KB de tamanho e criavam uma tonelada de BLOBs. As imagens devem ter cerca de 5 ou 6 KB. Ao testar meu novo código, as imagens devem ter o tamanho correto em torno de 5 ou 6 KB.

Se eu iterar pela tabela e substituir todas as byte[]imagens na varbinary(max)coluna, isso limpará todos esses BLOBs desnecessários?

É compreensível que meu banco de dados tenha crescido significativamente como resultado do meu erro, e estou tentando fazer com que ele volte a ficar pequeno, pois seu tamanho atual está criando problemas com nossos backups.

O que eu entendi dos dados BLOB é que eles foram armazenados separadamente no banco de dados e referenciados na varbinarycélula da minha tabela, então eu não tinha certeza se eu substituísse isso se os dados BLOB associados fossem excluídos. Se eles são excluídos automaticamente, por que o banco de dados não encolheria automaticamente?

Estou testando no Dev Environment, mas depois do último erro que cometi, queria verificar novamente. Vi no SSMS que há opções para Shrinking the Database, então estou supondo que essa seria a tarefa que eu deveria executar após atualizar todos os dados da imagem. Claro que haverá muitos backups durante esse processo também. Estou apenas tentando evitar quaisquer problemas adicionais.

Tenho um banco de dados que foi feito backup de cerca de 50 MB e cresceu para cerca de 3,5 GB após meu erro. Posso substituir os dados por imagens menores, mas não parece que isso seria suficiente porque o banco de dados não encolherá automaticamente.

Temos um grupo de disponibilidade que consiste em 42 bancos de dados com uma réplica síncrona e uma réplica assíncrona. A réplica síncrona é capaz de acompanhar a primária (por definição), mas a maioria dos bancos de dados na réplica assíncrona efetivamente congela seu progresso no início do dia útil e não faz progresso até perto do fim do dia útil. Abaixo está um gráfico mostrando o atraso do AG por banco de dados, calculado last_commit_timepor sys.dm_hadr_database_replica_states

Para a maioria dos bancos de dados, o last_commit_timefica por volta das 9:00 AM até quase o fim do dia útil. A citação abaixo é de Troubleshoot: Potential data loss with asynchronous-commit availability-group replicas

As seções a seguir descrevem as causas comuns para alto potencial de perda de dados de uma réplica secundária de confirmação assíncrona, supondo que você não tenha um problema de desempenho sistêmico na sua instância de servidor que não esteja relacionado a grupos de disponibilidade.

1. Alta latência de rede ou baixa taxa de transferência de rede causa acúmulo de log na réplica primária

2. O gargalo de E/S do disco retarda o endurecimento do log na réplica secundária

Cerca de metade dos bancos de dados usam os arquivos de dados do SQL Server no recurso Microsoft Azure. O desempenho de E/S é muito ruim para esses bancos de dados a ponto de às vezes eu ver avisos de E/S de 15 segundos no log de erros. A parte que me confunde é que a maioria dos bancos de dados com o pior atraso não está no armazenamento do Azure. O único padrão que consigo ver é que os bancos de dados com o melhor desempenho de E/S parecem ter o maior atraso.

Considerando vários bancos de dados em um grupo de disponibilidade, é possível que um banco de dados com baixo desempenho de E/S cause atraso em um banco de dados com bom desempenho de E/S?

Alguns detalhes técnicos adicionais sobre minha situação, se necessário:

• A versão do SQL Server é Microsoft SQL Server 2019 (RTM-CU30).

• O data center que hospeda a réplica assíncrona está a 1800 milhas de distância do primário. Ambos os data centers estão nos EUA.

• O ping da réplica assíncrona para o primário é de 40-50 ms. Já me disseram muitas vezes que não estamos atingindo algum tipo de limitação geral de throughput de rede. Um teste netttcp mostra capacidade de largura de banda de 25-30 Mbit/seg.

• De acordo com o hadr_database_flow_control_actionevento estendido, os bancos de dados que não fazem progresso durante o dia útil gastam efetivamente 100% do tempo esperando no controle de fluxo. Os bancos de dados com menos lag não gastam tempo esperando no controle de fluxo.

• De acordo com o hadr_transport_flow_control_actionevento estendido, não há nenhuma espera no controle de fluxo no nível de transporte. O Sends to Transport/seccontador perfmon parece validar isso.

• O sinalizador de rastreamento 12310 foi habilitado de qualquer maneira e não teve nenhum efeito perceptível.

• A latência de gravação para os bancos de dados assíncronos com armazenamento não no Azure é entre 1-10 ms. A latência de gravação para os bancos de dados com armazenamento no Azure chega a 400 ms.

• Usando o Bytes Sent to Replica/seccontador perfmon, a réplica assíncrona consegue manter o ritmo até por volta das 8:30 da manhã. Depois, ela fica para trás e só recupera o atraso depois de algumas grandes explosões de progresso após horas.

• O Log Bytes Flushed/seccontador perfmon (dados ausentes por parte do dia) parece corresponder ao que vemos com bytes enviados. A atividade do usuário final começa a cair por volta das 16h30, que é quando a réplica assíncrona faz mais progresso em recuperação.

• Gerei um relatório de latência AG em 02/06/2025 e os gargalos são envio e controle de fluxo no primário. Não sei como acompanhar esses resultados:

• Estou ciente de que colocar bancos de dados usando os arquivos de dados do SQL Server no recurso Microsoft Azure em um AG assíncrono pode ser uma configuração incomum. Nós efetivamente enviamos os dados 1800 milhas apenas para enviá-los para a nuvem. A documentação da Microsoft sobre o recurso sugere que isso pode não ser necessário:

Benefícios de alta disponibilidade e recuperação de desastres: Usar o recurso SQL Server Data Files no Microsoft Azure pode simplificar as soluções de alta disponibilidade e recuperação de desastres. Por exemplo, se uma máquina virtual no Microsoft Azure ou uma instância do SQL Server travar, você pode recriar seus bancos de dados em uma nova instância do SQL Server apenas restabelecendo links para os blobs.

No momento, estou enfrentando um problema com consultas parametrizadas no SQL Server e não entendo onde ele está enraizado.

Eu resumi tudo em um exemplo simples:

Vamos supor uma tabela que contém dados sobre alguma entidade filha, bem como o parent_ide um índice correspondente no parent_id. Os dados são acessados ​​com base nisso, parent_idmas por meio de uma visualização que, adicionalmente aos dados da tabela, contém uma coluna que calcula um row_numbersobre todas as entradas particionadas pelo parent_id.

Configuração reproduzível

Crie a tabela, o índice e a visualização da seguinte forma:

CREATE TABLE dbo.test (id BIGINT IDENTITY(1,1), text NVARCHAR(255), parent_id BIGINT);
GO

CREATE NONCLUSTERED INDEX idx_test_parent_id
       ON dbo.test (parent_id);
GO

CREATE VIEW dbo.test_view
AS
  SELECT *, ROW_NUMBER() OVER (PARTITION BY parent_id ORDER BY id) AS row_num
  FROM dbo.test
GO

Agora coloque alguns dados na tabela:

DECLARE @i BIGINT = 0
WHILE @i < 200000
BEGIN
    SET @i = @i + 1
    INSERT INTO dbo.test (text, parent_id)
    VALUES ('test 1', @i), ('test 2', @i), ('test 3', @i);
END

A questão

Ao acessar os dados por meio de uma consulta parametrizada a partir da exibição, o SQL Server fará uma varredura completa na tabela.

DECLARE @parent_id BIGINT = 123456
SELECT *
FROM dbo.test_view
WHERE parent_id = @parent_id

Ao acessar os dados diretamente (sem usar um parâmetro), obteremos o índice de busca esperado.

SELECT *
FROM dbo.test_view
WHERE parent_id = 123456

O que eu tentei

Pesquisando em diferentes fóruns, não entendi realmente o que está acontecendo aqui. Encontrei problemas semelhantes em que o parâmetro tinha o tipo de dado errado e, portanto, o desempenho era ruim, mas isso não é um problema no meu caso. Também li sobre problemas com sniffing de parâmetros, mas também não acho que isso seja um problema aqui, pois não acesso dados por meio de procedimentos ou funções armazenados.

Além disso, quando estou acessando os dados diretamente da tabela com uma consulta parametrizada, o problema não ocorrerá. Uma busca de índice é feita mesmo com os parâmetros.

O mesmo acontece quando adiciono o OPTION (RECOMPILE)à consulta acessando a exibição com uma consulta parametrizada, o SQL Server acabará fazendo uma busca de índice.

Pergunta

Alguém pode explicar qual é o problema aqui? Como isso é um problema para a view, mas não para a tabela em si? Eu realmente preciso me livrar da view calculando isso row_numberde forma diferente durante inserções/exclusões?

Configurar

• SQL Server 2022 v16.0.4165 em execução em um contêiner docker
• Imagem do Docker: mcr.microsoft.com/mssql/server:2022-latest

A tabela real tem uma chave primária, é claro. Mas também tem muito mais colunas do que apenas a textcoluna. Incluir todas essas colunas no índice seria uma possibilidade. O problema, no entanto, não está ocorrendo ao selecionar da tabela em si, então não parece ser um problema do índice para mim.

Eu não sabia que estava executando o banco de dados em um modo de compatibilidade. No ambiente produtivo, estou até recebendo CardinalityEstimationModelVersion="140". Não acho que o tenha configurado em algum lugar de propósito.

Planos de execução

• seleção direta com busca de índice
• seleção parametrizada com varredura completa da tabela
• Verificação completa da tabela comQUERY_OPTIMIZER_COMPATIBILITY_LEVEL_150