Práticas recomendadas de SQL

Conforme descrito em Planos de execução de consulta, o compilador SQL transforma uma instrução SQL em um plano de execução de consulta, que é usada para obter os resultados da consulta. Nesta página, descrevemos as práticas recomendadas criar instruções SQL para ajudar o Spanner a encontrar execuções eficientes. planos de negócios.

As instruções SQL de exemplo mostradas nesta página usam o seguinte esquema de amostra:

GoogleSQL

CREATE TABLE Singers (
 SingerId   INT64 NOT NULL,
 FirstName  STRING(1024),
 LastName   STRING(1024),
 SingerInfo BYTES(MAX),
 BirthDate  DATE
) PRIMARY KEY (SingerId);

CREATE TABLE Albums (
 SingerId     INT64 NOT NULL,
 AlbumId      INT64 NOT NULL,
 AlbumTitle   STRING(MAX),
 ReleaseDate  DATE
) PRIMARY KEY (SingerId, AlbumId),
INTERLEAVE IN PARENT Singers ON DELETE CASCADE;

Para ver todas as referências do SQL, consulte Sintaxe da instrução, Funções e operadores e Estrutura léxica e sintaxe.

PostgreSQL

CREATE TABLE Singers (
 SingerId   BIGINT PRIMARY KEY,
 FirstName  VARCHAR(1024),
 LastName   VARCHAR(1024),
 SingerInfo BYTEA,
 BirthDate  TIMESTAMPTZ
);

CREATE TABLE Albums (
 SingerId        BIGINT NOT NULL,
 AlbumId         BIGINT NOT NULL,
 AlbumTitle      VARCHAR(1024),
 ReleaseDate     DATE,
 PRIMARY KEY(SingerId, AlbumId),
 FOREIGN KEY (SingerId) REFERENCES Singers(SingerId)
) INTERLEAVE IN PARENT Singers ON DELETE CASCADE;

Para mais informações, consulte A linguagem PostgreSQL no Spanner.

Usar parâmetros de consulta

O Spanner dá suporte a parâmetros de consulta para aumentar o desempenho e ajudar evitar injeção de SQL quando consultas são construídas usando entradas do usuário. É possível usar parâmetros de consulta como substitutos de expressões arbitrárias, mas não como substitutos de identificadores, nomes de colunas, nomes de tabelas ou outras partes da consulta.

Os parâmetros podem ser exibidos em qualquer lugar onde se espera um valor literal. O mesmo nome de parâmetro pode ser usado mais de uma vez em uma única instrução SQL.

Em resumo, os parâmetros de consulta oferecem suporte à execução de consulta das seguintes maneiras:

• Planos pré-otimizados: as consultas que usam parâmetros podem ser executadas mais rapidamente em cada invocação porque a parametrização facilita o armazenamento em cache do plano de execução pelo Spanner.
• Composição de consulta simplificada: não é necessário escapar valores de string quando fornecê-las nos parâmetros de consulta. Os parâmetros de consulta também reduzem o risco de erros de sintaxe.
• Segurança: os parâmetros de consulta tornam suas consultas mais seguras, protegendo você contra vários ataques de injeção de SQL. Essa proteção é especialmente importante para consultas que você constrói com base na entrada do usuário.

Entender como o Spanner executa consultas

Observação :Spanner Studio (anteriormente chamado de Consulta no console do Google Cloud) oferece suporte a operações SQL, DML e DDL em um único editor. Para mais informações, consulte Gerenciar dados usando o console do Google Cloud.

O Spanner permite consultar bancos de dados usando instruções SQL declarativas que especificam quais dados você quer recuperar. Se você quiser entender como O Spanner recebe os resultados e examina o plano de execução da consulta. Um plano de execução de consulta mostra o custo computacional associado a cada etapa da consulta. Usando os custos, é possível depurar os problemas de desempenho da consulta e otimizá-la. Para saber mais, consulte Planos de execução de consulta.

É possível recuperar planos de execução de consulta pelo console do Google Cloud ou pelas bibliotecas de cliente.

