Comme décrit dans la section Plans d'exécution de requêtes, le compilateur SQL transforme une instruction SQL en un plan d'exécution de requêtes, utilisée pour obtenir les résultats de la requête. Cette page décrit les bonnes pratiques Créer des instructions SQL pour aider Spanner à trouver une exécution efficace de votre abonnement.
Les exemples d'instructions SQL présentés sur cette page utilisent l'exemple de schéma suivant:
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;
Pour obtenir une documentation de référence complète sur SQL, consultez les pages Syntaxe des requêtes, Fonctions et opérateurs et Structure lexicale et syntaxe.
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;
Pour en savoir plus, consultez Le langage PostgreSQL dans Spanner.
Utiliser des paramètres de requête
Spanner accepte les paramètres de requête pour améliorer les performances empêchent l'injection SQL lorsque les requêtes sont créées à l'aide d'une entrée utilisateur. Vous pouvez utiliser des paramètres de requête comme substituts d'expressions arbitraires, mais pas comme substitue des identifiants, des noms de colonne, des noms de table ou d'autres parties du requête.
Les paramètres peuvent apparaître partout où une valeur littérale est attendue. Identique peut être utilisé plusieurs fois dans une seule instruction SQL.
En résumé, les paramètres de requête permettent d'exécuter des requêtes de différentes manières:
- Plans préoptimisés: les requêtes qui utilisent des paramètres peuvent être exécutées plus rapidement sur chaque appel, car le paramétrage facilite Spanner pour mettre en cache le plan d'exécution.
- Composition de requête simplifiée: il n'est pas nécessaire d'échapper les valeurs de chaîne lorsque en les fournissant dans les paramètres de requête. Les paramètres de requête réduisent également le risque d'erreurs de syntaxe.
- Sécurité: les paramètres de requête renforcent la sécurité de vos requêtes en vous protégeant contre différentes attaques par injection SQL. Cette protection est particulièrement importante pour les requêtes que vous créez à partir d'entrées utilisateur.
Comprendre comment Spanner exécute les requêtes
Spanner vous permet d'interroger des bases de données à l'aide d'instructions SQL déclaratives spécifiant les données à récupérer. Si vous voulez comprendre comment Spanner obtient les résultats et examine le plan d'exécution de la requête. A de requête affiche le coût de calcul associé à chaque étape de la requête. À l'aide de ces coûts, vous pouvez déboguer les problèmes de performance et optimiser votre requête. Pour en savoir plus, consultez Plans d'exécution de requêtes.
Vous pouvez récupérer les plans d'exécution de requêtes via la console Google Cloud ou les bibliothèques clientes.
Afin d'obtenir un plan d'exécution pour une requête spécifique à l'aide de la console Google Cloud, procédez comme suit:
Ouvrez la page des instances Spanner.
Sélectionnez les noms de l'instance Spanner et de la base de données que vous que vous souhaitez interroger.
Cliquez sur Spanner Studio dans le panneau de navigation de gauche.
Saisissez la requête dans le champ de texte, puis cliquez sur Exécuter la requête.
Cliquez sur Explication
. La console Google Cloud affiche un visuel pour votre requête.
Pour savoir comment comprendre les plans visuels et les utiliser pour déboguer vos requêtes, consultez la section Régler une requête à l'aide du visualiseur du plan de requête.
Vous pouvez aussi consulter des exemples de plans de requêtes historiques et comparer les performances d'une requête au fil du temps pour certaines requêtes. Pour en savoir plus, consultez Exemples de plans de requête
Utiliser des index secondaires
Comme d'autres bases de données relationnelles, Spanner offre des index secondaires, vous pouvez utiliser pour récupérer des données à l'aide d'une instruction SQL ou Interface de lecture de Spanner La méthode la plus courante pour récupérer des données consiste à utiliser Spanner Studio. Utiliser un index secondaire dans une requête SQL permet d'indiquer comment vous souhaitez que Spanner obtienne les résultats. La spécification d'un index secondaire peut accélérer l'exécution des requêtes.
Par exemple, supposons que vous vouliez récupérer les identifiants de tous les chanteurs ayant une chaîne un nom de famille spécifique. La requête SQL pourrait être écrite de cette façon (par exemple) :
SELECT s.SingerId
FROM Singers AS s
WHERE s.LastName = 'Smith';
Cette requête renverrait les résultats attendus, mais son traitement pourrait prendre du temps. Le délai dépend du nombre de lignes de la table Singers
et du nombre de lignes correspondant au prédicat WHERE s.LastName = 'Smith'
. S'il n'y a pas d'index secondaire contenant la colonne LastName
à lire, le plan de requête lira l'intégralité de la table Singers
pour rechercher les lignes correspondant au prédicat. En lisant l'intégralité
est appelée analyse complète de la table. Une analyse complète de la table
moyen d'obtenir les résultats lorsque la table ne contient qu'un faible pourcentage
Singers
par ce nom de famille.
Pour améliorer les performances de cette requête, définissez un index secondaire sur la colonne du nom de famille, comme suit :
CREATE INDEX SingersByLastName ON Singers (LastName);
Comme l'index secondaire SingersByLastName
contient la table indexée
la colonne LastName
et la colonne de clé primaire SingerId
, Spanner peut
récupérer toutes les données de la table d'index, bien plus petite, au lieu d'analyser
la table Singers
complète.
Dans ce scénario, Spanner utilise automatiquement le serveur
l'index SingersByLastName
lors de l'exécution de la requête (tant que la période de 3 jours
transmis depuis la création de la base de données ; voir
Remarque sur les nouvelles bases de données). Cependant, il est préférable de
pour indiquer explicitement à Spanner d'utiliser cet index
Une directive index dans la clause 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';
Supposons maintenant que vous souhaitiez également récupérer le prénom du chanteur en plus de son identifiant. Même si la colonne FirstName
ne fait pas partie de l'index, vous devez toujours spécifier la directive d'index comme auparavant, de la manière suivante :
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';
L'utilisation de l'index améliore les performances, car Spanner
n'a pas besoin d'effectuer une analyse complète de la table lors de l'exécution du plan de requête. Au lieu de cela, il
sélectionne le sous-ensemble de lignes concordant avec le prédicat à partir de SingersByLastName
.
puis effectue une recherche à partir de la table de base Singers
pour récupérer
uniquement pour ce sous-ensemble de lignes.
Si vous souhaitez que Spanner n'ait pas à extraire de lignes de la base
vous pouvez stocker une copie de la colonne FirstName
dans
de l'index lui-même:
GoogleSQL
CREATE INDEX SingersByLastName ON Singers (LastName) STORING (FirstName);
PostgreSQL
CREATE INDEX SingersByLastName ON Singers (LastName) INCLUDE (FirstName);
En utilisant une clause STORING
(pour le dialecte GoogleSQL) ou une clause INCLUDE
(pour le dialecte PostgreSQL) comme celle-ci nécessite du stockage supplémentaire,
offre les avantages suivants:
- Requêtes SQL qui utilisent l'index et sélectionnent les colonnes stockées dans le
STORING
ou La clauseINCLUDE
ne nécessite pas de jointure supplémentaire à la table de base. - Les appels de lecture qui utilisent l'index peuvent lire les colonnes stockées dans le
STORING
ouINCLUDE
.
Les exemples ci-dessus illustrent comment les index secondaires peuvent accélérer les requêtes, en particulier lorsque ce type d'index permet d'identifier rapidement les lignes choisies par la clause WHERE
d'une requête.
Un autre scénario dans lequel les index secondaires peuvent offrir des avantages en termes de performance concerne certaines requêtes qui renvoient des résultats ordonnés. Pour Imaginons, par exemple, que vous souhaitiez récupérer tous les titres d'albums et leurs dates de sortie. par ordre croissant de date de disponibilité et par ordre décroissant de titre d'album. Vous pouvez écrire une requête SQL comme suit:
SELECT a.AlbumTitle, a.ReleaseDate
FROM Albums AS a
ORDER BY a.ReleaseDate, a.AlbumTitle DESC;
Sans index secondaire, cette requête nécessite une étape de tri potentiellement coûteuse dans le plan d'exécution. Vous pouvez accélérer l'exécution de la requête en définissant l'index secondaire suivant :
CREATE INDEX AlbumsByReleaseDateTitleDesc on Albums (ReleaseDate, AlbumTitle DESC);
Ensuite, réécrivez la requête pour utiliser l'index secondaire:
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;
Cette requête et cette définition d'index répondent aux deux critères suivants:
- Pour supprimer l'étape de tri, assurez-vous que la liste des colonnes dans
ORDER BY
est un préfixe de la liste des clés d'index. - Pour éviter de joindre de nouveau la table de base pour récupérer les colonnes manquantes, s'assurer que l'index couvre toutes les colonnes de la table utilisées par la requête.
Bien que les index secondaires puissent accélérer les requêtes courantes, peuvent ajouter de la latence à vos opérations de commit, car chaque index secondaire Les index secondaires nécessitent généralement l'implication d'un nœud supplémentaire dans chaque commit. Pour la plupart des charges de travail, quelques index secondaires sont suffisants. Cependant, vous devez déterminer si vous êtes plus soucieux de la latence en lecture ou en écriture, ainsi que les opérations les plus critiques pour votre charge de travail. Analysez vos charge de travail pour s'assurer qu'elle fonctionne comme prévu.
Pour obtenir une documentation de référence complète sur les index secondaires, consultez la page Index secondaires.
Optimiser les analyses
Certaines requêtes Spanner peuvent bénéficier de l'utilisation d'une méthode lors de l'analyse des données plutôt que l'approche plus courante de traitement de texte. Le traitement des analyses par lot est un moyen plus efficace qui traite d'importants volumes de données en une seule fois, et permet aux requêtes d'atteindre une baisse de l'utilisation du processeur et de la latence.
L'opération d'analyse Spanner démarre toujours dans sur les lignes et les lignes. Pendant ce temps, Spanner collecte plusieurs métriques d'exécution. Ensuite, Spanner applique un ensemble de méthodes heuristiques sur la base des résultats de ces métriques pour déterminer le mode d'analyse optimal. Quand ? approprié, Spanner passe à un mode de traitement par lot pour améliorer le débit et les performances des analyses.
Cas d'utilisation courants
Les requêtes présentant les caractéristiques suivantes bénéficient généralement de l'utilisation Traitement par lot:
- Analyses volumineuses sur des données rarement mises à jour.
- Effectue des analyses avec des prédicats sur des colonnes à largeur fixe.
- Analyses avec un nombre élevé de recherches. (Une recherche utilise un index pour récupérer les enregistrements.)
Cas d'utilisation sans gains de performances
Toutes les requêtes ne bénéficient pas du traitement par lot. La requête suivante sont plus performants avec le traitement d'analyse orienté ligne:
- Requêtes de recherche par point: requêtes qui ne récupèrent qu'une seule ligne.
- Requêtes d'analyse mineures: analyses de table qui n'analysent que quelques lignes, à moins qu'elles n'aient plus de requêtes larges.
- Requêtes qui utilisent
LIMIT
- Requêtes qui lisent des données avec une forte perte d'utilisateurs: requêtes dans lesquelles plus d'environ 10% des les données lues sont fréquemment mises à jour.
- Requêtes dont les lignes contiennent des valeurs importantes (les lignes volumineuses sont celles contenant des valeurs supérieures à 32 000 octets (précompression) dans une seule .
Vérifier la méthode d'analyse utilisée par une requête
Pour vérifier si votre requête utilise le traitement par lot, le traitement orienté lignes ou bascule automatiquement d'une méthode d'analyse à l'autre:
Accédez à la page Instances de Spanner dans la console Google Cloud.
Cliquez sur le nom de l'instance associée à la requête que vous souhaitez examiner.
Sous le tableau Bases de données, cliquez sur la base de données contenant la requête souhaitée. à enquêter.
Dans le menu de navigation, cliquez sur Spanner Studio.
Ouvrir un nouvel onglet en cliquant sur
Nouvel onglet de l'éditeur SQL ou Nouvel onglet.Lorsque l'éditeur de requête s'affiche, rédigez votre requête.
Cliquez sur Exécuter.
Spanner exécute la requête et affiche les résultats.
Cliquez sur l'onglet Explication sous l'éditeur de requête.
Spanner affiche un visualiseur du plan d'exécution du plan de requête. Chaque fiche du graphique représente un itérateur.
Cliquez sur la carte d'itérateur Table scan pour ouvrir un panneau d'informations.
Le panneau d'informations affiche des informations contextuelles sur l'analyse sélectionnée. La méthode de numérisation est indiquée sur cette carte. Automatique : indique que Spanner détermine l'analyse . Les autres valeurs possibles sont Vectorized pour les valeurs par lot. et Scalaire pour un traitement orienté lignes.
Appliquer la méthode d'analyse utilisée par une requête
Pour optimiser les performances des requêtes, Spanner choisit l'analyse optimale pour votre requête. Nous vous recommandons d'utiliser cette méthode d'analyse par défaut. Toutefois, il se peut que vous souhaitiez appliquer une règle type de méthode d'analyse.
Comment appliquer une analyse par lot
Vous pouvez appliquer une analyse par lot au niveau de la table et des instructions.
Pour appliquer la méthode d'analyse par lot au niveau de la table, utilisez une suggestion de table. dans votre requête:
GoogleSQL
SELECT ...
FROM (t1@{SCAN_METHOD=BATCH} JOIN t2 ON ...)
WHERE ...
PostgreSQL
SELECT ...
FROM (t1/*@ scan_method=batch */ JOIN t2 on ...)
WHERE ...
Pour appliquer la méthode d'analyse par lot au niveau de l'instruction, utilisez un dans votre requête:
GoogleSQL
@{SCAN_METHOD=BATCH}
SELECT ...
FROM ...
WHERE ...
PostgreSQL
/*@ scan_method=batch */
SELECT ...
FROM ...
WHERE ...
Désactiver l'analyse automatique et appliquer une analyse par ligne
Bien qu'il soit déconseillé de désactiver la méthode d'analyse automatique définie par Spanner, vous pouvez décider de le désactiver et d'utiliser de recherche orientée ligne à des fins de dépannage, pour diagnostiquer par exemple la latence.
Pour désactiver la méthode d'analyse automatique et appliquer le traitement des lignes à la table utilisez un indice de table dans votre requête:
GoogleSQL
SELECT ...
FROM (t1@{SCAN_METHOD=ROW} JOIN t2 ON ...)
WHERE ...
PostgreSQL
SELECT ...
FROM (t1/*@ scan_method=row */ JOIN t2 on ...)
WHERE ...
Pour désactiver la méthode d'analyse automatique et appliquer le traitement des lignes au niveau de l'instruction utilisez un indice d'instruction dans votre requête:
GoogleSQL
@{SCAN_METHOD=ROW}
SELECT ...
FROM ...
WHERE ...
PostgreSQL
/*@ scan_method=row */
SELECT ...
FROM ...
WHERE ...
Optimiser les recherches de clés de plage
Une requête SQL est couramment utilisée pour lire plusieurs lignes basées sur Spanner sur une liste de clés connues.
Les bonnes pratiques suivantes vous aident à écrire des requêtes efficaces lors de la récupération des données à l'aide d'une plage de clés:
Si la liste de clés est fragmentée et non adjacente, utilisez les paramètres de requête et
UNNEST
pour créer votre requête.Par exemple, si votre liste de clés correspond à
{1, 5, 1000}
, écrivez la requête de la manière suivante :GoogleSQL
SELECT * FROM Table AS t WHERE t.Key IN UNNEST (@KeyList)
PostgreSQL
SELECT * FROM Table AS t WHERE t.Key IN UNNEST ($1)
Remarques :
L'opérateur de tableau UNNEST aplatit un tableau d'entrée sous la forme de lignes d'éléments.
Le paramètre de requête, qui est
@KeyList
pour GoogleSQL et$1
pour PostgreSQL, peuvent accélérer votre requête, bonnes pratiques précédentes.
Si la liste de clés est adjacente et comprise dans une plage, indiquez les valeurs inférieure et des limites supérieures pour la plage de clés dans la clause
WHERE
;Par exemple, si votre liste de clés correspond à
{1,2,3,4,5}
, créez la requête comme suit : ce qui suit: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
Cette requête n'est plus efficace que si les clés de la plage de clés adjacent. En d'autres termes, si votre liste de clés est
{1, 5, 1000}
, spécifier les limites inférieure et supérieure comme dans la requête précédente, car le la requête résultante analyserait chaque valeur comprise entre 1 et 1000.
Jointures Optimize
Les opérations de jointure peuvent être coûteuses, car elles peuvent considérablement augmenter le nombre de lignes que votre requête doit analyser, ce qui entraîne les requêtes plus lentes. En plus des techniques que vous avez l'habitude d'utiliser, dans d'autres bases de données relationnelles afin d'optimiser les requêtes de jointure, voici quelques bonnes pratiques pour une jointure plus efficace lors de l'utilisation de Spanner SQL:
Si possible, joignez des données dans des tables entrelacées par clé primaire. Exemple :
SELECT s.FirstName, a.ReleaseDate FROM Singers AS s JOIN Albums AS a ON s.SingerId = a.SingerId;
Vous avez la garantie que les lignes de la table entrelacée
Albums
sont physiquement stockées dans les mêmes divisions que la ligne parente dansSingers
, comme indiqué sur la page Schéma et modèle de données. Les jointures peuvent donc être effectuées localement sans envoyer beaucoup de données sur le réseau.Utilisez la directive de jointure si vous souhaitez forcer l'ordre de la jointure. Exemple :
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%';
La directive de jointure
FORCE_JOIN_ORDER
indique à Spanner d'utiliser l'ordre de jointure spécifié dans la requête (c'est-à-direSingers JOIN Albums
, et nonAlbums JOIN Singers
). Les résultats renvoyés sont les mêmes, quel que soit le choisi par Spanner. Toutefois, vous pouvez utiliser cette jointure si vous remarquez dans le plan de requête que Spanner a changé l'ordre de jointure et causait des conséquences indésirables, telles que résultats ou a manqué des opportunités de recherche de lignes.Utilisez une directive de jointure pour choisir une mise en œuvre de jointure. Lorsque vous utilisez SQL pour interroger plusieurs tables, Spanner utilise automatiquement une méthode de jointure qui est susceptible de rendre la requête plus efficace. Cependant, Google vous recommande de tester différents algorithmes de jointure. Le choix du bon algorithme de jointure peut améliorer la latence, la consommation de mémoire ou les deux. Cette requête montre la syntaxe d'utilisation d'une directive JOIN avec la suggestion
JOIN_METHOD
pour choisir unHASH 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
Si vous utilisez un
HASH JOIN
ou unAPPLY JOIN
, et si vous avez unWHERE
très sélective d'un côté de votreJOIN
, placez la table qui génère le plus petit nombre de lignes pour la première table de laFROM
de la jointure. Cette structure est utile, car actuellement dansHASH JOIN
, Spanner choisit toujours la table de gauche pour la compilation et comme une vérification. De même, pourAPPLY JOIN
, Spanner choisit la table de gauche comme table extérieure et la table de droite comme table interne. Pour en savoir plus sur ces types de jointures, consultez les articles Jointure de hachage et Demandez à rejoindre le groupe.Pour les requêtes critiques pour votre charge de travail, spécifiez la version la plus performante et l'ordre de jointure dans vos instructions SQL pour une meilleure cohérence des performances.
Éviter les opérations de lecture de grande taille dans les transactions en lecture-écriture
Les transactions en lecture-écriture autorisent une séquence de zéro ou plusieurs lectures ou requêtes SQL et peuvent inclure un ensemble de mutations avant un appel à validation. Pour maintenir la cohérence de vos données, Spanner acquiert des verrous lors de la lecture et de l'écriture de lignes dans vos tables et index. Pour Pour en savoir plus sur le verrouillage, consultez la page Déroulement des opérations de lecture et d'écriture.
En raison du fonctionnement du verrouillage dans Spanner, l'exécution d'une requête
Requête qui lit un grand nombre de lignes (par exemple, SELECT * FROM Singers
)
signifie qu'aucune autre transaction ne peut écrire dans les lignes lues
votre transaction est validée ou annulée.
De plus, comme votre transaction traite un grand nombre de lignes,
prendre plus de temps qu'une transaction qui lit une plage de lignes beaucoup plus petite
(par exemple, SELECT LastName FROM Singers WHERE SingerId = 7
), ce qui
cela exacerbe le problème et réduit le débit du système.
Essayez donc d'éviter les lectures volumineuses (par exemple, les analyses complètes de table ou les jointures massives). opérations) dans vos transactions, sauf si vous acceptez débit.
Dans certains cas, la méthode suivante peut donner de meilleurs résultats:
- Effectuez vos lectures volumineuses dans une transaction en lecture seule. Les transactions en lecture seule permettent un débit agrégé plus élevé, car elles n'utilisent pas de serrures.
- Facultatif: effectuez le traitement requis sur les données que vous venez de lire.
- Démarrez une transaction en lecture-écriture.
- Vérifiez que les lignes critiques n'ont pas changé de valeur depuis que vous avez effectué
la transaction en lecture seule de l'étape 1.
- Si les lignes ont changé, annulez votre transaction et recommencez à l'étape 1.
- Si tout se passe bien, validez vos mutations.
Une façon de s'assurer que vous évitez les lectures de grande taille en mode lecture/écriture transactions consiste à examiner les plans d'exécution générés par vos requêtes.
Utiliser ORDER BY pour garantir le classement de vos résultats SQL
Si vous attendez un certain classement des résultats d'une requête SELECT
,
inclure explicitement la clause ORDER BY
. Par exemple, si vous souhaitez
lister tous les chanteurs par ordre de clé primaire, utilisez cette requête:
SELECT * FROM Singers
ORDER BY SingerId;
Spanner garantit l'ordre des résultats uniquement si la clause ORDER BY
est présent dans la requête. En d'autres termes, considérez la requête suivante sans ORDER
BY
:
SELECT * FROM Singers;
Spanner ne garantit pas que les résultats de cette requête seront
ordre de clé primaire. De plus, l'ordre des résultats peut changer à tout moment.
et leur cohérence d'un appel à l'autre n'est pas garantie. Si une requête
comporte une clause ORDER BY
, et Spanner utilise un index qui fournit le
l'ordre requis, Spanner ne trie pas explicitement les données. Par conséquent,
ne vous inquiétez pas de l'impact
de l'inclusion de cette clause sur les performances. Vous pouvez consulter
si une opération de tri explicite est incluse dans l'exécution en examinant
le plan de requête.
Utiliser STARTS_WITH au lieu de LIKE
Comme Spanner n'évalue pas les modèles LIKE
paramétrés tant que
à l'exécution, Spanner doit lire toutes les lignes et les évaluer par rapport
LIKE
pour filtrer les lignes qui ne correspondent pas.
Lorsqu'un modèle LIKE
se présente sous la forme foo%
(par exemple, il commence par une chaîne
chaîne et se termine par un seul caractère générique pour cent) et que la colonne est indexée, utilisez
STARTS_WITH
au lieu de LIKE
. Ce
permet à Spanner d'optimiser plus efficacement l'exécution des requêtes
du client.
Option déconseillée :
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;
<ph type="x-smartling-placeholder"></ph> Recommandation:
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);
Utiliser des horodatages de commit
Si votre application doit interroger des données écrites après un certain temps,
ajouter des colonnes d'horodatage de commit aux tables appropriées. Codes temporels de commit
activer une optimisation Spanner permettant de réduire les E/S
Requêtes dont les clauses WHERE
limitent les résultats aux lignes écrites plus récemment
qu'à un moment précis.
Pour en savoir plus sur cette optimisation, consultez Bases de données de dialecte GoogleSQL ou avec Bases de données de dialecte PostgreSQL