Em um banco de dados do Cloud Spanner, o Spanner cria automaticamente um índice para cada chave primária de uma tabela. Por exemplo, não é preciso fazer nada para indexar a chave primária do Singers
, porque ela é indexada automaticamente.
Também é possível criar índices secundários para outras colunas. Adicionar um índice secundário a uma coluna torna mais eficiente para procurar dados nessa coluna. Por exemplo, se você precisar procurar rapidamente um álbum por título, crie um índice secundário em AlbumTitle
para que o Spanner não precise verificar toda a tabela.
Se a pesquisa no exemplo acima for feita em uma transação de leitura e gravação, a pesquisa mais eficiente também evita reter bloqueios em toda a tabela, o que permite inserções e atualizações simultâneas na tabela para linhas fora do intervalo de pesquisa AlbumTitle
.
Além dos benefícios que eles trazem para as pesquisas, os índices secundários também podem ajudar o Spanner a executar verificações com mais eficiência, permitindo verificações de índices, em vez de verificações de tabelas completas.
O Spanner armazena os seguintes dados em cada índice secundário:
- Todas as colunas de chave da tabela base
- Todas as colunas incluídas no índice
- Todas as colunas especificadas na cláusula opcional
STORING
(bancos de dados do dialeto SQL padrão do Google) ouINCLUDE
(bancos de dados do dialeto PostgreSQL) da definição do índice.
Com o tempo, o Spanner analisa suas tabelas para garantir que seus índices secundários sejam usados para as consultas apropriadas.
Adicionar um índice secundário
O momento mais eficiente para adicionar um índice secundário é quando você cria a tabela. Para criar uma tabela e os índices dela ao mesmo tempo, envie as instruções DDL para a nova tabela e os novos índices em uma única solicitação para o Spanner.
No Spanner, também é possível adicionar um novo índice secundário a uma tabela atual enquanto o banco de dados continua a exibir tráfego. Como qualquer outra alteração de esquema no Spanner, adicionar um índice a um banco de dados atual não exige que o banco de dados fique off-line e não bloqueia colunas ou tabelas inteiras.
Sempre que um novo índice é adicionado a uma tabela, o Spanner preenche automaticamente o índice para refletir uma visualização atualizada dos dados que estão sendo indexados. O Spanner gerencia esse processo de preenchimento para você, e o processo é executado em segundo plano usando recursos de nó com baixa prioridade. Na maioria dos casos, não é possível acelerar o processo (por exemplo, adicionando mais nós), e o preenchimento não afeta significativamente o desempenho do banco de dados.
O tempo de criação do índice pode variar de minutos a muitas horas. Como a criação do índice é uma atualização de esquema, ele está sujeito às mesmas restrições de desempenho que qualquer outra atualização de esquema. O tempo necessário para criar um índice secundário depende de vários fatores:
- do tamanho do conjunto de dados;
- A capacidade de computação da instância
- da carga na instância.
Para ver o progresso de um processo de preenchimento de índice, consulte a seção de progresso.
Esteja ciente de que usar a coluna confirmar carimbo de data/hora como a primeira parte do índice secundário pode criar pontos de acesso e reduzir o desempenho de gravação.
Use a instrução CREATE INDEX
para definir um índice secundário no seu esquema. Veja alguns exemplos:
Para indexar todos os Singers
no banco de dados pelo nome e sobrenome:
CREATE INDEX SingersByFirstLastName ON Singers(FirstName, LastName)
Para criar um índice de todos Songs
no banco de dados pelo valor de SongName
:
CREATE INDEX SongsBySongName ON Songs(SongName)
Para indexar somente as músicas de um determinado cantor, use a cláusula INTERLEAVE IN
para intercalar o índice na tabela Singers
:
CREATE INDEX SongsBySingerSongName ON Songs(SingerId, SongName),
INTERLEAVE IN Singers
Para indexar apenas as canções de um álbum específico:
CREATE INDEX SongsBySingerAlbumSongName ON Songs(SingerId, AlbumId, SongName),
INTERLEAVE IN Albums
Para indexar por ordem decrescente de SongName
:
CREATE INDEX SongsBySingerAlbumSongNameDesc ON Songs(SingerId, AlbumId, SongName DESC),
INTERLEAVE IN Albums
A anotação DESC
acima se aplica somente a SongName
. Para indexar por ordem decrescente de outras chaves de índice, anote-as com DESC
também: SingerId DESC, AlbumId DESC
.
Observe também que PRIMARY_KEY
é uma palavra reservada e não pode ser usada como o nome de um índice. É o nome dado ao pseudoíndice, que é criado quando uma tabela com a especificação PRIMARY KEY é criada
Para mais detalhes e práticas recomendadas para escolher índices não intercalados e intercalados, consulte Opções de índice e Usar um índice intercalado em uma coluna cujo valor aumenta ou diminui monotonicamente.
Ver progresso do preenchimento do índice
Etapas para visualizar o progresso do preenchimento do índice
Um processo de preenchimento de índice faz parte de uma operação de longa duração schema-update, já que a adição de um índice secundário requer uma atualização de esquema. É possível ver o progresso do preenchimento do índice usando o ID da operação. Se você não tiver o código da operação, use a lista de operações do gcloud Spanner para encontrá-lo:
gcloud spanner operations list --instance=INSTANCE --database=DATABASE
Observações sobre o uso:
Para limitar a lista de operações retornadas por esse comando, especifique a sinalização
--filter
. Por exemplo, use o filtro a seguir para retornar operações de atualização de esquema.--filter="@TYPE:UpdateDatabaseDdlMetadata"
Para informações sobre a sintaxe do filtro, consulte gcloud topic filtros. Para informações sobre como filtrar operações de banco de dados, consulte o campo
filter
em ListDatabaseOperationsRequest.
Veja um exemplo da saída:
OPERATION_ID STATEMENTS DONE @TYPE _auto_op_123456 CREATE INDEX SingersByFirstLastName ON Singers(FirstName, LastName) False UpdateDatabaseDdlMetadata CREATE INDEX SongsBySingerAlbumSongName ON Songs(SingerId, AlbumId, SongName), INTERLEAVE IN Albums _auto_op_234567 True CreateDatabaseMetadata
Para acompanhar o progresso de um ou vários processos secundários de preenchimento de índice, use o gcloud Spanner Operations describe:
gcloud spanner operations describe _auto_op_123456 \ --instance=INSTANCE \ --database=DATABASE
Aqui está um exemplo de saída de uma operação de longa duração com atualização de esquema que contém dois processos de preenchimento de índice:
done: true metadata: '@type': type.googleapis.com/google.spanner.admin.database.v1.UpdateDatabaseDdlMetadata commitTimestamps: - '2021-01-22T21:58:42.912540Z' database: projects/my-project/instances/test-instance/databases/example-db progress: - endTime: '2021-01-22T21:58:42.912540Z' progressPercent: 100 startTime: '2021-01-22T21:58:11.053996Z' - progressPercent: 67 startTime: '2021-01-22T21:58:11.053996Z' statements: - CREATE INDEX SingersByFirstLastName ON Singers(FirstName, LastName) - CREATE INDEX SongsBySingerAlbumSongName ON Songs(SingerId, AlbumId, SongName), INTERLEAVE IN Albums name: projects/my-project/instances/test-instance/databases/example-db/operations/_auto_op_123456 response: '@type': type.googleapis.com/google.protobuf.Empty
O progresso de cada instrução de preenchimento de índice é encontrado no campo
progress
. Para cada instrução na matriz de instruções, há um campo correspondente na matriz de progresso. Essa ordem de matriz de progresso corresponde à ordem das matrizes de instruções. Quando disponíveis, os camposstartTime
,progressPercent
eendTime
são preenchidos de acordo. A saída não mostra um tempo estimado de quando o progresso de preenchimento será concluído.
Cenários ao visualizar o progresso do preenchimento do índice
Há diferentes cenários que você pode encontrar ao tentar verificar o progresso de um preenchimento de índice. As instruções de criação de índice que exigem um preenchimento de índice fazem parte de operações de atualização de esquema, e pode haver várias instruções que fazem parte de uma operação de atualização de esquema.
O primeiro cenário é o mais simples, que é quando a instrução de criação do índice é a primeira na operação de atualização do esquema. Como a instrução de criação
de índice é a primeira, é a primeira que é processada e executada devido
à ordem de execução.
Imediatamente, o campo startTime
da instrução de criação de índice será preenchido com o horário de início da operação de atualização do esquema. Em seguida, o campo progressPercent
da instrução de criação do índice é preenchido quando o progresso do preenchimento de índice está acima de 0%. Por fim, o campo endTime
será preenchido depois que a instrução for confirmada.
O segundo cenário é quando a instrução de criação do índice não é a primeira
instrução na operação de atualização do esquema. Nenhum campo relacionado à instrução de criação de índice será preenchido até que as instruções anteriores tenham sido confirmadas devido à ordem de execução.
Semelhante ao cenário acima, depois que as instruções anteriores forem confirmadas, o campo startTime
da instrução de criação de índice será preenchido primeiro, seguido pelo campo progressPercent
. Por fim, o campo endTime
é preenchido quando a instrução termina de confirmar.
Cancelar criação do índice
Use a CLI do Google Cloud para cancelar a criação do índice. Para recuperar uma lista de operações de atualização de esquema de um banco de dados do Spanner, use o comando gcloud spanner operations list
e inclua a opção --filter
:
gcloud spanner operations list \
--instance=INSTANCE \
--database=DATABASE \
--filter="@TYPE:UpdateDatabaseDdlMetadata"
Encontre o OPERATION_ID
para a operação que você quer cancelar, use o comando gcloud spanner operations cancel
para cancelá-lo:
gcloud spanner operations cancel OPERATION_ID \
--instance=INSTANCE \
--database=DATABASE
Ver índices existentes
Para ver informações sobre índices existentes em um banco de dados, use o Console do Google Cloud ou a CLI do Google Cloud:
Console
Acesse a página Instâncias do Spanner no Console do Google Cloud.
Clique no nome da instância que quer exibir.
No painel esquerdo, clique no banco de dados que você quer visualizar e clique na tabela que você quer visualizar.
Clique na guia Índices. O Console do Google Cloud mostra uma lista de índices.
Opcional: para detalhes sobre um índice, como as colunas incluídas, clique no nome do índice.
gcloud
Use o comando gcloud spanner databases ddl describe
:
gcloud spanner databases ddl describe DATABASE \
--instance=INSTANCE
A CLI gcloud imprime as instruções de Linguagem de definição de dados (DDL) para criar as tabelas e os índices do banco de dados. As instruções CREATE
INDEX
descrevem os índices atuais. Exemplo:
--- |-
CREATE TABLE Singers (
SingerId INT64 NOT NULL,
FirstName STRING(1024),
LastName STRING(1024),
SingerInfo BYTES(MAX),
) PRIMARY KEY(SingerId)
---
CREATE INDEX SingersByFirstLastName ON Singers(FirstName, LastName)
Consultar com um índice específico
As seções a seguir explicam como especificar um índice em uma instrução SQL e com a interface de leitura para o Spanner. Os exemplos nessas seções presumem que você adicionou uma coluna MarketingBudget
à tabela Albums
e criou um índice chamado AlbumsByAlbumTitle
:
SQL padrão do Google
CREATE TABLE Albums (
SingerId INT64 NOT NULL,
AlbumId INT64 NOT NULL,
AlbumTitle STRING(MAX),
MarketingBudget INT64,
) PRIMARY KEY (SingerId, AlbumId),
INTERLEAVE IN PARENT Singers ON DELETE CASCADE;
CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);
PostgreSQL
CREATE TABLE Albums (
SingerId BIGINT NOT NULL,
AlbumId BIGINT NOT NULL,
AlbumTitle VARCHAR,
MarketingBudget BIGINT,
PRIMARY KEY (SingerId, AlbumId)
) INTERLEAVE IN PARENT Singers ON DELETE CASCADE;
CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);
Especificar um índice em uma instrução SQL
Quando você usa a SQL para consultar uma tabela, o Spanner usa automaticamente todos os índices que provavelmente tornarão a consulta mais eficiente. Como resultado, você não precisa especificar um índice para consultas SQL. No entanto,
para consultas essenciais à sua carga de trabalho, o Google aconselha a utilização de
diretivas FORCE_INDEX
nas instruções SQL para um desempenho mais consistente.
Em alguns casos, o Spanner pode escolher um índice que faz com que a latência da consulta aumente. Se você seguiu as etapas de solução de problemas para regressões de desempenho e confirmou que convém tentar um índice diferente para a consulta, especifique o índice como parte de sua consulta.
Para especificar um índice em uma instrução SQL, use a dica
FORCE_INDEX
para fornecer uma diretiva de índice. As diretivas de índice usam a seguinte sintaxe:
SQL padrão do Google
FROM MyTable@{FORCE_INDEX=MyTableIndex}
PostgreSQL
FROM MyTable /*@ FORCE_INDEX = MyTableIndex */
Você também pode usar uma diretiva de índice para instruir o Spanner a verificar a tabela base em vez de usar um índice:
SQL padrão do Google
FROM MyTable@{FORCE_INDEX=_BASE_TABLE}
PostgreSQL
FROM MyTable /*@ FORCE_INDEX = _BASE_TABLE */
O exemplo a seguir mostra uma consulta SQL que especifica um índice:
SQL padrão do Google
SELECT AlbumId, AlbumTitle, MarketingBudget
FROM Albums@{FORCE_INDEX=AlbumsByAlbumTitle}
WHERE AlbumTitle >= "Aardvark" AND AlbumTitle < "Goo";
PostgreSQL
SELECT AlbumId, AlbumTitle, MarketingBudget
FROM Albums /*@ FORCE_INDEX = AlbumsByAlbumTitle */
WHERE AlbumTitle >= 'Aardvark' AND AlbumTitle < 'Goo';
Uma diretiva de índice pode forçar o processador de consultas do Spanner a ler colunas adicionais que são exigidas pela consulta, mas não são armazenadas no índice.
O processador de consultas recupera essas colunas unindo o índice e a tabela base. Para evitar essa mesclagem extra, use uma cláusula STORING
(bancos de dados de dialeto SQL padrão do Google) ou INCLUDE
(bancos de dados do dialeto PostgreSQL) para armazenar as outras colunas no índice.
Por exemplo, no exemplo mostrado acima, a coluna MarketingBudget
não é armazenada no índice, mas a consulta SQL seleciona essa coluna. Como resultado, o Spanner precisa pesquisar a coluna MarketingBudget
na tabela base e, em seguida, associá-la aos dados do índice para retornar os resultados da consulta.
O Spanner gerará um erro se a diretiva de índice tiver um dos seguintes problemas:
- O índice não existe.
- O índice está em uma tabela base diferente.
- Falta um a expressão de filtragem obrigatória
NULL
para um índiceNULL_FILTERED
.
Os exemplos a seguir mostram como gravar e executar consultas que buscam os valores de AlbumId
, AlbumTitle
e MarketingBudget
usando o índice AlbumsByAlbumTitle
:
C++
C#
Go
Java
Node.js
PHP
Python
Ruby
Especificar um índice na interface de leitura
Quando você usa a interface de leitura para o Spanner e quer que o Spanner use um índice, é necessário especificar o índice. A interface de leitura não seleciona o índice automaticamente.
Além disso, seu índice deve conter todos os dados que aparecem nos resultados da consulta, excluindo as colunas que fazem parte da chave primária. Essa restrição existe porque a interface de leitura não é compatível com junções entre o índice e a tabela base. Se você precisar incluir outras colunas nos resultados da consulta, terá algumas opções:
- Use uma cláusula
STORING
ouINCLUDE
para armazenar as outras colunas no índice. - Consulte sem incluir as colunas adicionais e use as chaves primárias para enviar outra consulta que lê as colunas adicionais.
O Spanner retorna valores do índice em ordem de classificação crescente por chave de índice. Para recuperar os valores em ordem decrescente, siga estas etapas:
Anote a chave de índice com
DESC
: Exemplo:CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle DESC);
A anotação
DESC
se aplica a uma única chave de índice. Se o índice incluir mais de uma chave e você desejar que os resultados apareçam em ordem descendente com base em todas as chaves, inclua uma anotaçãoDESC
para cada chave.Se a leitura especificar um intervalo de chaves, certifique-se de que o intervalo de chaves também esteja em ordem decrescente. Em outras palavras, o valor da chave inicial precisa ser maior que o valor da chave final.
O exemplo a seguir mostra como recuperar os valores de AlbumId
e AlbumTitle
usando o índice AlbumsByAlbumTitle
:
C++
C#
Go
Java
Node.js
PHP
Python
Ruby
Criar um índice para verificações somente de índice
Opcionalmente, use a cláusula STORING
(para bancos de dados do dialeto SQL padrão do Google) ou a cláusula INCLUDE
(para bancos de dados do dialeto PostgreSQL) para armazenar uma cópia de uma coluna no índice. Esse tipo de índice oferece vantagens para consultas e chamadas de leitura usando o índice, ao custo de usar armazenamento extra:
- As consultas SQL que usam o índice e selecionam as colunas armazenadas na cláusula
STORING
ouINCLUDE
não exigem uma junção adicional à tabela base. - As chamadas
read()
que usam o índice podem ler colunas armazenadas pela cláusulaSTORING
/INCLUDE
.
Por exemplo, suponha que você tenha criado uma versão alternativa de AlbumsByAlbumTitle
que armazena uma cópia da coluna MarketingBudget
no índice. Observe a
cláusula STORING
ou INCLUDE
em negrito:
SQL padrão do Google
CREATE INDEX AlbumsByAlbumTitle2 ON Albums(AlbumTitle) STORING (MarketingBudget);
PostgreSQL
CREATE INDEX AlbumsByAlbumTitle2 ON Albums(AlbumTitle) INCLUDE (MarketingBudget);
Com o antigo índice AlbumsByAlbumTitle
, o Spanner precisa unir o índice à tabela base e, em seguida, recuperar a coluna da tabela base. Com o novo índice AlbumsByAlbumTitle2
, o Spanner lê a coluna diretamente do índice, que é mais eficiente.
Se você usar a interface de leitura em vez de SQL, o novo índice AlbumsByAlbumTitle2
também permitirá que você leia a coluna MarketingBudget
diretamente:
C++
C#
Go
Java
Node.js
PHP
Python
Ruby
Índice de valores NULL
Por padrão, o Spanner indexa valores NULL
. Por exemplo, lembre-se da definição do índice SingersByFirstLastName
na tabela Singers
:
CREATE INDEX SingersByFirstLastName ON Singers(FirstName, LastName);
Todas as linhas de Singers
são indexadas mesmo se FirstName
ou LastName
, ou ambas, forem NULL
.
Quando valores NULL
são indexados, é possível realizar consultas SQL eficientes e leituras sobre dados que incluem valores NULL
. Por exemplo, use esta instrução de consulta SQL para encontrar todos Singers
com NULL
FirstName
:
SQL padrão do Google
SELECT s.SingerId, s.FirstName, s.LastName
FROM Singers@{FORCE_INDEX=SingersByFirstLastName} AS s
WHERE s.FirstName IS NULL;
PostgreSQL
SELECT s.SingerId, s.FirstName, s.LastName
FROM Singers /* @ FORCE_INDEX = SingersByFirstLastName */ AS s
WHERE s.FirstName IS NULL;
Ordem de classificação para valores NULL
O Spanner classifica NULL
como o menor valor de qualquer tipo. Para uma coluna em ordem crescente (ASC
), os valores NULL
são classificados primeiro. Para uma coluna em ordem decrescente (DESC
), os NULL
valores classificam por último.
Desativar a indexação de valores NULL
SQL padrão do Google
Para desativar a indexação de nulos, adicione a palavra-chave NULL_FILTERED
à definição do índice. Índices NULL_FILTERED
são particularmente úteis para indexar colunas esparsas, onde a maioria das linhas contém um valor NULL
. Nesses casos, o índice NULL_FILTERED
pode ser consideravelmente menor e mais eficiente de manter do que um índice normal que inclua valores NULL
.
Aqui está uma definição alternativa de SingersByFirstLastName
que não indexa os valores NULL
:
CREATE NULL_FILTERED INDEX SingersByFirstLastNameNoNulls
ON Singers(FirstName, LastName);
A palavra-chave NULL_FILTERED
se aplica a todas as colunas de chave de índice. Não é possível especificar a filtragem de NULL
por coluna.
PostgreSQL
Para filtrar linhas com valores nulos em uma ou mais colunas indexadas, use o predicado WHERE COLUMN IS NOT NULL
.
Índices filtrados por nulo são especialmente úteis para indexar colunas esparsas, em que a maioria das linhas contém um valor NULL
. Nesses casos, o índice filtrado por valores nulos pode ser consideravelmente menor e mais eficiente de manter do que um índice normal que inclui valores NULL
.
Aqui está uma definição alternativa de SingersByFirstLastName
que não indexa os valores NULL
:
CREATE INDEX SingersByFirstLastNameNoNulls
ON Singers(FirstName, LastName)
WHERE FirstName IS NOT NULL
AND LastName IS NOT NULL;
Filtrar os valores de NULL
impede que o Spanner o use em algumas consultas. Por exemplo, o Spanner não usa o índice para essa consulta, porque o índice omite qualquer linha Singers
em que LastName
seja NULL
. Como resultado, usar o índice impede que a consulta retorne as linhas corretas:
SQL padrão do Google
FROM Singers@{FORCE_INDEX=SingersByFirstLastNameNoNulls}
WHERE FirstName = "John";
PostgreSQL
FROM Singers /*@ FORCE_INDEX = SingersByFirstLastNameNoNulls */
WHERE FirstName = 'John';
Para permitir que o Spanner use o índice, é preciso reescrever a consulta para que ela exclua as linhas que também serão excluídas do índice:
SQL padrão do Google
SELECT FirstName, LastName
FROM Singers@{FORCE_INDEX=SingersByFirstLastNameNoNulls}
WHERE FirstName = 'John' AND LastName IS NOT NULL;
PostgreSQL
SELECT FirstName, LastName
FROM Singers /*@ FORCE_INDEX = SingersByFirstLastNameNoNulls */
WHERE FirstName = 'John' AND LastName IS NOT NULL;
Índices exclusivos
Os índices podem ser declarados como UNIQUE
. Os índices UNIQUE
adicionam uma restrição aos dados indexados que proíbem entradas duplicadas para uma determinada chave de índice.
Essa restrição é aplicada pelo Spanner no momento da confirmação da transação.
Especificamente, qualquer transação que gere várias entradas de índice para a mesma chave falhará na confirmação.
Se uma tabela contiver dados não UNIQUE
para começar, a tentativa de criar um índice UNIQUE
nela falhará.
Uma observação sobre índices UNIQUE NULL_FILTERED
Um índice UNIQUE NULL_FILTERED
não impõe a exclusividade da chave de índice quando pelo menos uma das partes de chave do índice é NULL.
Por exemplo, suponha que você tenha criado a tabela e o índice a seguir:
SQL padrão do Google
CREATE TABLE ExampleTable (
Key1 INT64 NOT NULL,
Key2 INT64,
Key3 INT64,
Col1 INT64,
) PRIMARY KEY (Key1, Key2, Key3);
CREATE UNIQUE NULL_FILTERED INDEX ExampleIndex ON ExampleTable (Key1, Key2, Col1);
PostgreSQL
CREATE TABLE ExampleTable (
Key1 BIGINT NOT NULL,
Key2 BIGINT,
Key3 BIGINT,
Col1 BIGINT,
PRIMARY KEY (Key1, Key2, Key3)
);
CREATE UNIQUE INDEX ExampleIndex ON ExampleTable (Key1, Key2, Col1)
WHERE Key1 IS NOT NULL
AND Key2 IS NOT NULL
AND Col1 IS NOT NULL;
As duas linhas a seguir em ExampleTable
têm os mesmos valores para as chaves de índice secundário Key1
, Key2
e Col1
:
1, NULL, 1, 1
1, NULL, 2, 1
Como Key2
é NULL
e o índice é filtrado por nulo, as linhas não estarão
presentes no índice ExampleIndex
. Como eles não foram inseridos no
índice, eles não serão rejeitados por violar a exclusividade em (Key1, Key2,
Col1)
.
Se você quiser que o índice imponha a exclusividade dos valores da tupla (Key1
,
Key2
, Col1
), será necessário anotar Key2
com NOT NULL
na definição da tabela
ou criar o índice sem filtrar nulos.
Remover um índice
Use a instrução DROP INDEX
para soltar um índice secundário do
seu esquema.
Para descartar o índice chamado SingersByFirstLastName
:
DROP INDEX SingersByFirstLastName;
Índice para verificação mais rápida
Quando o Spanner precisa realizar uma verificação de tabela (em vez de uma pesquisa indexada) para buscar valores de uma ou mais colunas, será possível receber resultados mais rapidamente se existir um índice para essas colunas e na ordem especificada pela consulta. Se você executa consultas com frequência com frequência, recomendamos a criação de índices secundários para ajudar a realizar essas verificações com mais eficiência.
Em especial, se você precisa que o Spanner verifique com frequência a chave primária de uma tabela ou outro índice em ordem inversa, é possível aumentar a eficiência por meio de um índice secundário que torna a ordem desejada explícita.
Por exemplo, a consulta abaixo sempre retorna um resultado rápido, mesmo que o Spanner precise verificar Songs
para encontrar o valor mais baixo de SongId
:
SELECT SongId FROM Songs LIMIT 1;
SongId
é a chave primária da tabela, armazenada em ordem crescente, assim como todas as chaves primárias. O Spanner pode verificar esse índice de chave e encontrar o primeiro resultado rapidamente.
No entanto, sem a ajuda de um índice secundário, a seguinte consulta não retornaria tão rapidamente, especialmente se Songs
contiver muitos dados:
SELECT SongId FROM Songs ORDER BY SongId DESC LIMIT 1;
Mesmo que SongId
seja a chave primária da tabela, o Spanner não poderá buscar o valor mais alto da coluna sem recorrer a uma verificação completa da tabela.
Adicionar o índice a seguir permitiria que essa consulta fosse retornada mais rapidamente:
CREATE INDEX SongIdDesc On Songs(SongId DESC);
Com esse índice ativado, o Spanner o usaria para retornar um resultado para a segunda consulta muito mais rapidamente.
A seguir
- Saiba mais sobre as práticas recomendadas de SQL para o Spanner.
- Entenda os planos de execução de consulta para o Spanner.
- Saiba como resolver problemas de regressões de desempenho em consultas SQL.