Para acessar um plano de execução para uma consulta específica usando o console do Google Cloud, faça o seguinte: siga estas etapas:

1. Abra a página "Instâncias do Spanner".

   Acessar "Instâncias do Spanner"

2. Selecione os nomes da instância do Spanner e do banco de dados que você quer consultar.

3. Clique em Spanner Studio no painel de navegação à esquerda.

4. Digite a consulta no campo de texto e clique em Executar consulta.

5. Clique em Explicação
   . O console do Google Cloud exibe um plano de execução visual para a consulta.

   

Para mais informações sobre como entender planos visuais e usá-los para depuração suas consultas, consulte Ajustar uma consulta usando o visualizador de planos de consulta.

Também é possível conferir amostras de planos de consulta históricos e comparar a performance de uma consulta ao longo do tempo para determinadas consultas. Para saber mais, consulte Planos de consulta com amostragem.

Usar índices secundários

Assim como outros bancos de dados relacionais, o Spanner oferece índices secundários, você pode usar para recuperar dados usando uma instrução SQL ou Interface de leitura do Spanner. A maneira mais comum de buscar dados de uma é usar o Spanner Studio. Com um índice secundário em uma consulta SQL, é possível especificar como você quer que o Spanner receba os resultados. A especificação de um índice secundário pode acelerar a execução da consulta.

Por exemplo, suponha que você queira buscar os IDs de todos os cantores com uma um sobrenome específico. Uma maneira de escrever uma consulta SQL é:

SELECT s.SingerId
FROM Singers AS s
WHERE s.LastName = 'Smith';

Essa consulta retornaria os resultados que você espera, mas talvez levasse muito tempo para fazer isso. O tempo dependerá do número de linhas na tabela Singers e quantas satisfazem o predicado WHERE s.LastName = 'Smith'. Se não houver um índice secundário que contenha a coluna LastName a ser lida, o plano de consulta vai ler toda a tabela Singers para encontrar linhas que correspondam ao predicado. Ler o texto inteiro é chamada de verificação completa da tabela. Uma verificação completa da tabela é uma maneira cara de conseguir os resultados quando a tabela contém apenas uma pequena porcentagem de Singers com esse sobrenome.

É possível melhorar o desempenho dessa consulta definindo um índice secundário na coluna de sobrenome:

CREATE INDEX SingersByLastName ON Singers (LastName);

Como o índice secundário SingersByLastName contém a coluna da tabela indexada LastName e a coluna de chave primária SingerId, o Spanner pode buscar todos os dados da tabela de índice muito menor em vez de verificar toda a tabela Singers.

Nesse cenário, o Spanner usa automaticamente o índice secundário SingersByLastName ao executar a consulta, desde que três dias tenham se passado desde a criação do banco de dados. Consulte Uma observação sobre novos bancos de dados. No entanto, é melhor informar explicitamente ao Spanner para usar esse índice especificando uma diretiva de índice na cláusula FROM:

GoogleSQL

SELECT s.SingerId
FROM Singers@{FORCE_INDEX=SingersByLastName} AS s
WHERE s.LastName = 'Smith';

PostgreSQL

 SELECT s.SingerId
FROM Singers /*@ FORCE_INDEX=SingersByLastName */ AS s
WHERE s.LastName = 'Smith';

Agora, suponha que você também queria buscar o nome do cantor além do ID. Mesmo que a coluna FirstName não esteja contida no índice, especifique a diretiva de índice como antes:

GoogleSQL

SELECT s.SingerId, s.FirstName
FROM Singers@{FORCE_INDEX=SingersByLastName} AS s
WHERE s.LastName = 'Smith';

PostgreSQL

SELECT s.SingerId, s.FirstName
FROM Singers /*@ FORCE_INDEX=SingersByLastName */ AS s
WHERE s.LastName = 'Smith';

