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. Você pode 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 do parâmetro pode ser usado mais de uma vez em uma única instrução SQL.
Em resumo, os parâmetros de consulta são compatíveis com a execução da consulta das seguintes maneiras:
- Planos pré-otimizados: as consultas que usam parâmetros podem ser executadas mais rapidamente cada invocação, porque a parametrização facilita Spanner para armazenar o plano de execução em cache.
- 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
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 O plano de execução da consulta exibe 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 usando o console do Google Cloud ou as 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:
Abra a página "Instâncias do Spanner".
Selecione os nomes da instância do Spanner e do banco de dados que você o que você quer consultar.
Clique em Spanner Studio no painel de navegação à esquerda.
Digite a consulta no campo de texto e clique em Executar consulta.
Clique em Explicação
. O console do Google Cloud exibe plano de execução para sua 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 visualizar amostras de planos históricos de consulta e comparar o desempenho 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. Como usar um índice secundário em uma consulta SQL permite 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 é um processo caro
para obter os resultados quando a tabela contém apenas uma pequena porcentagem de
Singers
com o 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 tabela indexada
coluna LastName
e a coluna de chave primária SingerId
, o Spanner pode
obter todos os dados da tabela de índices muito menor em vez de verificar o
tabela Singers
completa.
Nesse cenário, o Spanner usa automaticamente
o índice SingersByLastName
ao executar a consulta (contanto que três dias tenham
passados desde a criação do banco de dados; ver
Uma observação sobre novos bancos de dados). No entanto, é melhor
diga explicitamente ao Spanner para usar esse índice especificando
Uma diretiva index 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';
O uso do índice ainda oferece um benefício de desempenho porque o Spanner
não precisa fazer uma verificação completa da tabela ao executar o plano de consulta. Em vez disso,
seleciona o subconjunto de linhas que satisfazem o predicado da SingersByLastName
.
índice e, em seguida, faz uma pesquisa na tabela base Singers
para buscar o primeiro
apenas para esse subconjunto de linhas.
Se você quiser que o Spanner não precise buscar nenhuma linha da base
é possível armazenar uma cópia da coluna FirstName
na
o índice em si:
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áusulaINCLUDE
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áusulaINCLUDE
.
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. Para exemplo, suponha que você deseja buscar todos os títulos de álbuns e suas datas de lançamento em ordem crescente da data de lançamento e decrescente do título do álbum. Você poderia escrever uma consulta SQL desta forma:
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 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. Faça um comparativo de mercado para garantir o desempenho 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 começa a execução em no modo orientado por linhas. Durante esse período, o Spanner coleta métricas de tempo de execução. Depois, o Spanner aplica um conjunto de com base no resultado dessas métricas para determinar o modo de verificação ideal. Quando apropriado, o Spanner alterna para um modo de processamento orientado em lote para ajudar a 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.
- Verificações com predicados em colunas de largura fixa.
- Verificações com grandes contagens de busca. (Uma busca usa um índice para recuperar registros.)
Casos de uso sem ganhos de performance
Nem todas as consultas se beneficiam do processamento orientado em lote. A consulta a seguir tipos têm melhor desempenho com o processamento de verificação orientado por linhas:
- 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 elas tenham grandes contagens de buscas.
- 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 com valores grandes são aquelas que contêm valores maiores do que 32.000 bytes (pré-compactação) em uma única .
Como verificar o método de verificação usado por uma consulta
Para verificar se a consulta usa processamento orientado em lote e por linhas, ou que alterna automaticamente entre os dois métodos de verificação:
Acesse a página Instâncias do Spanner no console do Google Cloud.
Clique no nome da instância com a consulta que você quer investigar.
Na tabela Bancos de dados, clique no banco de dados com a consulta que você quer investigar.
No menu de navegação, clique em Spanner Studio.
Abra uma nova guia clicando em
Nova guia do editor SQL ou Nova guia.Quando o editor de consultas aparecer, crie sua consulta.
Clique em Executar.
O Spanner executa a consulta e mostra os resultados.
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.
Clique no card do iterador Table scan para abrir um painel de informações.
O painel mostra informações contextuais. sobre a verificação selecionada. O método de leitura é exibido 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 a verificação ideal para sua consulta. Recomendamos que você use esse método de verificação padrão. No entanto, talvez você queira aplicar uma regra tipo de método de verificação.
Como aplicar a verificação orientada por lote
É possível aplicar a verificação orientada por lote no nível da tabela e da instrução.
Para aplicar o método de verificação orientado por lote no nível da tabela, use uma dica de tabela. na sua 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 orientado por lote 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 verificação automática e aplicar a verificação orientada por linhas
Embora não seja recomendado desativar o método de verificação automática definido pelo no Spanner, é possível desativá-lo e usar orientado por linhas para solucionar problemas, como latência de rede.
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 ...
Desativar o método de verificação automática e aplicar o processamento de linhas na 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-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 como da seguinte forma:GoogleSQL
SELECT * FROM Table AS t WHERE t.Key BETWEEN @min AND @max
PostgreSQL
SELECT * FROM Table AS t WHERE t.Key BETWEEN $1 AND $2
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 os consulta resultante verificaria todos os valores entre 1 e 1.000.
Otimizar junções
As operações de mesclagem podem ser caras porque podem aumentar o número de linhas que a consulta precisa verificar, o que resulta em consultas mais lentas. Além das técnicas às quais 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 emSingers
, conforme discutido no Esquema e Modelo de Dados. Portanto, as mesclagens podem ser ser concluída localmente sem enviar muitos dados pela rede.Use a diretiva de junção se quiser forçar a ordem de junçã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
instrui o Spanner a usar a ordem de junção especificada na consulta (ou seja,Singers JOIN Albums
, nãoAlbums JOIN Singers
). Os resultados retornados são os mesmos, independentemente na ordem escolhida pelo Spanner. No entanto, talvez você queira usar esta mesclagem diretiva se perceber no plano de consulta que o Spanner mudou na ordem de mesclagem e causou consequências indesejáveis, como problemas intermediários resultados de pesquisa ou perder oportunidades de buscar 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 mesclagem 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 umHASH 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
ouAPPLY JOIN
e se tiver umWHERE
cláusula que seja altamente seletiva em um lado doJOIN
, coloque a tabela que produz o menor número de linhas do que a primeira tabela naFROM
da mesclagem. Essa estrutura é útil porque, atualmente, emHASH JOIN
, O Spanner sempre escolhe a tabela do lado esquerdo como build e o tabela lateral direita como sondagem. Da mesma forma, paraAPPLY JOIN
, o Spanner escolhe a tabela à esquerda como externa e a direita como para dentro. 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 mesclagem massiva) operações) nas suas transações, a menos que você esteja disposto a aceitar e aumentar a capacidade de processamento.
Em alguns casos, o padrão a seguir pode gerar melhores resultados:
- Faça as leituras grandes dentro de uma transação somente leitura. As transações somente leitura permitem maior capacidade agregada porque não usam bloqueios.
- Opcional: faça qualquer processamento necessário nos dados que você acabou de ler.
- Inicie uma transação de leitura/gravação.
- 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ê está esperando uma determinada 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 apenas se a cláusula ORDER BY
está 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
tem uma cláusula ORDER BY
, e o Spanner usa um índice que fornece o
a ordem exigida, o Spanner não classificará explicitamente os dados. Portanto,
não se preocupe com o impacto no desempenho resultante 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.
Usar 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 a forma foo%
(por exemplo, ele começa com uma
string e terminar com uma única porcentagem de caractere curinga) e a coluna estiver indexada, use
STARTS_WITH
em vez de LIKE
. Isso
permite que o Spanner otimize a execução da consulta com mais eficiência
de um plano eficaz de resposta a incidentes.
Não recomendado:
GoogleSQL
SELECT a.AlbumTitle FROM Albums a WHERE a.AlbumTitle LIKE @like_clause;
PostgreSQL
SELECT a.AlbumTitle FROM Albums a WHERE a.AlbumTitle LIKE $1;
Recomendado:
GoogleSQL
SELECT a.AlbumTitle FROM Albums a WHERE STARTS_WITH(a.AlbumTitle, @prefix);
PostgreSQL
SELECT a.AlbumTitle FROM Albums a WHERE STARTS_WITH(a.AlbumTitle, $2);
Usar carimbos de data/hora de confirmação
Caso seu aplicativo precise consultar dados gravados após um período específico,
adicionar colunas de carimbo de data/hora de confirmação às tabelas relevantes. Carimbos de data/hora de confirmação
permitir 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 o bancos de dados do dialeto GoogleSQL ou com Bancos de dados de dialeto PostgreSQL.