In einer Spanner-Datenbank erstellt Spanner automatisch einen Index für den Primärschlüssel jeder Tabelle. Beispielsweise müssen Sie nichts unternehmen, um den Primärschlüssel von Singers
zu indexieren, da er automatisch für Sie indexiert wird.
Sie können auch sekundäre Indexe für andere Spalten erstellen. Wenn Sie einen sekundären Index für eine Spalte hinzufügen, können Sie Daten in dieser Spalte effizienter nachschlagen. Wenn Sie beispielsweise schnell ein Album anhand des Titels suchen müssen, sollten Sie einen sekundären Index für AlbumTitle
erstellen, damit Spanner nicht die gesamte Tabelle scannen muss.
Wenn die Suche im vorherigen Beispiel innerhalb einer Lese-Schreib-Transaktion durchgeführt wird, vermeidet die effizientere Suche auch, Sperren für die gesamte Tabelle anzuhalten, was gleichzeitige Einfügungen und Aktualisierungen in der Tabelle für Zeilen außerhalb des Suchbereichs AlbumTitle
ermöglicht.
Neben den Vorteilen, die sie für Suchvorgänge bieten, können sekundäre Indexe Spanner auch dabei helfen, Scans effizienter auszuführen, sodass Indexscans anstelle von vollständigen Tabellenscans möglich sind.
Spanner speichert die folgenden Daten in jedem sekundären Index:
- Alle Schlüsselspalten aus der Basistabelle
- Alle Spalten, die im Index enthalten sind
- Alle Spalten, die in der optionalen
STORING
-Klausel (GoogleSQL-Dialekt-Datenbanken) oderINCLUDE
-Klausel (PostgreSQL-Dialekt-Datenbanken) der Indexdefinition angegeben sind.
Im Laufe der Zeit analysiert Spanner Ihre Tabellen, um sicherzustellen, dass Ihre sekundären Indexe für die entsprechenden Abfragen verwendet werden.
Sekundären Index hinzufügen
Am effizientesten ist die Erweiterung einer Tabelle um einen sekundären Index gleich bei deren Erstellung. Wenn Sie eine Tabelle und ihre Indexe gleichzeitig erstellen möchten, senden Sie die DDL-Anweisungen für die neue Tabelle und die neuen Indexe in einer einzigen Anfrage an Spanner.
In Spanner können Sie einer vorhandenen Tabelle auch einen neuen sekundären Index hinzufügen, während die Datenbank weiterhin Traffic bereitstellt. Wie bei allen anderen Schemaänderungen in Spanner muss beim Hinzufügen eines Index zu einer vorhandenen Datenbank die Datenbank nicht offline geschaltet werden und es werden keine ganzen Spalten oder Tabellen gesperrt.
Immer wenn ein neuer Index zu einer vorhandenen Tabelle hinzugefügt wird, führt Spanner automatisch einen Backfill durch, der den Index so füllt, dass er eine aktuelle Ansicht der indexierten Daten darstellt. Spanner verwaltet diesen Backfill-Prozess für Sie. Der Prozess wird im Hintergrund mit Knotenressourcen mit niedriger Priorität ausgeführt. In den meisten Fällen ist es nicht möglich, den Prozess zu beschleunigen (z.B. durch Hinzufügen weiterer Knoten) und Backfill beeinträchtigt die Leistung der Datenbank nicht wesentlich.
Die Indexerstellung kann mehrere Minuten bis hin zu vielen Stunden in Anspruch nehmen. Da die Indexerstellung eine Schemaaktualisierung ist, unterliegt sie denselben Leistungsbeschränkungen wie jede andere Schemaaktualisierung. Wie viel Zeit zum Erstellen eines sekundären Index benötigt wird, hängt von mehreren Faktoren ab:
- Die Größe des Datasets
- Rechenkapazität der Instanz
- Auslastung der Instanz
Den Fortschritt eines Index-Backfill-Prozesses können Sie im Abschnitt „Fortschritt“ aufrufen.
Die Verwendung der Spalte Commit-Zeitstempel als erster Teil des sekundären Index kann Hotspots erstellen und die Schreibleistung verringern.
Mit der Anweisung CREATE INDEX
definieren Sie einen sekundären Index in Ihrem Schema. Hier einige Beispiele:
So indexieren Sie alle Singers
in der Datenbank nach ihrem Vor- und Nachnamen:
GoogleSQL
CREATE INDEX SingersByFirstLastName ON Singers(FirstName, LastName);
PostgreSQL
CREATE INDEX SingersByFirstLastName ON Singers(FirstName, LastName);
So erstellen Sie einen Index aller Songs
in der Datenbank nach dem Wert von SongName
:
GoogleSQL
CREATE INDEX SongsBySongName ON Songs(SongName);
PostgreSQL
CREATE INDEX SongsBySongName ON Songs(SongName);
Wenn Sie nur die Titel eines bestimmten Interpreten indexieren möchten, verwenden Sie die Klausel INTERLEAVE IN
, um den Index in der Tabelle Singers
zu verschachteln:
GoogleSQL
CREATE INDEX SongsBySingerSongName ON Songs(SingerId, SongName),
INTERLEAVE IN Singers;
PostgreSQL
CREATE INDEX SongsBySingerSongName ON Songs(SingerId, SongName)
INTERLEAVE IN Singers;
So indexieren Sie nur die Titel eines bestimmten Albums:
GoogleSQL
CREATE INDEX SongsBySingerAlbumSongName ON Songs(SingerId, AlbumId, SongName),
INTERLEAVE IN Albums;
PostgreSQL
CREATE INDEX SongsBySingerAlbumSongName ON Songs(SingerId, AlbumId, SongName)
INTERLEAVE IN Albums;
So indexieren Sie nach SongName
in absteigender Reihenfolge:
GoogleSQL
CREATE INDEX SongsBySingerAlbumSongNameDesc ON Songs(SingerId, AlbumId, SongName DESC),
INTERLEAVE IN Albums;
PostgreSQL
CREATE INDEX SongsBySingerAlbumSongNameDesc ON Songs(SingerId, AlbumId, SongName DESC)
INTERLEAVE IN Albums;
Beachten Sie, dass die vorherige DESC
-Anmerkung nur für SongName
gilt. Wenn Sie nach anderen Indexschlüsseln in absteigender Reihenfolge indexieren möchten, versehen Sie sie ebenfalls mit DESC
: SingerId DESC, AlbumId DESC
.
Beachten Sie außerdem, dass PRIMARY_KEY
ein reserviertes Wort ist und nicht als Name eines Index verwendet werden kann. Dies ist der Name, der dem Pseudo-Index zugewiesen wird, der beim Erstellen einer Tabelle mit PRIMARY KEY-Spezifikation erstellt wird.
Weitere Informationen und Best Practices für die Auswahl nicht verschränkter Indexe und verschränkter Indexe finden Sie unter Indexoptionen und Verschränkte Indexe für eine Spalte verwenden, deren Wert monoton erhöht oder reduziert wird..
Fortschritt des Index-Backfills prüfen
Console
Klicken Sie im Spanner-Navigationsmenü auf den Tab Vorgänge. Auf der Seite Vorgänge wird eine Liste der derzeit ausgeführten Vorgänge angezeigt.
Suchen Sie in der Liste nach dem Backfill-Vorgang. Wenn er noch ausgeführt wird, zeigt der Fortschrittsindikator in der Spalte Ende den Prozentsatz des bereits abgeschlossenen Vorgangs an, wie in der folgenden Abbildung dargestellt:
gcloud
Mit gcloud spanner operations describe
können Sie den Fortschritt eines Vorgangs prüfen.
Rufen Sie die Vorgangs-ID ab:
gcloud spanner operations list --instance=INSTANCE-NAME \ --database=DATABASE-NAME --type=DATABASE_UPDATE_DDL
Ersetzen Sie Folgendes:
- INSTANCE-NAME durch den Namen der Spanner-Instanz.
- DATABASE-NAME durch den Namen der Datenbank.
Verwendungshinweise:
Wenn Sie die Liste einschränken möchten, geben Sie das Flag
--filter
an. Beispiel:--filter="metadata.name:example-db"
listet nur die Vorgänge für eine bestimmte Datenbank auf.--filter="error:*"
listet nur die Sicherungsvorgänge auf, die fehlgeschlagen sind.
Informationen zur Filtersyntax finden Sie unter gcloud topic filters. Informationen zum Filtern von Sicherungsvorgängen finden Sie im Feld
filter
in ListBackupOperationsRequest.Beim Flag
--type
wird nicht zwischen Groß- und Kleinschreibung unterschieden.
Die Ausgabe sieht dann ungefähr so aus:
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
Führen Sie
gcloud spanner operations describe
aus:gcloud spanner operations describe \ --instance=INSTANCE-NAME \ --database=DATABASE-NAME \ projects/PROJECT-NAME/instances/INSTANCE-NAME/databases/DATABASE-NAME/operations/OPERATION_ID
Ersetzen Sie Folgendes:
- INSTANCE-NAME: Der Name der Spanner-Instanz.
- DATABASE-NAME: Der Name der Spanner-Datenbank.
- PROJECT-NAME: Der Projektname.
- OPERATION-ID: Die Vorgangs-ID des Vorgangs, den Sie prüfen möchten.
Der Abschnitt
progress
in der Ausgabe zeigt den Prozentsatz des abgeschlossenen Vorgangs an. Die Ausgabe sieht in etwa so aus:done: true ... 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' ...
REST Version 1
Rufen Sie die Vorgangs-ID ab:
gcloud spanner operations list --instance=INSTANCE-NAME
--database=DATABASE-NAME --type=DATABASE_UPDATE_DDL
Ersetzen Sie Folgendes:
- INSTANCE-NAME durch den Namen der Spanner-Instanz.
- DATABASE-NAME durch den Namen der Datenbank.
Bevor Sie die Anfragedaten verwenden, ersetzen Sie die folgenden Werte:
- PROJECT-ID: Projekt-ID.
- INSTANCE-ID: Instanz-ID.
- DATABASE-ID: die Datenbank-ID.
- OPERATION-ID: die Vorgangs-ID.
HTTP-Methode und URL:
GET https://spanner.googleapis.com/v1/projects/PROJECT-ID/instances/INSTANCE-ID/databases/DATABASE-ID/operations/OPERATION-ID
Wenn Sie die Anfrage senden möchten, maximieren Sie eine der folgenden Optionen:
Sie sollten in etwa folgende JSON-Antwort erhalten:
{ ... "progress": [ { "progressPercent": 100, "startTime": "2023-05-27T00:52:27.366688Z", "endTime": "2023-05-27T00:52:30.184845Z" }, { "progressPercent": 100, "startTime": "2023-05-27T00:52:30.184845Z", "endTime": "2023-05-27T00:52:40.750959Z" } ], ... "done": true, "response": { "@type": "type.googleapis.com/google.protobuf.Empty" } }
Für gcloud
und REST finden Sie den Fortschritt jeder Index-Backfill-Anweisung im Abschnitt progress
. Für jede Anweisung im Anweisungsarray gibt es ein entsprechendes Feld im Fortschrittsarray. Die Reihenfolge des Fortschrittsarrays entspricht der Reihenfolge des Array-Arrays von Anweisungen. Sobald sie verfügbar sind, werden die Felder startTime
, progressPercent
und endTime
entsprechend ausgefüllt.
Die Ausgabe zeigt keine geschätzte Zeit für den Abschluss des Backfill-Fortschritts an.
Wenn der Vorgang zu lange dauert, können Sie ihn abbrechen. Weitere Informationen finden Sie unter Indexerstellung abbrechen.
Szenarien beim Ansehen des Index-Backfill-Fortschritts
Wenn Sie den Fortschritt eines Index-Backfills prüfen möchten, können verschiedene Szenarien auftreten. Anweisungen zur Indexerstellung, die einen Index-Backfill erfordern, sind Teil von Schemaaktualisierungsvorgängen. Es können mehrere Anweisungen vorhanden sein, die Teil eines Schemaaktualisierungsvorgangs sind.
Das erste Szenario ist das einfachste, nämlich wenn die Anweisung zur Indexerstellung die erste Anweisung im Schemaaktualisierungsvorgang ist. Da es sich bei der Anweisung zur Indexerstellung um die erste Anweisung handelt, ist sie die erste, die gemäß der Ausführungsreihenfolge verarbeitet und ausgeführt wird.
Das Feld startTime
der Anweisung zur Indexerstellung wird sofort mit der Startzeit der Schemaaktualisierung ausgefüllt. Als Nächstes wird das Feld progressPercent
der Anweisung zur Indexerstellung ausgefüllt, wenn der Fortschritt des Index-Backfills mehr als 0 % beträgt. Das Feld endTime
wird schließlich ausgefüllt, sobald der Commit der Anweisung ausgeführt wurde.
Das zweite Szenario liegt vor, wenn die Anweisung zur Indexerstellung nicht die erste Anweisung im Vorgang zur Schemaaktualisierung ist. Aufgrund der Reihenfolge der Ausführung werden keine Felder ausgefüllt, die sich auf die Anweisung zur Indexerstellung beziehen, bis das Commit der vorherigen Anweisung(en) durchgeführt wurde.
Ähnlich wie im vorherigen Szenario wird nach dem Commit der vorherigen Anweisungen zuerst das Feld startTime
der Anweisung zur Indexerstellung ausgefüllt, gefolgt vom Feld progressPercent
. Das Feld endTime
wird ausgefüllt, sobald der Commit der Anweisung abgeschlossen ist.
Indexerstellung abbrechen
Sie können die Google Cloud CLI verwenden, um die Indexerstellung abzubrechen. Verwenden Sie den Befehl gcloud spanner operations list
und fügen Sie die Option --filter
ein, um eine Liste von Schemaaktualisierungsvorgängen für eine Spanner-Datenbank abzurufen:
gcloud spanner operations list \
--instance=INSTANCE \
--database=DATABASE \
--filter="@TYPE:UpdateDatabaseDdlMetadata"
Suchen Sie nach der OPERATION_ID
des Vorgangs, den Sie abbrechen möchten, und brechen Sie ihn mit dem Befehl gcloud spanner operations cancel
ab:
gcloud spanner operations cancel OPERATION_ID \
--instance=INSTANCE \
--database=DATABASE
Vorhandene Indexe ansehen
Zum Aufrufen von Informationen zu vorhandenen Indexen in einer Datenbank können Sie die Google Cloud Console oder die Google Cloud CLI verwenden:
Console
Rufen Sie in der Google Cloud Console die Seite Spanner-Instanzen auf.
Klicken Sie auf den Namen der Instanz, die Sie aufrufen möchten.
Klicken Sie im linken Bereich auf die Datenbank, die Sie sich ansehen möchten, und klicken Sie dann auf die Tabelle, die Sie aufrufen möchten.
Klicken Sie auf den Tab Indexe. In der Google Cloud Console wird eine Liste der Indexe angezeigt.
Optional: Klicken Sie auf den Namen eines Index, um Details zu diesem zu erhalten, z. B. die Spalten, die er enthält.
gcloud
Führen Sie den Befehl gcloud spanner databases ddl describe
aus:
gcloud spanner databases ddl describe DATABASE \
--instance=INSTANCE
Die gcloud CLI gibt die DDL-Anweisungen (Data Definition Language) aus, um die Tabellen und Indexe der Datenbank zu erstellen. Die CREATE
INDEX
-Anweisungen beschreiben die vorhandenen Indexe. Beispiel:
--- |-
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)
Mit einem bestimmten Index abfragen
In den folgenden Abschnitten wird erläutert, wie Sie einen Index in einer SQL-Anweisung und mit der Leseschnittstelle für Spanner angeben. In den Beispielen in diesen Abschnitten wird davon ausgegangen, dass Sie der Tabelle Albums
eine Spalte MarketingBudget
hinzugefügt und einen Index mit dem Namen AlbumsByAlbumTitle
erstellt haben:
GoogleSQL
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);
Index in einer SQL-Anweisung angeben
Wenn Sie eine Spanner-Tabelle mit SQL abfragen, verwendet Spanner automatisch alle Indexe, die die Effizienz der Abfrage wahrscheinlich erhöhen. Daher müssen Sie für SQL-Abfragen keinen Index angeben. Bei Abfragen, die für Ihre Arbeitslast entscheidend sind, empfiehlt Google jedoch, FORCE_INDEX
-Anweisungen in Ihren SQL-Anweisungen zu verwenden, um eine konsistentere Leistung zu erzielen.
In einigen Fällen wählt Spanner möglicherweise einen Index aus, der die Abfragelatenz erhöht. Wenn Sie die Schritte zur Fehlerbehebung bei Leistungsabfällen ausgeführt haben und bestätigt haben, dass es sinnvoll ist, die Abfrage mit einem anderen Index zu versuchen, können Sie den Index als Teil Ihrer Abfrage angeben:
Wenn Sie einen Index in einer SQL-Anweisung angeben möchten, verwenden Sie den Hinweis FORCE_INDEX
, um eine Indexanweisung bereitzustellen. Indexanweisungen verwenden die folgende Syntax:
GoogleSQL
FROM MyTable@{FORCE_INDEX=MyTableIndex}
PostgreSQL
FROM MyTable /*@ FORCE_INDEX = MyTableIndex */
Sie können Spanner auch mit einer Indexanweisung anweisen, die Basistabelle zu scannen, anstatt einen Index zu verwenden:
GoogleSQL
FROM MyTable@{FORCE_INDEX=_BASE_TABLE}
PostgreSQL
FROM MyTable /*@ FORCE_INDEX = _BASE_TABLE */
Das folgende Beispiel zeigt eine SQL-Abfrage, die einen Index angibt:
GoogleSQL
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';
Eine Indexanweisung kann den Abfrageprozessor von Spanner zwingen, zusätzliche Spalten zu lesen, die für die Abfrage erforderlich sind, aber nicht im Index gespeichert sind.
Der Abfrageprozessor ruft diese Spalten ab, indem er den Index und die Basistabelle zusammenfügt. Um diesen zusätzlichen Join zu vermeiden, verwenden Sie eine STORING
-Klausel (GoogleSQL-Dialekt-Datenbanken) oder INCLUDE
-Klausel (PostgreSQL-Dialekt-Datenbanken), um die zusätzlichen Spalten im Index zu speichern.
Im vorherigen Beispiel wird die Spalte MarketingBudget
nicht im Index gespeichert, aber die SQL-Abfrage wählt diese Spalte aus. Daher muss Spanner die Spalte MarketingBudget
in der Basistabelle suchen und sie dann mit Daten aus dem Index verknüpfen, um die Abfrageergebnisse zurückzugeben.
Spanner gibt einen Fehler aus, wenn die Indexanweisung eines der folgenden Probleme aufweist:
- Der Index existiert nicht.
- Der Index befindet sich in einer anderen Basistabelle.
- Der Abfrage fehlt ein erforderlicher
NULL
-Filterausdruck für einenNULL_FILTERED
-Index.
Die folgenden Beispiele zeigen, wie Abfragen geschrieben und ausgeführt werden, die die Werte von AlbumId
, AlbumTitle
und MarketingBudget
mithilfe des Index AlbumsByAlbumTitle
abrufen:
C++
C#
Go
Java
Node.js
PHP
Python
Ruby
Index in der Leseschnittstelle angeben
Wenn Sie die Leseschnittstelle für Spanner verwenden und möchten, dass Spanner einen Index verwendet, müssen Sie den Index angeben. Die Leseschnittstelle wählt den Index nicht automatisch aus.
Darüber hinaus muss Ihr Index alle Daten enthalten, die in den Abfrageergebnissen angezeigt werden, mit Ausnahme der Spalten, die Teil des Primärschlüssels sind. Diese Einschränkung besteht, weil die Leseschnittstelle keine Joins zwischen dem Index und der Basistabelle unterstützt. Wenn Sie weitere Spalten mit in die Abfrageergebnisse einbeziehen möchten, haben Sie mehrere Möglichkeiten:
- Verwenden Sie eine
STORING
- oderINCLUDE
-Klausel, um die zusätzlichen Spalten im Index zu speichern. - Machen Sie Ihre Abfrage, ohne die zusätzlichen Spalten einzubeziehen, und senden Sie dann mithilfe der Primärschlüssel eine weitere Abfrage, die die zusätzlichen Spalten liest.
Spanner gibt Werte aus dem Index in aufsteigender Sortierreihenfolge nach Indexschlüssel zurück. Führen Sie die folgenden Schritte aus, um Werte in absteigender Reihenfolge abzurufen:
Kommentieren Sie den Indexschlüssel mit
DESC
. Beispiel:CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle DESC);
Die Anmerkung
DESC
gilt für einen einzelnen Indexschlüssel. Wenn der Index mehr als einen Schlüssel enthält und die Abfrageergebnisse auf Basis aller Schlüssel in absteigender Reihenfolge angezeigt werden sollen, fügen Sie für jeden Schlüssel eineDESC
-Anmerkung ein.Wenn der Lesevorgang einen Schlüsselbereich angibt, muss der Schlüsselbereich ebenfalls in absteigender Reihenfolge angegeben werden. Mit anderen Worten: Der Wert des Startschlüssels muss größer sein als der Wert des Endschlüssels.
Das folgende Beispiel veranschaulicht, wie die Werte von AlbumId
und AlbumTitle
mit dem Index AlbumsByAlbumTitle
abgerufen werden:
C++
C#
Go
Java
Node.js
PHP
Python
Ruby
Index für reine Indexscans erstellen
Optional können Sie die STORING
-Klausel (für GoogleSQL-Dialekt-Datenbanken) oder INCLUDE
(für PostgreSQL-Dialekt-Datenbanken) verwenden, um eine Kopie einer Spalte im Index zu speichern. Dieser Indextyp bietet Vorteile für Abfragen und Leseaufrufe unter Verwendung des Index, allerdings beansprucht das zusätzliche Speicherkapazität:
- SQL-Abfragen, die den Index verwenden und in der Klausel
STORING
oderINCLUDE
gespeicherte Spalten auswählen, benötigen keine zusätzliche Verknüpfung mit der Basistabelle. read()
-Aufrufe, die den Index verwenden, können von derSTORING
/INCLUDE
-Klausel gespeicherte Spalten lesen.
Angenommen, Sie haben eine alternative Version von AlbumsByAlbumTitle
erstellt, die eine Kopie der Spalte MarketingBudget
im Index speichert (beachten Sie die fett gedruckte STORING
- oder INCLUDE
-Klausel):
GoogleSQL
CREATE INDEX AlbumsByAlbumTitle2 ON Albums(AlbumTitle) STORING (MarketingBudget);
PostgreSQL
CREATE INDEX AlbumsByAlbumTitle2 ON Albums(AlbumTitle) INCLUDE (MarketingBudget);
Beim alten Index AlbumsByAlbumTitle
muss Spanner den Index mit der Basistabelle verknüpfen und dann die Spalte aus der Basistabelle abrufen. Beim neuen Index AlbumsByAlbumTitle2
liest Spanner die Spalte direkt aus dem Index, was effizienter ist.
Wenn Sie statt SQL die Leseschnittstelle verwenden, können Sie mit dem neuen Index AlbumsByAlbumTitle2
auch direkt die Spalte MarketingBudget
lesen:
C++
C#
Go
Java
Node.js
PHP
Python
Ruby
Index ändern
Mit der Anweisung ALTER INDEX
können Sie einem vorhandenen Index zusätzliche Spalten hinzufügen oder Spalten löschen. Dadurch kann die Spaltenliste aktualisiert werden, die beim Erstellen des Index von der STORING
-Klausel (GoogleSQL-Dialekt-Datenbanken) oder INCLUDE
-Klausel (PostgreSQL-Dialektdatenbanken) definiert wird. Sie können diese Anweisung nicht verwenden, um dem Indexschlüssel Spalten hinzuzufügen oder Spalten daraus zu löschen. Anstatt beispielsweise einen neuen Index AlbumsByAlbumTitle2
zu erstellen, können Sie ALTER INDEX
verwenden, um eine Spalte in AlbumsByAlbumTitle
hinzuzufügen, wie im folgenden Beispiel gezeigt:
GoogleSQL
ALTER INDEX AlbumsByAlbumTitle ADD STORED COLUMN MarketingBudget
PostgreSQL
ALTER INDEX AlbumsByAlbumTitle ADD INCLUDE COLUMN MarketingBudget
Wenn Sie einem vorhandenen Index eine neue Spalte hinzufügen, verwendet Spanner einen Hintergrund-Backfill-Prozess. Während der Backfill ausgeführt wird, ist die Spalte im Index nicht lesbar, sodass Sie möglicherweise nicht die erwartete Leistungssteigerung erhalten. Mit dem Befehl gcloud spanner operations
können Sie den lang andauernden Vorgang auflisten und seinen Status ansehen.
Weitere Informationen finden Sie unter Vorgang beschreiben.
Sie können auch einen Vorgang abbrechen abbrechen.
Nachdem der Backfill abgeschlossen ist, fügt Spanner die Spalte dem Index hinzu. Wenn der Index größer wird, kann dies die Abfragen verlangsamen, die den Index verwenden.
Das folgende Beispiel zeigt, wie Sie eine Spalte aus einem Index löschen:
GoogleSQL
ALTER INDEX AlbumsByAlbumTitle DROP STORED COLUMN MarketingBudget
PostgreSQL
ALTER INDEX AlbumsByAlbumTitle DROP INCLUDE COLUMN MarketingBudget
Index der NULL-Werte
NULL
-Werte werden von Spanner standardmäßig indexiert. Erinnern Sie sich beispielsweise an die Definition des Index SingersByFirstLastName
in der Tabelle Singers
:
CREATE INDEX SingersByFirstLastName ON Singers(FirstName, LastName);
Alle Zeilen von Singers
werden auch dann indexiert, wenn FirstName
oder LastName
oder beide NULL
sind.
Wenn NULL
-Werte indexiert werden, können Sie auf Daten, die NULL
-Werte enthalten, effiziente SQL-Abfragen und Leseaufrufe durchführen. Verwenden Sie beispielsweise diese SQL-Abfrageanweisung, um alle Singers
mit einem NULL
FirstName
zu finden:
GoogleSQL
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;
Sortierreihenfolge für NULL-Werte
Spanner sortiert NULL
als kleinsten Wert für einen bestimmten Typ. Bei einer Spalte in aufsteigender (ASC
) Reihenfolge werden NULL
-Werte als Erstes einsortiert. Bei einer Spalte in absteigender (DESC
) Reihenfolge werden NULL
-Werte als Letztes einsortiert.
Indexierung von NULL-Werten deaktivieren
GoogleSQL
Um die Indexierung von Null-Werten zu deaktivieren, fügen Sie das Schlüsselwort NULL_FILTERED
zur Indexdefinition hinzu. NULL_FILTERED
-Indexe sind besonders nützlich, wenn es um die Indexierung von dünnbesetzten Spalten geht, bei denen die meisten Zeilen einen NULL
-Wert enthalten. In diesen Fällen kann der NULL_FILTERED
-Index erheblich kleiner und effizienter zu pflegen sein als ein normaler Index, der NULL
-Werte enthält.
Hier eine alternative Definition von SingersByFirstLastName
, die keine NULL
-Werte indexiert:
CREATE NULL_FILTERED INDEX SingersByFirstLastNameNoNulls
ON Singers(FirstName, LastName);
Das Keyword NULL_FILTERED
gilt für alle Indexschlüsselspalten. Eine NULL
-Filterung kann nicht pro Spalte angegeben werden.
PostgreSQL
Verwenden Sie das Prädikat WHERE COLUMN IS NOT NULL
, um Zeilen mit Nullwerten in einer oder mehreren indexierten Spalten herauszufiltern.
Nach Null gefilterte Indexe sind besonders nützlich, um Spalten mit geringer Dichte zu indexieren, bei denen die meisten Zeilen einen NULL
-Wert enthalten. In diesen Fällen kann der nach Null gefilterte Index erheblich kleiner und effizienter zu verwalten sein als ein normaler Index, der NULL
-Werte enthält.
Hier eine alternative Definition von SingersByFirstLastName
, die keine NULL
-Werte indexiert:
CREATE INDEX SingersByFirstLastNameNoNulls
ON Singers(FirstName, LastName)
WHERE FirstName IS NOT NULL
AND LastName IS NOT NULL;
Durch das Herausfiltern von NULL
-Werten wird verhindert, dass Spanner diesen für einige Abfragen verwendet. Beispielsweise verwendet Spanner den Index für diese Abfrage nicht, da der Index alle Singers
-Zeilen auslässt, für die LastName
den Wert NULL
hat. Daher würde die Verwendung des Index verhindern, dass die Abfrage die richtigen Zeilen zurückgibt:
GoogleSQL
FROM Singers@{FORCE_INDEX=SingersByFirstLastNameNoNulls}
WHERE FirstName = "John";
PostgreSQL
FROM Singers /*@ FORCE_INDEX = SingersByFirstLastNameNoNulls */
WHERE FirstName = 'John';
Damit Spanner den Index verwenden kann, müssen Sie die Abfrage so umschreiben, dass die Zeilen ausgeschlossen werden, die ebenfalls aus dem Index ausgeschlossen sind:
GoogleSQL
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;
Index-Proto-Felder
Verwenden Sie generierte Spalten, um Felder in Protokollpuffern zu indexieren, die in PROTO
-Spalten gespeichert sind, sofern die zu indexierenden Felder den einfachen Datentyp oder den ENUM
-Datentyp verwenden.
Wenn Sie einen Index für ein Protokollnachrichtenfeld definieren, können Sie dieses Feld nicht aus dem Proto-Schema ändern oder entfernen. Weitere Informationen finden Sie unter Updates für Schemas, die einen Index für Proto-Felder enthalten.
Das folgende Beispiel zeigt die Tabelle Singers
mit einer .proto-Nachrichtenspalte SingerInfo
. Um einen Index für das Feld nationality
der PROTO
zu definieren, müssen Sie eine gespeicherte generierte Spalte erstellen:
GoogleSQL
CREATE PROTO BUNDLE (googlesql.example.SingerInfo, googlesql.example.SingerInfo.Residence);
CREATE TABLE Singers (
SingerId INT64 NOT NULL,
...
SingerInfo googlesql.example.SingerInfo,
SingerNationality STRING(MAX) AS (SingerInfo.nationality) STORED
) PRIMARY KEY (SingerId);
Sie hat die folgende Definition des Prototyps googlesql.example.SingerInfo
:
GoogleSQL
package googlesql.example;
message SingerInfo {
optional string nationality = 1;
repeated Residence residence = 2;
message Residence {
required int64 start_year = 1;
optional int64 end_year = 2;
optional string city = 3;
optional string country = 4;
}
}
Definieren Sie dann einen Index für das Feld nationality
des Protokolls:
GoogleSQL
CREATE INDEX SingersByNationality ON Singers(SingerNationality);
Die folgende SQL-Abfrage liest Daten mit dem vorherigen Index:
GoogleSQL
SELECT s.SingerId, s.FirstName
FROM Singers AS s
WHERE s.SingerNationality = "English";
Hinweise:
- Verwenden Sie eine Indexanweisung, um auf Indexe für die Felder von Protokollpufferspalten zuzugreifen.
- Sie können keinen Index für wiederkehrende Protokollpufferfelder erstellen.
Aktualisierungen von Schemas, die einen Index für Proto-Felder enthalten
Wenn Sie einen Index für ein Protokollnachrichtenfeld definieren, können Sie dieses Feld nicht aus dem Proto-Schema ändern oder entfernen. Dies liegt daran, dass nach der Definition des Index bei jeder Aktualisierung des Schemas eine Typprüfung durchgeführt wird. Spanner erfasst die Typinformationen für alle Felder im Pfad, die in der Indexdefinition verwendet werden.
Eindeutige Indexe
Indexe können als UNIQUE
deklariert werden. UNIQUE
-Indexe fügen den indexierten Daten eine Einschränkung hinzu, die doppelte Einträge für einen bestimmten Indexschlüssel verbietet.
Diese Einschränkung wird von Spanner zum Zeitpunkt des Transaktions-Commits erzwungen.
Genauer gesagt kann eine Transaktion, die dazu führen würde, dass mehrere Indexeinträge für denselben Schlüssel existieren, nicht ausgeführt werden.
Wenn eine Tabelle anfänglich keine UNIQUE
-Daten enthält, schlägt der Versuch fehl, einen UNIQUE
-Index zu erstellen.
Ein Hinweis zu UNIQUE NULL_FILTERED-Indexen
Ein UNIQUE NULL_FILTERED
-Index erzwingt keine Eindeutigkeit des Indexschlüssels, wenn mindestens eine der Schlüsselkomponenten des Index NULL ist.
Angenommen, Sie haben die folgende Tabelle und den folgenden Index erstellt:
GoogleSQL
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;
Die folgenden zwei Zeilen in ExampleTable
weisen die gleichen Werte für die Sekundärindexschlüssel Key1
, Key2
und Col1
auf:
1, NULL, 1, 1
1, NULL, 2, 1
Da Key2
auf NULL
gesetzt ist und der Index nach Nullwerten gefiltert ist, sind die Zeilen nicht im Index ExampleIndex
vorhanden. Da sie nicht in den Index eingefügt werden, lehnt der Index sie nicht für einen Verstoß gegen die Eindeutigkeit von (Key1, Key2,
Col1)
ab.
Wenn der Index die Eindeutigkeit der Werte des Tupels (Key1
, Key2
, Col1
) erzwingen soll, müssen Sie Key2
in der Tabellendefinition mit NOT NULL
annotieren oder den Index erstellen, ohne Nullen zu filtern.
Index löschen
Mit der Anweisung DROP INDEX
löschen Sie einen sekundären Index aus Ihrem Schema.
So löschen Sie den Index mit dem Namen SingersByFirstLastName
:
DROP INDEX SingersByFirstLastName;
Index für schnelleres Scannen
Wenn Spanner einen Tabellenscan (statt einer indexierten Suche) ausführen muss, um Werte aus einer oder mehreren Spalten abzurufen, erhalten Sie schneller Ergebnisse, wenn für diese Spalten ein Index in der von der Abfrage angegebenen Reihenfolge vorhanden ist. Wenn Sie häufig Abfragen ausführen, die Scans erfordern, sollten Sie sekundäre Indexe erstellen, damit diese Scans effizienter ausgeführt werden können.
Wenn Spanner den Primärschlüssel einer Tabelle oder einen anderen Index häufig in umgekehrter Reihenfolge scannen muss, können Sie dessen Effizienz erhöhen, indem Sie einen sekundären Index verwenden, der die ausgewählte Reihenfolge explizit macht.
Die folgende Abfrage gibt beispielsweise immer ein schnelles Ergebnis zurück, obwohl Spanner Songs
scannen muss, um den niedrigsten Wert von SongId
zu finden:
SELECT SongId FROM Songs LIMIT 1;
SongId
ist der Primärschlüssel der Tabelle. Er wird wie alle Primärschlüssel in aufsteigender Reihenfolge gespeichert. Spanner kann den Index dieses Schlüssels scannen und schnell das erste Ergebnis finden.
Ohne einen sekundären Index würde die folgende Abfrage jedoch nicht so schnell zurückgegeben werden, insbesondere wenn Songs
viele Daten enthält:
SELECT SongId FROM Songs ORDER BY SongId DESC LIMIT 1;
Obwohl SongId
der Primärschlüssel der Tabelle ist, hat Spanner keine Möglichkeit, den höchsten Wert der Spalte abzurufen, ohne auf einen vollständigen Tabellenscan zurückzugreifen.
Wenn Sie den folgenden Index hinzufügen, könnte die Abfrage schneller Ergebnisse liefern:
CREATE INDEX SongIdDesc On Songs(SongId DESC);
Wenn dieser Index vorhanden ist, würde Spanner ihn verwenden, um ein Ergebnis für die zweite Abfrage viel schneller zurückzugeben.
Nächste Schritte
- SQL-Best Practices für Spanner
- Abfrageausführungspläne für Spanner
- Weitere Informationen zur Fehlerbehebung bei Leistungsregressionen in SQL-Abfragen