Você ainda recebe um benefício de desempenho ao usar o índice porque o Spanner não precisa fazer uma verificação completa da tabela ao executar o plano de consulta. Em vez disso, ele seleciona o subconjunto de linhas que satisfazem o predicado do índice SingersByLastName e faz uma pesquisa da tabela base Singers para buscar o primeiro nome apenas desse subconjunto de linhas.

Se você não quiser que o Spanner busque linhas da tabela base, armazene uma cópia da coluna FirstName no próprio índice:

GoogleSQL

CREATE INDEX SingersByLastName ON Singers (LastName) STORING (FirstName);

PostgreSQL

CREATE INDEX SingersByLastName ON Singers (LastName) INCLUDE (FirstName);

usando uma cláusula STORING (para o dialeto GoogleSQL) ou uma cláusula INCLUDE; (para o dialeto PostgreSQL) dessa forma custa armazenamento extra, mas oferece as seguintes vantagens:

• Consultas SQL que usam o índice e selecionam colunas armazenadas nos STORING ou cláusula INCLUDE não exigem uma junção extra à tabela base.
• As chamadas de leitura que usam o índice podem ler colunas armazenadas no STORING ou cláusula INCLUDE.

Os exemplos anteriores ilustram como índices secundários podem agilizar consultas quando as linhas escolhidas pela cláusula WHERE podem ser identificadas rapidamente usando o índice secundário.

Outro cenário em que índices secundários podem oferecer benefícios de desempenho é para determinadas consultas que retornam resultados ordenados. Por exemplo, suponha que você queira buscar todos os títulos de álbuns e as datas de lançamento deles em ordem crescente na data de lançamento e em ordem decrescente por título do álbum. Você pode escrever uma consulta SQL da seguinte maneira:

SELECT a.AlbumTitle, a.ReleaseDate
FROM Albums AS a
ORDER BY a.ReleaseDate, a.AlbumTitle DESC;

Sem um índice secundário, esta consulta requer uma etapa de classificação potencialmente cara no plano de execução. É possível agilizar a execução da consulta definindo esse índice secundário:

CREATE INDEX AlbumsByReleaseDateTitleDesc on Albums (ReleaseDate, AlbumTitle DESC);

Em seguida, reescreva a consulta para usar o índice secundário:

GoogleSQL

SELECT a.AlbumTitle, a.ReleaseDate
FROM Albums@{FORCE_INDEX=AlbumsByReleaseDateTitleDesc} AS a
ORDER BY a.ReleaseDate, a.AlbumTitle DESC;

PostgreSQL

SELECT a.AlbumTitle, a.ReleaseDate
FROM Albums /*@ FORCE_INDEX=AlbumsByReleaseDateTitleDesc */ AS s
ORDER BY a.ReleaseDate, a.AlbumTitle DESC;

Essa consulta e a definição de índice atendem aos seguintes critérios:

• Para remover a etapa de classificação, verifique se a lista de colunas no ORDER BY é um prefixo da lista de chaves do índice.
• Para evitar a mesclagem de dados da tabela base para buscar colunas ausentes, garantir que o índice cubra todas as colunas da tabela usada pela consulta.

Embora os índices secundários possam acelerar consultas comuns, adicionar índices secundários podem adicionar latência às operações de confirmação, porque cada o índice secundário normalmente exige o envolvimento de um nó extra em cada commit. Na maioria das cargas de trabalho, não há problemas em ter alguns índices secundários. No entanto, você precisa considerar se é mais importante a latência de leitura ou de gravação e quais operações são as mais críticas para a carga de trabalho. Compare sua carga de trabalho para garantir que ela esteja funcionando conforme o esperado.

Para a referência completa de índices secundários, consulte Índices secundários.

Otimizar verificações

Algumas consultas do Spanner podem se beneficiar do uso de um modelo de processamento de dados ao verificar dados em vez do método mais comum orientado por linhas método de processamento de dados. O processamento de verificações em lotes é uma maneira mais eficiente de processar grandes volumes de dados de uma só vez e permite que as consultas alcancem menor utilização de CPU e latência.

A operação de verificação do Spanner sempre inicia a execução no modo orientado a linhas. Durante esse período, o Spanner coleta métricas de tempo de execução. Em seguida, o Spanner aplica um conjunto de heurísticas com base no resultado dessas métricas para determinar o modo de verificação ideal. Quando apropriado, o Spanner muda para um modo de processamento orientado a lotes para melhorar a capacidade e o desempenho da verificação.

Casos de uso comuns

Consultas com as seguintes características geralmente se beneficiam do uso de processamento orientado por lote:

• Verificações grandes em dados atualizados com pouca frequência.
• Faz verificações com predicados em colunas de largura fixa.
• Verificações com contagens de busca grandes. Uma busca usa um índice para extrair registros.

Casos de uso sem ganhos de performance

Nem todas as consultas se beneficiam do processamento orientado a lotes. Os tipos de consulta a seguir têm melhor desempenho com o processamento de verificação orientado por linha:

• Consultas de pesquisa de pontos: aquelas que buscam apenas uma linha.
• Pequenas consultas de verificação: verificações de tabela que verificam apenas algumas linhas, a menos que tenham contagens de busca grandes.
• Consultas que usam LIMIT.
• Consultas que leem dados de alta desistência de usuários: consultas em que mais de ~10% dos os dados lidos são atualizados com frequência.
• Consultas com linhas que contêm valores grandes: linhas de valores grandes são aquelas que contêm valores maiores que 32.000 bytes (antes da compactação) em uma única coluna.

Como verificar o método de verificação usado por uma consulta

Para verificar se sua consulta usa processamento orientado em lote e por linhas, ou que alterna automaticamente entre os dois métodos de verificação:

1. Acesse a página Instâncias do Spanner no console do Google Cloud.

   Acessar a página "Instâncias"

2. Clique no nome da instância com a consulta que você quer investigar.

3. Na tabela "Bancos de dados", clique no banco de dados com a consulta que você quer investigar.

4. No menu de navegação, clique em Spanner Studio.

5. Abra uma nova guia clicando em Nova guia do editor SQL ou Nova guia.

6. Quando o editor de consultas aparecer, crie sua consulta.

7. Clique em Executar.

   O Spanner executa a consulta e mostra os resultados.

8. Clique na guia Explicação abaixo do editor de consultas.

   O Spanner mostra um visualizador de plano de execução de plano de consulta. Cada card no gráfico representa um iterador.

9. Clique no card do iterador Verificação de tabela para abrir um painel de informações.

   O painel de informações mostra informações contextuais sobre a verificação selecionada. O método de leitura é mostrado neste card. Automático indica que o Spanner determina a verificação . Outros valores possíveis incluem Vectorized para orientação em lote e Scalar para processamento orientado por linhas.

   

Como aplicar o método de verificação usado por uma consulta

Para otimizar o desempenho da consulta, o Spanner escolhe o método de verificação ideal para a consulta. Recomendamos que você use esse método de verificação padrão. No entanto, talvez você queira aplicar uma política específica tipo de método de verificação.

Como aplicar a verificação orientada por lote

É possível aplicar a verificação orientada a lotes no nível da tabela e da instrução.

Para aplicar o método de verificação orientada a lotes no nível da tabela, use uma dica de tabela na consulta:

GoogleSQL

  SELECT ...
  FROM (t1@{SCAN_METHOD=BATCH} JOIN t2 ON ...)
  WHERE ...

PostgreSQL

  SELECT ...
  FROM (t1/*@ scan_method=batch */ JOIN t2 on ...)
  WHERE ...

Para aplicar o método de verificação orientada a lotes no nível da instrução, use uma dica de instrução na consulta:

GoogleSQL

  @{SCAN_METHOD=BATCH}
  SELECT ...
  FROM ...
  WHERE ...

PostgreSQL

  /*@ scan_method=batch */
  SELECT ...
  FROM ...
  WHERE ...

Como desativar a leitura automática e aplicar a leitura orientada por linha

Embora não recomendemos desativar o método de verificação automática definido pelo Spanner, você pode decidir desativá-lo e usar o método de verificação orientado a linha para fins de solução de problemas, como diagnosticar latência.

Desativar o método de verificação automática e aplicar o processamento de linhas na tabela use uma dica de tabela na consulta:

GoogleSQL

  SELECT ...
  FROM (t1@{SCAN_METHOD=ROW} JOIN t2 ON ...)
  WHERE ...

PostgreSQL

  SELECT ...
  FROM (t1/*@ scan_method=row */ JOIN t2 on ...)
  WHERE ...

Para desativar o método de verificação automática e aplicar o processamento de linhas no nível da instrução, use uma dica de instrução na consulta:

GoogleSQL

  @{SCAN_METHOD=ROW}
  SELECT ...
  FROM ...
  WHERE ...

PostgreSQL

  /*@ scan_method=row */
  SELECT ...
  FROM ...
  WHERE ...

Otimizar pesquisas de chave de intervalo

Um uso comum de uma consulta SQL é ler várias linhas do Spanner com base em uma lista de chaves conhecidas.

As práticas recomendadas a seguir ajudam você a escrever consultas eficientes ao buscar dados por um intervalo de chaves:

• Se a lista de chaves for esparsa e não adjacente, use parâmetros de consulta e UNNEST para construir a consulta.

  Por exemplo, se a lista de chaves for {1, 5, 1000}, escreva a consulta assim:

  GoogleSQL

  SELECT *
  FROM Table AS t
  WHERE t.Key IN UNNEST (@KeyList)

  PostgreSQL

  SELECT *
  FROM Table AS t
  WHERE t.Key IN UNNEST ($1)

  Observações:

  • O operador UNNEST da matriz nivela uma matriz de entrada em linhas de elementos.

  • O parâmetro de consulta, que é @KeyList para GoogleSQL e $1 para PostgreSQL, pode acelerar sua consulta conforme discutido nas das práticas recomendadas anteriores.

• Se a lista de chaves for adjacente e dentro de um intervalo, especifique os valores limites maiores do intervalo de chaves na cláusula WHERE.

  Por exemplo, se a lista de chaves for {1,2,3,4,5}, construa a consulta assim:

  GoogleSQL

  SELECT *
  FROM Table AS t
  WHERE t.Key BETWEEN @min AND @max

  Observação :aqui, @min e @max são parâmetros de consulta vinculados à valores 1 e 5, respectivamente.

  PostgreSQL

  SELECT *
  FROM Table AS t
  WHERE t.Key BETWEEN $1 AND $2

  Observação: aqui, $1 e $2 são parâmetros de consulta vinculados aos valores 1 e 5, respectivamente.

  Essa consulta só é mais eficiente se as chaves no intervalo de chaves forem adjacentes. Em outras palavras, se a lista de chaves for {1, 5, 1000}, não especificar os limites mínimo e máximo, como na consulta anterior, porque o consulta resultante verificaria todos os valores entre 1 e 1.000.

Otimizar agrupamentos

As operações de mesclagem podem ser caras porque podem aumentar significativamente o número de linhas que a consulta precisa verificar, o que resulta em consultas mais lentas. Além das técnicas a que você está acostumado a usar, em outros bancos de dados relacionais para otimizar consultas de mesclagem, confira algumas práticas para uma mesclagem mais eficiente ao usar o SQL do Spanner:

• Se possível, vincule dados em tabelas intercaladas por chave principal. Exemplo:

  SELECT s.FirstName, a.ReleaseDate
  FROM Singers AS s JOIN Albums AS a ON s.SingerId = a.SingerId;

  As linhas na tabela intercalada Albums têm a garantia de estar fisicamente armazenadas nas mesmas divisões que a linha pai em Singers, conforme discutido no Esquema e Modelo de Dados. Por isso, as mesclagens podem ser concluídas localmente sem enviar muitos dados pela rede.

• Use a diretiva de vinculação se você quiser forçar a ordem da vinculação. Exemplo:

  GoogleSQL

  SELECT *
  FROM Singers AS s JOIN@{FORCE_JOIN_ORDER=TRUE} Albums AS a
  ON s.SingerId = a.Singerid
  WHERE s.LastName LIKE '%x%' AND a.AlbumTitle LIKE '%love%';

  PostgreSQL

  SELECT *
  FROM Singers AS s JOIN/*@ FORCE_JOIN_ORDER=TRUE */ Albums AS a
  ON s.SingerId = a.Singerid
  WHERE s.LastName LIKE '%x%' AND a.AlbumTitle LIKE '%love%';

  A diretiva de junção FORCE_JOIN_ORDER diz ao Spanner para usar a ordem de junção especificada na consulta (isto é, Singers JOIN Albums, não Albums JOIN Singers). Os resultados retornados são os mesmos, independentemente da ordem escolhida pelo Spanner. No entanto, convém usar essa diretiva de vinculação se você notar no plano de consulta que o Spanner mudou a ordem de vinculação e causou consequências indesejáveis, como resultados intermediários maiores, ou perdeu oportunidades de procurar linhas.

• Use uma diretiva de vinculação para escolher uma implementação de junção. Quando você usa SQL para consultar várias tabelas, o Spanner usa automaticamente um método de junção que provavelmente tornará a consulta mais eficiente. No entanto, o Google aconselha realizar testes com diferentes algoritmos de mesclagem. Escolher o algoritmo de mesclagem certo para a consulta pode melhorar a latência, o consumo de memória ou ambos. A consulta mostra A sintaxe para usar uma diretiva JOIN com a dica JOIN_METHOD para escolher um HASH JOIN:

  GoogleSQL

  SELECT *
  FROM Singers s JOIN@{JOIN_METHOD=HASH_JOIN} Albums AS a
  ON a.SingerId = a.SingerId

  PostgreSQL

  SELECT *
  FROM Singers s JOIN/*@ JOIN_METHOD=HASH_JOIN */ Albums AS a
  ON a.SingerId = a.SingerId

• Se você estiver usando um HASH JOIN ou APPLY JOIN e tiver uma cláusula WHERE altamente seletiva em um lado do JOIN, coloque a tabela que produz o menor número de linhas como a primeira tabela na cláusula FROM da mesclagem. Essa estrutura é útil porque, atualmente, em HASH JOIN, O Spanner sempre escolhe a tabela do lado esquerdo como build e o tabela lateral direita como sondagem. Da mesma forma, para APPLY JOIN, o Spanner escolhe a tabela do lado esquerdo como externa e a tabela do lado direito como interna. Saiba mais sobre esses tipos de mesclagem em Hash e Aplicar mesclagem.

• Para consultas essenciais para sua carga de trabalho, especifique a de maior desempenho método de mesclagem e ordem de mesclagem em suas instruções SQL para obter uma desempenho.

Evitar grandes leituras em transações de leitura e gravação

Transações de leitura/gravação permitem uma sequência de zero ou mais leituras ou consultas SQL e podem incluir um conjunto de mutações, antes de uma chamada para confirmação. Para manter a consistência dos dados, o Spanner adquire bloqueios ao ler e gravar linhas em tabelas e índices. Para Para mais informações sobre bloqueio, consulte O ciclo de vida de leituras e gravações.

Devido à forma como o bloqueio funciona no Spanner, realizar uma leitura ou SQL consulta que lê um grande número de linhas (por exemplo, SELECT * FROM Singers); significa que nenhuma outra transação pode gravar nas linhas que você leu até se a transação foi confirmada ou cancelada.

Além disso, como sua transação está processando um grande número de linhas, ela provavelmente levará mais tempo do que uma transação que lê um intervalo muito menor de linhas (por exemplo, SELECT LastName FROM Singers WHERE SingerId = 7), o que também agrava o problema e reduz a capacidade de processamento do sistema.

Portanto, tente evitar leituras grandes (por exemplo, verificações de tabela completas ou operações de vinculação em massa) nas suas transações, a menos que esteja disposto a aceitar uma capacidade de gravação menor.

Em alguns casos, o seguinte padrão pode render resultados melhores:

1. Realize as leituras grandes em uma transação somente leitura. As transações somente leitura permitem maior capacidade agregada porque não usam bloqueios.
2. Opcional: faça qualquer processamento necessário nos dados que você acabou de ler.
3. Inicie uma transação de leitura/gravação.
4. Verifique se as linhas críticas não mudaram os valores desde a execução a transação somente leitura na etapa 1.
   • Se houve mudança, reverta sua transação e comece novamente na etapa 1.
   • Se tudo estiver certo, confirme as mutações.

Uma maneira de garantir que você está evitando leituras grandes de leitura/gravação transações é observar os planos de execução que suas consultas geram.

Usar ORDER BY para garantir a ordem dos resultados SQL

Se você espera uma certa ordem para os resultados de uma consulta SELECT, inclua explicitamente a cláusula ORDER BY. Por exemplo, se você quiser listar todos os cantores na ordem da chave primária, use esta consulta:

SELECT * FROM Singers
ORDER BY SingerId;

O Spanner garante a ordenação de resultados somente se a cláusula ORDER BY estiver presente na consulta. Em outras palavras, considere esta consulta sem o ORDER BY:

SELECT * FROM Singers;

O Spanner não garante que os resultados dessa consulta serão ordem de chave primária. Além disso, a ordem dos resultados pode mudar a qualquer momento e não há garantia de consistência de invocação para invocação. Se uma consulta tiver uma cláusula ORDER BY e o Spanner usar um índice que fornece a ordem necessária, ele não vai classificar os dados explicitamente. Portanto, não se preocupe com o impacto no desempenho da inclusão dessa cláusula. Você pode conferir se uma operação de classificação explícita está incluída na execução analisando o plano de consulta.

Use STARTS_WITH em vez de LIKE

Como o Spanner não avalia padrões LIKE parametrizados até ambiente de execução, o Spanner precisa ler todas as linhas e avaliá-las em relação ao Expressão LIKE para filtrar linhas que não correspondem.

Quando um padrão LIKE tem o formato foo% (por exemplo, começa com uma string fixa e termina com um único caractere curinga percentual) e a coluna é indexada, use STARTS_WITH em vez de LIKE. Isso permite que o Spanner otimize a execução da consulta com mais eficiência de transformação de dados de uma organização.

Não recomendado:

GoogleSQL

SELECT a.AlbumTitle FROM Albums a
WHERE a.AlbumTitle LIKE @like_clause;

Observação: neste exemplo, presumimos que @like_clause está vinculado a 'Love%'.

PostgreSQL

SELECT a.AlbumTitle FROM Albums a
WHERE a.AlbumTitle LIKE $1;

Observação: neste exemplo, presumimos que $2 está vinculado a 'Love%'.

Recomendado:

GoogleSQL

SELECT a.AlbumTitle FROM Albums a
WHERE STARTS_WITH(a.AlbumTitle, @prefix);

Observação: neste exemplo, presumimos que @prefix está vinculado a 'Love'. Essa consulta tem mais eficiente do que a consulta anterior. Ele é executado mais rapidamente se um índice for definido em Albums.AlbumTitle.

PostgreSQL

SELECT a.AlbumTitle FROM Albums a
WHERE STARTS_WITH(a.AlbumTitle, $2);

Observação: neste exemplo, presumimos que $1 está vinculado a 'Love'. Essa consulta é mais eficiente que a anterior. Ela será executada mais rapidamente se um índice for definido em Albums.AlbumTitle.

Usar carimbos de data/hora de confirmação

Se o aplicativo precisar consultar dados gravados após um determinado horário, adicione colunas de carimbo de data/hora de confirmação às tabelas relevantes. Carimbos de data/hora de confirmação permite uma otimização do Spanner que pode reduzir a E/S de consultas com cláusulas WHERE que restringem os resultados às linhas escritas mais recentemente. de um horário específico.

Saiba mais sobre essa otimização com bancos de dados do GoogleSQL ou com bancos de dados do PostgreSQL.