Statistiques des requêtes

Ce document décrit les statistiques de requêtes que Spanner propose sous forme de tables intégrées. Vous pouvez récupérer des statistiques à partir des tables SPANNER_SYS.QUERY_STATS* à l'aide d'instructions SQL.

Quand utiliser les statistiques de requêtes

Les statistiques de requêtes sont utiles lorsque vous devez examiner des problèmes de performances ou optimiser les requêtes sur votre base de données Spanner. Vous pouvez utiliser les statistiques de requêtes pour examiner une utilisation élevée du processeur, résoudre les problèmes de latence élevée des requêtes ou réduire l'utilisation de la mémoire.

Accéder aux statistiques de requête

Spanner fournit les statistiques de requête dans le schéma SPANNER_SYS. Vous pouvez accéder aux données SPANNER_SYS de différentes manières :

Les méthodes de lecture unique suivantes fournies par Spanner ne sont pas compatibles avec SPANNER_SYS :

  • effectuer une lecture forte à partir d'une ou de plusieurs lignes d'une table ;
  • effectuer une lecture non actualisée à partir d'une ou de plusieurs lignes d'une table ;
  • lire à partir d'une ou de plusieurs lignes d'un index secondaire.

Pour en savoir plus, consultez Méthodes de lecture unique.

Utilisation du processeur regroupée par requête

Les tables ci-dessous suivent les requêtes ayant entraîné le plus haut niveau d'utilisation du processeur pendant une période donnée :

  • SPANNER_SYS.QUERY_STATS_TOP_MINUTE : requêtes pendant des intervalles d'une minute
  • SPANNER_SYS.QUERY_STATS_TOP_10MINUTE : requêtes pendant des intervalles de 10 minutes
  • SPANNER_SYS.QUERY_STATS_TOP_HOUR : requêtes pendant des intervalles d'une heure

Ces tables ont les propriétés suivantes :

  • Chaque table contient des données pour des intervalles de temps qui ne se chevauchent pas et dont la durée est spécifiée par le nom de la table.

  • Les intervalles sont basés sur les heures de l'horloge

    • Les intervalles d'une minute se terminent à la minute.
    • Les intervalles de 10 minutes se terminent toutes les 10 minutes à partir de l'heure pile.
    • Les intervalles d'une heure se terminent à l'heure pile.

    Par exemple, à 11:59:30, les intervalles les plus récents disponibles pour les requêtes SQL sont les suivants :

    • 1 minute : 11:58:00 – 11:58:59
    • 10 minutes : 11:40:00 – 11:49:59
    • 1 heure : 10:00:00 – 10:59:59

  • Spanner regroupe les statistiques par texte de la requête SQL. Si une requête utilise des paramètres de requête ou si Spanner convertit automatiquement les valeurs littérales en paramètres, Spanner regroupe toutes les exécutions de cette requête sur une seule ligne. Si la requête utilise des littéraux de chaîne qui ne peuvent pas être convertis automatiquement en paramètres, Spanner ne regroupe les statistiques que si le texte complet de la requête est identique. Lorsque le texte diffère, chaque requête apparaît sur une ligne distincte. Pour le LMD par lot, Spanner normalise le lot en dédupliquant les instructions identiques consécutives avant de générer l'empreinte.

  • Si un tag de requête est présent, TEXT_FINGERPRINT est le hachage du tag de requête. Sinon, il s'agit du hachage de la valeur TEXT. Pour les LMD partitionnés, TEXT_FINGERPRINT est toujours le hachage de la valeur TEXT.

  • Chaque ligne contient des statistiques pour toutes les exécutions d'une requête SQL particulière pour laquelle Spanner capture des statistiques pendant l'intervalle spécifié.

  • Si Spanner ne parvient pas à stocker toutes les requêtes exécutées pendant l'intervalle, le système donne la priorité aux requêtes ayant l'utilisation du processeur la plus élevée pendant l'intervalle spécifié.

  • Les requêtes suivies incluent celles qui ont abouti, ont échoué ou ont été annulées par l'utilisateur.

  • Un sous-ensemble de statistiques est spécifique aux requêtes qui ont été exécutées mais qui n'ont pas abouti :

    • Nombre d'exécutions et latence moyenne en secondes pour toutes les requêtes qui ont échoué.

    • Nombre d'exécutions des requêtes ayant expiré.

    • Nombre d'exécutions des requêtes annulées par l'utilisateur ou ayant échoué en raison de problèmes de connectivité réseau.

  • Toutes les colonnes des tables peuvent être nulles.

Les statistiques de requête pour les instructions LMD partitionnées précédemment exécutées ont les propriétés suivantes :

  • Chaque instruction LMD partitionnée réussie compte strictement comme une exécution. Une instruction LMD partitionnée qui a échoué, qui est annulée ou qui est en cours d'exécution a un nombre d'exécutions de zéro.

  • ALL_FAILED_EXECUTION_COUNT, ALL_FAILED_AVG_LATENCY_SECONDS, CANCELLED_OR_DISCONNECTED_EXECUTION_COUNT et TIMED_OUT_EXECUTION_COUNT Les statistiques ne sont pas suivies pour les LMD partitionnés.

  • Les statistiques de chaque instruction LMD partitionnée précédemment exécutée peuvent apparaître à différents intervalles. SPANNER_SYS.QUERY_STATS_TOP_10MINUTE et SPANNER_SYS.QUERY_STATS_TOP_HOUR fournissent une vue agrégée des instructions LMD partitionnées qui se terminent respectivement en 10 minutes et en 1 heure. Pour afficher les statistiques des instructions dont la durée est supérieure à une heure, consultez l'exemple de requête.

Schéma de la table

Nom de la colonne Type Description
INTERVAL_END TIMESTAMP Fin de l'intervalle de temps au cours duquel les exécutions de requête retenues ont eu lieu
REQUEST_TAG STRING Tag de requête facultatif pour cette opération de requête. Pour en savoir plus sur l'utilisation des tags, consultez la page Résoudre les problèmes liés aux tags de requête.
QUERY_TYPE STRING Indique si une requête est un PARTITIONED_QUERY ou un QUERY. Une PARTITIONED_QUERY est une requête avec un partitionToken obtenu à partir de l'API PartitionQuery, ou une instruction LMD partitionnée. Toutes les autres requêtes et instructions LMD sont indiquées par le type de requête QUERY.
TEXT STRING Texte de requête SQL, tronqué à environ 64 Ko

Les statistiques de plusieurs requêtes ayant la même chaîne de tag sont regroupées sur une seule ligne avec la valeur REQUEST_TAG correspondant à cette chaîne de tag. Seul le texte de l'une de ces requêtes est affiché dans ce champ, tronqué à environ 64 Ko. Pour le LMD par lot, l'ensemble d'instructions SQL est aplati sur une seule ligne, concaténé à l'aide d'un point-virgule comme délimiteur. Les textes SQL identiques consécutifs sont dédupliqués avant d'être tronqués.
TEXT_TRUNCATED BOOL Valeur indiquant si le texte de la requête a été tronqué
TEXT_FINGERPRINT INT64 Hachage de la valeur REQUEST_TAG, le cas échéant. Dans le cas contraire, hachage de la valeur TEXT. Correspond au champ query_fingerprint du journal d'audit.
EXECUTION_COUNT INT64 Nombre de fois où Spanner a vu la requête au cours de l'intervalle.
AVG_LATENCY_SECONDS FLOAT64 Durée moyenne, en secondes, de chaque exécution de la requête au sein de la base de données, à l'exclusion du temps d'encodage et de transmission de l'ensemble de résultats ainsi que de la surcharge
AVG_ROWS FLOAT64 Nombre moyen de lignes renvoyées par la requête
AVG_BYTES FLOAT64 Nombre moyen d'octets de données renvoyés par la requête, à l'exclusion de la surcharge liée à l'encodage de la transmission
AVG_ROWS_SCANNED FLOAT64 Nombre moyen de lignes analysées par la requête, à l'exclusion des valeurs supprimées
AVG_CPU_SECONDS FLOAT64 Nombre moyen de secondes de temps CPU que Spanner a consacré à toutes les opérations pour exécuter la requête.
ALL_FAILED_EXECUTION_COUNT INT64 Nombre de fois où la requête a échoué au cours de l'intervalle.
ALL_FAILED_AVG_LATENCY_SECONDS FLOAT64 Durée moyenne, en secondes, de chaque exécution de la requête ayant échoué dans la base de données, à l'exclusion du temps d'encodage et de transmission de l'ensemble de résultats ainsi que de la surcharge
CANCELLED_OR_DISCONNECTED_EXECUTION_COUNT INT64 Nombre de fois où la requête a été annulée par l'utilisateur ou a échoué en raison d'une connexion réseau interrompue au cours de l'intervalle.
TIMED_OUT_EXECUTION_COUNT INT64 Nombre de fois où la requête a expiré au cours de l'intervalle.
AVG_BYTES_WRITTEN FLOAT64 Nombre moyen d'octets écrits par l'instruction.
AVG_ROWS_WRITTEN FLOAT64 Nombre moyen de lignes modifiées par l'instruction.
STATEMENT_COUNT INT64 Somme des instructions agrégées dans cette entrée. Pour les requêtes standards et le LMD, cette valeur est égale au nombre d'exécutions. Pour le LMD par lot, Spanner capture le nombre d'instructions dans le lot.
RUN_IN_RW_TRANSACTION_EXECUTION_COUNT INT64 Nombre de fois où la requête a été exécutée dans le cadre d'une transaction en lecture-écriture. Cette colonne vous aide à déterminer si vous pouvez éviter les conflits de verrouillage en déplaçant la requête vers une transaction en lecture seule.
LATENCY_DISTRIBUTION ARRAY<STRUCT>

Histogramme du temps d'exécution de la requête. Les valeurs sont mesurées en secondes.

Le tableau contient un seul élément et est du type suivant :
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>
Pour en savoir plus sur les valeurs, consultez Distribution et Exponentiel.

Pour calculer la latence du centile à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), qui renvoie le n-ième centile estimé. Pour obtenir un exemple associé, consultez Rechercher la latence du 99e centile pour les requêtes.

Pour en savoir plus, consultez Centiles et métriques de distribution.

AVG_MEMORY_PEAK_USAGE_BYTES FLOAT64

Lors de l'exécution d'une requête distribuée, utilisation maximale moyenne de la mémoire (en octets).

Utilisez cette statistique pour identifier les requêtes ou les tailles de données de table susceptibles de rencontrer des limites de mémoire.
AVG_MEMORY_USAGE_PERCENTAGE FLOAT64

Lors de l'exécution d'une requête distribuée, utilisation moyenne de la mémoire requise (en pourcentage de la limite de mémoire autorisée pour cette requête).

Cette statistique ne suit que la mémoire requise pour l'exécution de la requête. Certains opérateurs utilisent une mémoire tampon supplémentaire pour améliorer les performances. La mémoire tampon supplémentaire utilisée est visible dans le plan de requête, mais n'est pas utilisée pour calculer AVG_MEMORY_USAGE_PERCENTAGE, car la mémoire tampon est utilisée pour l'optimisation et n'est pas obligatoire.

Utilisez cette statistique pour identifier les requêtes qui approchent de la limite d'utilisation de la mémoire et qui risquent d'échouer si la taille des données augmente. Pour limiter le risque d'échec de la requête, consultez les bonnes pratiques SQL pour optimiser ces requêtes, ou divisez la requête en plusieurs parties qui lisent moins de données.
AVG_QUERY_PLAN_CREATION_TIME_SECS FLOAT64

Temps CPU moyen (en secondes) consacré à la compilation des requêtes, y compris à la création de l'environnement d'exécution des requêtes.

Si la valeur de cette colonne est élevée, utilisez des requêtes paramétrées.
AVG_FILESYSTEM_DELAY_SECS FLOAT64

Temps moyen passé par la requête à lire à partir du système de fichiers ou à être bloquée sur les entrées/sorties (E/S).

Utilisez cette statistique pour identifier une latence potentiellement élevée causée par les E/S du système de fichiers. Pour résoudre ce problème, ajoutez un index ou une clause STORING (GoogleSQL) ou INCLUDE (PostgreSQL) à un index existant.
AVG_REMOTE_SERVER_CALLS FLOAT64

Nombre moyen d'appels de serveur distant (RPC) effectués par la requête.

Utilisez cette statistique pour déterminer si différentes requêtes qui analysent le même nombre de lignes ont un nombre de RPC très différent. La requête avec une valeur RPC plus élevée peut bénéficier de l'ajout d'un index ou d'une clause STORING (GoogleSQL) ou INCLUDE (PostgreSQL) à un index existant.
AVG_ROWS_SPOOLED FLOAT64

Nombre moyen de lignes écrites sur un disque temporaire (pas en mémoire) par l'instruction de requête.

Utilisez cette statistique pour identifier les requêtes potentiellement à latence élevée qui consomment beaucoup de mémoire et ne peuvent pas être exécutées en mémoire. Pour résoudre ce problème, modifiez l'ordre JOIN ou ajoutez un index qui fournit un SORT requis.
AVG_DISK_IO_COST FLOAT64

Coût moyen de cette requête en termes de charge de disque HDD Spanner.

Utilisez cette valeur pour effectuer des comparaisons relatives des coûts d'E/S du disque dur entre les lectures que vous exécutez dans la base de données. L'interrogation de données sur un espace de stockage HDD entraîne des frais imputés à la capacité de charge du disque HDD de l'instance. Une valeur plus élevée indique que vous utilisez davantage de charge de disque HDD et que votre requête peut être plus lente que si elle était exécutée sur un disque SSD. De plus, si la charge de votre disque dur est saturée, les performances de vos requêtes peuvent être encore plus affectées. Vous pouvez surveiller la capacité totale de charge du disque HDD de l'instance, exprimée en pourcentage. Pour augmenter la capacité de charge des disques HDD, vous pouvez ajouter des unités de traitement ou des nœuds à votre instance. Pour en savoir plus, consultez Modifier la capacité de calcul. Pour améliorer les performances des requêtes, envisagez également de déplacer certaines données vers un SSD.

Pour les charges de travail qui consomment beaucoup d'E/S de disque, nous vous recommandons de stocker les données fréquemment consultées sur un stockage SSD. Les données accessibles à partir du SSD ne consomment pas la capacité de charge du disque HDD. Vous pouvez stocker des tables, des colonnes ou des index secondaires spécifiques sur un stockage SSD, tout en conservant les données rarement consultées sur un stockage HDD. Pour en savoir plus, consultez Présentation du stockage par niveaux.
LATENCY_DISTRIBUTION_JSON_STRING STRING

Histogramme du temps d'exécution de la requête. Les valeurs sont mesurées en secondes.

Représentation sous forme de chaîne compatible JSON de la statistique LATENCY_DISTRIBUTION. La chaîne JSON est un objet JSON ayant la même structure que le STRUCT défini dans la colonne LATENCY_DISTRIBUTION.

Cette colonne est compatible avec les bases de données utilisant le dialecte GoogleSQL et celles utilisant le dialecte PostgreSQL. Cette colonne contient la distribution.

Pour calculer la latence du centile à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), qui renvoie le n-ième centile estimé. Pour obtenir un exemple associé, consultez Rechercher la latence au 99e centile pour les requêtes à l'aide de la colonne LATENCY_DISTRIBUTION_JSON_STRING.

Pour en savoir plus, consultez Centiles et métriques de distribution.

AVG_COLUMNAR_READ_SHARE FLOAT64

Pourcentage moyen d'octets lus sur le stockage en colonnes par rapport au nombre total d'octets lus sur le stockage en lignes et en colonnes, exprimé sous forme de fraction comprise entre 0 et 1.

Utilisez cette statistique pour surveiller l'utilisation du moteur de données en colonnes dans les requêtes. Pour en savoir plus, consultez Surveiller les performances du moteur de données en colonnes.

QUERY_OPTIMIZER_VERSIONS ARRAY<INT64>

Versions de l'optimiseur de requêtes utilisées pour les requêtes au cours de cette période.
STATISTICS_PACKAGE_NAMES ARRAY<STRING>

Noms des packages de statistiques utilisés pour les requêtes dans cette période.
CPU_SECONDS_DISTRIBUTION ARRAY<STRUCT>

Histogramme du temps CPU que Spanner a consacré à toutes les opérations pour exécuter la requête. Les valeurs sont mesurées en secondes.

Le tableau présente la structure suivante :
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

Pour en savoir plus sur les types de valeurs, consultez Distribution et Exponentiel.

Pour calculer les centiles de secondes de processeur à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64).

CPU_SECONDS_DISTRIBUTION_JSON_STRING STRING

Représentation sous forme de chaîne compatible JSON de la statistique CPU_SECONDS_DISTRIBUTION. La chaîne JSON est un objet JSON ayant la même structure que le STRUCT défini dans la colonne CPU_SECONDS_DISTRIBUTION.

Cette colonne est compatible avec les bases de données utilisant le dialecte GoogleSQL et celles utilisant le dialecte PostgreSQL.

Pour calculer les centiles de secondes de processeur à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64).

ROW_SCANNED_DISTRIBUTION ARRAY<STRUCT>

Histogramme du nombre de lignes analysées par la requête, à l'exclusion des valeurs supprimées.

Le tableau présente la structure suivante :
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

Pour en savoir plus sur les types de valeurs, consultez Distribution et Exponentiel.

Pour calculer les centiles des lignes analysées à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64).

ROW_SCANNED_DISTRIBUTION_JSON_STRING STRING

Représentation sous forme de chaîne compatible JSON de la statistique ROW_SCANNED_DISTRIBUTION. La chaîne JSON est un objet JSON ayant la même structure que le STRUCT défini dans la colonne ROW_SCANNED_DISTRIBUTION.

Cette colonne est compatible avec les bases de données utilisant le dialecte GoogleSQL et celles utilisant le dialecte PostgreSQL.

Pour calculer les centiles des lignes analysées à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64).

EXECUTION_COUNT, AVG_LATENCY_SECONDS, LATENCY_DISTRIBUTION et LATENCY_DISTRIBUTION_JSON_STRING pour les requêtes ayant échoué incluent les requêtes qui ont échoué en raison d'une syntaxe incorrecte ou qui ont rencontré une erreur temporaire, mais qui ont réussi lors d'une nouvelle tentative. Ces statistiques ne suivent pas les instructions LMD partitionnées ayant échoué ou ayant été annulées.

Statistiques globales

Il existe également des tables qui suivent les données globales pour toutes les requêtes pour lesquelles Spanner a capturé des statistiques sur une période spécifique :

  • SPANNER_SYS.QUERY_STATS_TOTAL_MINUTE : requêtes émises durant des intervalles d'une minute
  • SPANNER_SYS.QUERY_STATS_TOTAL_10MINUTE : requêtes émises durant des intervalles de 10 minutes
  • SPANNER_SYS.QUERY_STATS_TOTAL_HOUR : requêtes émises durant des intervalles d'une heure

Ces tables ont les propriétés suivantes :

  • Chaque table contient des données pour des intervalles de temps qui ne se chevauchent pas, dont la durée est spécifiée par le nom de la table.

  • Les intervalles sont définis selon l'heure réelle. Les intervalles d'une minute se terminent toutes les minutes, les intervalles de 10 minutes s'achèvent toutes les 10 minutes à partir de l'heure juste, et les intervalles d'une heure prennent fin toutes les heures.

    Par exemple, à 11:59:30, les intervalles les plus récents disponibles pour les requêtes SQL sont les suivants :

    • 1 minute : 11:58:00 – 11:58:59
    • 10 minutes : 11:40:00 – 11:49:59
    • 1 heure : 10:00:00 – 10:59:59

  • Chaque ligne contient les statistiques globales correspondant à l'ensemble des requêtes exécutées sur la base de données au cours de l'intervalle spécifié. Il n'y a par conséquent qu'une seule ligne par intervalle de temps, qui inclut les requêtes terminées, les requêtes ayant échoué et les requêtes annulées par l'utilisateur.

  • Les statistiques capturées dans les tables TOTAL peuvent inclure des requêtes que Spanner n'a pas capturées dans les tables TOP.

  • Certaines colonnes de ces tables sont exposées en tant que métriques dans Cloud Monitoring. Les métriques exposées sont les suivantes :

    • Nombre d'exécutions de requêtes
    • Échecs de requêtes
    • Latences des requêtes
    • Nombre de lignes renvoyées
    • Nombre de lignes analysées
    • Nombre d'octets renvoyés
    • Temps CPU de la requête

    Pour en savoir plus, consultez Métriques Spanner.

Schéma de la table

Nom de la colonne Type Description
INTERVAL_END TIMESTAMP Fin de l'intervalle de temps au cours duquel les exécutions de requête retenues ont eu lieu
EXECUTION_COUNT INT64 Nombre de fois où Spanner a vu la requête pendant l'intervalle de temps.
AVG_LATENCY_SECONDS FLOAT64 Durée moyenne, en secondes, de chaque exécution de la requête au sein de la base de données, à l'exclusion du temps d'encodage et de transmission de l'ensemble de résultats ainsi que de la surcharge
AVG_ROWS FLOAT64 Nombre moyen de lignes renvoyées par la requête
AVG_BYTES FLOAT64 Nombre moyen d'octets de données renvoyés par la requête, à l'exclusion de la surcharge liée à l'encodage de la transmission
AVG_ROWS_SCANNED FLOAT64 Nombre moyen de lignes analysées par la requête, à l'exclusion des valeurs supprimées
AVG_CPU_SECONDS FLOAT64 Nombre moyen de secondes de temps CPU que Spanner a consacré à toutes les opérations pour exécuter la requête.
ALL_FAILED_EXECUTION_COUNT INT64 Nombre de fois où la requête a échoué au cours de l'intervalle.
ALL_FAILED_AVG_LATENCY_SECONDS FLOAT64 Durée moyenne, en secondes, de chaque exécution de la requête ayant échoué dans la base de données, à l'exclusion du temps d'encodage et de transmission de l'ensemble de résultats ainsi que de la surcharge
CANCELLED_OR_DISCONNECTED_EXECUTION_COUNT INT64 Nombre de fois où la requête a été annulée par l'utilisateur ou a échoué en raison d'une connexion réseau interrompue au cours de l'intervalle.
TIMED_OUT_EXECUTION_COUNT INT64 Nombre de fois où la requête a expiré au cours de l'intervalle.
AVG_BYTES_WRITTEN FLOAT64 Nombre moyen d'octets écrits par l'instruction.
AVG_ROWS_WRITTEN FLOAT64 Nombre moyen de lignes modifiées par l'instruction.
RUN_IN_RW_TRANSACTION_EXECUTION_COUNT INT64 Nombre de fois où des requêtes ont été exécutées dans le cadre de transactions en lecture-écriture. Cette colonne vous aide à déterminer si vous pouvez éviter les conflits de verrouillage en déplaçant certaines requêtes vers des transactions en lecture seule.
LATENCY_DISTRIBUTION ARRAY<STRUCT>

Histogramme du temps d'exécution des requêtes. Les valeurs sont mesurées en secondes.

Spécifiez le tableau comme suit :
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>
Pour en savoir plus sur les valeurs, consultez Distribution et Exponentiel.

Pour calculer la latence du centile à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), qui renvoie le n-ième centile estimé. Pour obtenir un exemple associé, consultez Rechercher la latence du 99e centile pour les requêtes.

Pour en savoir plus, consultez Centiles et métriques de distribution.

LATENCY_DISTRIBUTION_JSON_STRING STRING

Histogramme du temps d'exécution de la requête. Les valeurs sont mesurées en secondes.

Représentation sous forme de chaîne compatible JSON de la statistique LATENCY_DISTRIBUTION. La chaîne JSON est un objet JSON ayant la même structure que le STRUCT défini dans la colonne LATENCY_DISTRIBUTION.

Cette colonne est compatible avec les bases de données utilisant le dialecte GoogleSQL et celles utilisant le dialecte PostgreSQL. Cette colonne contient la distribution.

Pour calculer la latence du centile à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), qui renvoie le n-ième centile estimé. Pour obtenir un exemple associé, consultez Rechercher la latence du 99e centile pour les requêtes à l'aide de la colonne LATENCY_DISTRIBUTION_JSON_STRING.

Pour en savoir plus, consultez Centiles et métriques de distribution.

AVG_COLUMNAR_READ_SHARE FLOAT64

Pourcentage moyen d'octets lus sur le stockage en colonnes par rapport au nombre total d'octets lus sur le stockage en lignes et en colonnes, exprimé sous forme de fraction comprise entre 0 et 1.

Utilisez cette statistique pour surveiller l'utilisation du moteur de données en colonnes dans les requêtes. Pour en savoir plus, consultez Surveiller les performances du moteur de données en colonnes.

CPU_SECONDS_DISTRIBUTION ARRAY<STRUCT>

Histogramme du temps CPU que Spanner a consacré à toutes les opérations pour exécuter la requête. Les valeurs sont mesurées en secondes.

Le tableau présente la structure suivante :
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

Pour en savoir plus sur les types de valeurs, consultez Distribution et Exponentiel.

Pour calculer les centiles de secondes de processeur à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64).

CPU_SECONDS_DISTRIBUTION_JSON_STRING STRING

Représentation sous forme de chaîne compatible JSON de la statistique CPU_SECONDS_DISTRIBUTION. La chaîne JSON est un objet JSON ayant la même structure que le STRUCT défini dans la colonne CPU_SECONDS_DISTRIBUTION.

Cette colonne est compatible avec les bases de données utilisant le dialecte GoogleSQL et celles utilisant le dialecte PostgreSQL.

Pour calculer les centiles de secondes de processeur à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64).

ROW_SCANNED_DISTRIBUTION ARRAY<STRUCT>

Histogramme du nombre de lignes analysées par la requête, à l'exclusion des valeurs supprimées.

Le tableau présente la structure suivante :
ARRAY<STRUCT<
  COUNT INT64,
  MEAN FLOAT64,
  SUM_OF_SQUARED_DEVIATION FLOAT64,
  NUM_FINITE_BUCKETS INT64,
  GROWTH_FACTOR FLOAT64,
  SCALE FLOAT64,
  BUCKET_COUNTS ARRAY<INT64>>>

Pour en savoir plus sur les types de valeurs, consultez Distribution et Exponentiel.

Pour calculer les centiles des lignes analysées à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64).

ROW_SCANNED_DISTRIBUTION_JSON_STRING STRING

Représentation sous forme de chaîne compatible JSON de la statistique ROW_SCANNED_DISTRIBUTION. La chaîne JSON est un objet JSON ayant la même structure que le STRUCT défini dans la colonne ROW_SCANNED_DISTRIBUTION.

Cette colonne est compatible avec les bases de données utilisant le dialecte GoogleSQL et celles utilisant le dialecte PostgreSQL.

Pour calculer les centiles des lignes analysées à partir de la distribution, utilisez la fonction SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64).

Conservation des données

Au minimum, Spanner conserve les données de chaque table pendant les périodes suivantes :

  • SPANNER_SYS.QUERY_STATS_TOP_MINUTE et SPANNER_SYS.QUERY_STATS_TOTAL_MINUTE : intervalles couvrant les six heures précédentes

  • SPANNER_SYS.QUERY_STATS_TOP_10MINUTE et SPANNER_SYS.QUERY_STATS_TOTAL_10MINUTE : intervalles couvrant les quatre derniers jours.

  • SPANNER_SYS.QUERY_STATS_TOP_HOUR et SPANNER_SYS.QUERY_STATS_TOTAL_HOUR : intervalles couvrant les 30 jours précédents.

Exemples de requêtes

Cette section présente plusieurs exemples d'instructions SQL permettant d'extraire des statistiques sur les requêtes. Vous pouvez exécuter ces instructions SQL à l'aide des bibliothèques clientes, de Google Cloud CLI ou de la consoleGoogle Cloud .

Lister les statistiques de base pour chaque requête sur une période donnée

La requête suivante renvoie les données brutes correspondant aux principales requêtes exécutées au cours de la minute précédente :

SELECT text,
       request_tag,
       interval_end,
       execution_count,
       avg_latency_seconds,
       avg_rows,
       avg_bytes,
       avg_rows_scanned,
       avg_cpu_seconds
FROM spanner_sys.query_stats_top_minute
ORDER BY interval_end DESC;

Lister les statistiques des instructions LMD partitionnées qui s'exécutent pendant plus d'une heure

La requête suivante renvoie le nombre d'exécutions et le nombre moyen de lignes écrites par les principales requêtes LMD partitionnées au cours des heures précédentes :

SELECT text,
       request_tag,
       interval_end,
       sum(execution_count) as execution_count,
       sum(avg_rows_written*execution_count)/sum(execution_count) as avg_rows_written
FROM spanner_sys.query_stats_top_hour
WHERE starts_with(text, "UPDATE") AND query_type = "PARTITIONED_QUERY"
group by text, request_tag, interval_end
ORDER BY interval_end DESC;

Lister les requêtes dont l'utilisation du processeur est la plus élevée

La requête suivante renvoie les requêtes qui ont entraîné le niveau le plus élevé d'utilisation du processeur au cours de l'heure précédente :

SELECT text,
       request_tag,
       execution_count AS count,
       avg_latency_seconds AS latency,
       avg_cpu_seconds AS cpu,
       execution_count * avg_cpu_seconds AS total_cpu
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_hour)
ORDER BY total_cpu DESC;

Déterminer le nombre total d'exécutions pour une période donnée

La requête suivante renvoie le nombre total de requêtes exécutées au cours du dernier intervalle complet d'une minute :

SELECT interval_end,
       execution_count
FROM spanner_sys.query_stats_total_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_total_minute);

Déterminer la latence moyenne d'une requête

La requête suivante renvoie la latence moyenne d'une requête donnée :

SELECT avg_latency_seconds
FROM spanner_sys.query_stats_top_hour
WHERE text LIKE "SELECT x FROM table WHERE x=@foo;";

Identifier la latence au 99e centile pour les requêtes

La comparaison de la latence moyenne avec la latence du 99e centile permet d'identifier d'éventuelles requêtes aberrantes avec des temps d'exécution élevés.

Les requêtes suivantes renvoient le 99e centile du temps d'exécution des requêtes exécutées au cours des 10 dernières minutes.

Pour les bases de données au dialecte GoogleSQL, vous pouvez utiliser la colonne LATENCY_DISTRIBUTION :

SELECT interval_end, avg_latency_seconds, SPANNER_SYS.DISTRIBUTION_PERCENTILE(latency_distribution[OFFSET(0)], 99.0)
  AS percentile_latency
FROM spanner_sys.query_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_total_10minute)
ORDER BY interval_end;

Pour les bases de données de dialecte PostgreSQL, utilisez plutôt la colonne LATENCY_DISTRIBUTION_JSON_STRING :

SELECT interval_end, avg_latency_seconds, SPANNER_SYS.DISTRIBUTION_PERCENTILE(latency_distribution_json_string, 99.0)
  AS percentile_latency
FROM spanner_sys.query_stats_total_10minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_total_10minute)
ORDER BY interval_end;

Identifier les requêtes qui analysent le plus de données

Vous pouvez utiliser le nombre de lignes analysées par une requête comme mesure de la quantité de données analysées par cette dernière. La requête suivante renvoie le nombre de lignes analysées par les requêtes exécutées au cours de l'heure précédente :

SELECT text,
       execution_count,
       avg_rows_scanned
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_hour)
ORDER BY avg_rows_scanned DESC;

Rechercher les instructions qui ont écrit le plus de données

Vous pouvez utiliser le nombre de lignes écrites (ou d'octets écrits) par le LMD pour mesurer la quantité de données modifiées par la requête. La requête suivante renvoie le nombre de lignes écrites par les instructions LMD exécutées au cours de l'heure précédente :

SELECT text,
       execution_count,
       avg_rows_written
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_hour)
ORDER BY avg_rows_written DESC;

Utilisation totale du processeur pour toutes les requêtes

La requête suivante renvoie le nombre d'heures d'utilisation du CPU au cours de l'heure précédente :

SELECT (avg_cpu_seconds * execution_count / 60 / 60)
  AS total_cpu_hours
FROM spanner_sys.query_stats_total_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_total_hour);

Lister les requêtes qui ont échoué au cours d'une période donnée

La requête suivante renvoie les données brutes, y compris le nombre d'exécutions et la latence moyenne des requêtes ayant échoué pour les requêtes principales de la minute précédente. Ces statistiques ne suivent pas les instructions LMD partitionnées ayant échoué ou ayant été annulées.

SELECT text,
       request_tag,
       interval_end,
       execution_count,
       all_failed_execution_count,
       all_failed_avg_latency_seconds,
       avg_latency_seconds,
       avg_rows,
       avg_bytes,
       avg_rows_scanned,
       avg_cpu_seconds
FROM spanner_sys.query_stats_top_minute
WHERE all_failed_execution_count > 0
ORDER BY interval_end;

Déterminer le nombre total d'erreurs sur une période donnée

La requête suivante renvoie le nombre total de requêtes dont l'exécution a échoué au cours de l'intervalle d'une minute le plus récent. Ces statistiques ne suivent pas les instructions LMD partitionnées ayant échoué ou ayant été annulées.

SELECT interval_end,
       all_failed_execution_count
FROM spanner_sys.query_stats_total_minute
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_minute)
ORDER BY interval_end;

Lister les requêtes qui expirent le plus souvent

La requête suivante renvoie les requêtes qui ont présenté le délai avant expiration le plus élevé au cours de l'heure précédente.

SELECT text,
       execution_count AS count,
       timed_out_execution_count AS timeout_count,
       avg_latency_seconds AS latency,
       avg_cpu_seconds AS cpu,
       execution_count * avg_cpu_seconds AS total_cpu
FROM spanner_sys.query_stats_top_hour
WHERE interval_end =
  (SELECT MAX(interval_end)
   FROM spanner_sys.query_stats_top_hour)
ORDER BY timed_out_execution_count DESC;

Trouver la latence moyenne des exécutions réussies et échouées d'une requête

La requête suivante renvoie la latence moyenne combinée, la latence moyenne pour des exécutions réussies et la latence moyenne pour les exécutions ayant échoué pour une requête spécifique. Ces statistiques ne suivent pas les instructions LMD partitionnées ayant échoué ou ayant été annulées.

SELECT avg_latency_seconds AS combined_avg_latency,
       all_failed_avg_latency_seconds AS failed_execution_latency,
       ( avg_latency_seconds * execution_count -
         all_failed_avg_latency_seconds * all_failed_execution_count
       ) / (
       execution_count - all_failed_execution_count ) AS success_execution_latency
FROM   spanner_sys.query_stats_top_hour
WHERE  text LIKE "select x from table where x=@foo;";

Résoudre les problèmes d'utilisation élevée du processeur ou de latence élevée des requêtes à l'aide des statistiques de requêtes

Les statistiques de requêtes sont utiles lorsque vous devez examiner une utilisation élevée du processeur sur votre base de données Spanner ou lorsque vous essayez simplement de comprendre les formes de requêtes gourmandes en ressources processeur sur votre base de données. L'inspection des requêtes qui utilisent d'importantes ressources de base de données permet aux utilisateurs de Spanner de réduire les coûts opérationnels et d'améliorer les latences générales du système.

Vous pouvez utiliser du code SQL ou le tableau de bord Insights sur les requêtes pour examiner les requêtes problématiques dans votre base de données. Les rubriques suivantes expliquent comment examiner ces requêtes à l'aide du code SQL.

Bien que l'exemple suivant se concentre sur l'utilisation du processeur, vous pouvez suivre des étapes similaires pour résoudre les problèmes de latence élevée des requêtes et identifier les requêtes présentant les latences les plus élevées. Sélectionnez des intervalles de temps et des requêtes par latence plutôt que par utilisation du processeur.

Sélectionnez une période à examiner

Commencez votre évaluation en recherchant une heure à laquelle votre application a commencé à subir une utilisation élevée du processeur. Par exemple, si le problème a commencé à se produire vers le 24 juillet 2020 à 17h00 UTC.

Recueillir des statistiques sur les requêtes pour la période sélectionnée

Après avoir sélectionné une période pour commencer votre investigation, examinez les statistiques collectées dans la table QUERY_STATS_TOTAL_10MINUTE à ce moment-là. Les résultats de cette requête peuvent indiquer l'évolution du processeur et d'autres statistiques de requête au cours de cette période.

La requête suivante renvoie les statistiques de requête agrégées de 16h30 à 17h30 UTC inclus. La requête utilise ROUND pour limiter le nombre de décimales à des fins d'affichage.

SELECT interval_end,
       execution_count AS count,
       ROUND(avg_latency_seconds,2) AS latency,
       ROUND(avg_rows,2) AS rows_returned,
       ROUND(avg_bytes,2) AS bytes,
       ROUND(avg_rows_scanned,2) AS rows_scanned,
       ROUND(avg_cpu_seconds,3) AS avg_cpu
FROM spanner_sys.query_stats_total_10minute
WHERE
  interval_end >= "2020-07-24T16:30:00Z"
  AND interval_end <= "2020-07-24T17:30:00Z"
ORDER BY interval_end;

L'exécution de la requête a produit les résultats suivants.

interval_end nombre latence rows_returned bytes rows_scanned avg_cpu
2020-07-24T16:30:00Z 6 0,06 5,00 536,00 16,67 0,035
2020-07-24T16:40:00Z 55 0,02 0.22 25,29 0.22 0,004
2020-07-24T16:50:00Z 102 0,02 0,30 33,35 0,30 0,004
2020-07-24T17:00:00Z 154 1.06 4.42 486.33 7792208.12 4.633
2020-07-24T17:10:00Z 94 0,02 1,68 106,84 1,68 0,006
2020-07-24T17:20:00Z 110 0,02 0,38 34,60 0,38 0,005
2020-07-24T17:30:00Z 47 0,02 0.23 24,96 0.23 0,004

Dans le tableau précédent, notez que le temps CPU moyen, la colonne avg_cpu du tableau des résultats, est le plus élevé dans les intervalles mis en surbrillance se terminant à 17h00. Notez également que le nombre moyen de lignes analysées est beaucoup plus élevé. Cela indique que des requêtes plus coûteuses ont été exécutées entre 16h50 et 17h00. Choisissez cet intervalle pour approfondir l'analyse à l'étape suivante.

Identifier les requêtes qui entraînent une utilisation élevée du processeur

Une fois l'intervalle de temps à examiner sélectionné, interrogez la table QUERY_STATS_TOP_10MINUTE. Les résultats de cette requête peuvent aider à identifier les requêtes qui entraînent une utilisation élevée du processeur.

SELECT text_fingerprint AS fingerprint,
       execution_count AS count,
       ROUND(avg_latency_seconds,2) AS latency,
       ROUND(avg_cpu_seconds,3) AS cpu,
       ROUND(execution_count * avg_cpu_seconds,3) AS total_cpu
FROM spanner_sys.query_stats_top_10minute
WHERE
  interval_end = "2020-07-24T17:00:00Z"
ORDER BY total_cpu DESC;

L'exécution de cette requête donne les résultats suivants.

fingerprint nombre latence processeur total_cpu
5505124206529314852 30 3.88 17.635 529.039
1697951036096498470 10 4.49 18.388 183.882
2295109096748351518 1 0,33 0,048 0,048
11618299167612903606 1 0,25 0,021 0,021
10302798842433860499 1 0,04 0.006 0.006
123771704548746223 1 0,04 0.006 0.006
4216063638051261350 1 0,04 0.006 0.006
3654744714919476398 1 0,04 0.006 0.006
2999453161628434990 1 0,04 0.006 0.006
823179738756093706 1 0,02 0,005 0.0056

Les deux premières requêtes, mises en évidence dans le tableau des résultats, sont des anomalies en termes de CPU et de latence moyennes, ainsi que de nombre d'exécutions et de CPU totale. Examinez la première requête listée dans ces résultats.

Comparer les exécutions de requêtes au fil du temps

Après avoir affiné l'investigation, vérifiez la table QUERY_STATS_TOP_MINUTE. En comparant les exécutions au fil du temps pour une requête particulière, vous pouvez rechercher des corrélations entre le nombre de lignes ou d'octets renvoyés, ou le nombre de lignes analysées et l'utilisation élevée du processeur ou la latence. Un écart peut indiquer une non-uniformité des données. Un nombre constamment élevé de lignes analysées peut indiquer l'absence d'index appropriés ou un ordre de jointure sous-optimal.

Examinez la requête présentant l'utilisation moyenne du processeur et la latence les plus élevées en exécutant l'instruction suivante, qui filtre sur l'empreinte textuelle de cette requête.

SELECT interval_end,
       ROUND(avg_latency_seconds,2) AS latency,
       avg_rows AS rows_returned,
       avg_bytes AS bytes_returned,
       avg_rows_scanned AS rows_scanned,
       ROUND(avg_cpu_seconds,3) AS cpu,
FROM spanner_sys.query_stats_top_minute
WHERE text_fingerprint = 5505124206529314852
ORDER BY interval_end DESC;

L'exécution de cette requête renvoie les résultats suivants.

interval_end latence rows_returned bytes_returned rows_scanned processeur
2020-07-24T17:00:00Z 4.55 21 2365 30000000 19,255
2020-07-24T16:00:00Z 3,62 21 2365 30000000 17,255
2020-07-24T15:00:00Z 4,37 21 2365 30000000 18,350
2020-07-24T14:00:00Z 4,02 21 2365 30000000 17,748
2020-07-24T13:00:00Z 3.12 21 2365 30000000 16,380
2020-07-24T12:00:00Z 3,45 21 2365 30000000 15,476
2020-07-24T11:00:00Z 4,94 21 2365 30000000 22,611
2020-07-24T10:00:00Z 6,48 21 2365 30000000 21,265
2020-07-24T09:00:00Z 0.23 21 2365 5 0,040
2020-07-24T08:00:00Z 0,04 21 2365 5 0,021
2020-07-24T07:00:00Z 0.09 21 2365 5 0,030

En examinant les résultats précédents, vous remarquerez que le nombre de lignes analysées, le processeur utilisé et la latence ont tous changé de manière significative vers 9h00. Pour comprendre pourquoi ces chiffres ont augmenté de manière si spectaculaire, examinez le texte de la requête et vérifiez si des modifications du schéma ont pu avoir un impact sur la requête.

Utilisez la requête suivante pour récupérer le texte de la requête que vous examinez.

SELECT text,
       text_truncated
FROM spanner_sys.query_stats_top_hour
WHERE text_fingerprint = 5505124206529314852
LIMIT 1;

Cela renvoie le résultat suivant.

text text_truncated
sélectionnez * dans les ordres où o_custkey = 36901; faux

En examinant le texte de la requête renvoyée, vous remarquerez que la requête filtre sur un champ appelé o_custkey. Il s'agit d'une colonne non-clé de la table orders. Il s'avère qu'un index existait sur cette colonne, mais qu'il a été supprimé vers 9h. Cela explique la modification du coût de cette requête. Vous pouvez rajouter l'index ou, si la requête est exécutée peu fréquemment, décider de ne pas avoir d'index et d'accepter le coût de lecture plus élevé.

Jusqu'à présent, l'investigation s'est concentrée sur les requêtes qui ont abouti et a identifié une raison pour laquelle les performances de la base de données se sont dégradées. À l'étape suivante, concentrez-vous sur les requêtes ayant échoué ou annulées, et examinez ces données pour obtenir plus d'informations.

Examiner les requêtes ayant échoué

Les requêtes qui n'aboutissent pas consomment tout de même des ressources avant d'expirer, d'être annulées ou d'échouer d'une autre manière. Spanner suit le nombre d'exécutions et les ressources consommées par les requêtes ayant échoué, ainsi que celles ayant réussi. Ces statistiques ne suivent pas les instructions LMD partitionnées ayant échoué ou ayant été annulées.

Pour vérifier si les requêtes ayant échoué contribuent de manière significative à l'utilisation du système, commencez par vérifier le nombre de requêtes ayant échoué au cours de l'intervalle de temps qui vous intéresse.

SELECT interval_end,
       all_failed_execution_count AS failed_count,
       all_failed_avg_latency_seconds AS latency
FROM spanner_sys.query_stats_total_minute
WHERE
  interval_end >= "2020-07-24T16:50:00Z"
  AND interval_end <= "2020-07-24T17:00:00Z"
ORDER BY interval_end;
interval_end failed_count latence
2020-07-24T16:52:00Z 1 15,211391
2020-07-24T16:53:00Z 3 58,312232

Pour approfondir vos recherches, recherchez les requêtes les plus susceptibles d'échouer à l'aide de la requête suivante.

SELECT interval_end,
       text_fingerprint,
       execution_count,
       avg_latency_seconds AS avg_latency,
       all_failed_execution_count AS failed_count,
       all_failed_avg_latency_seconds AS failed_latency,
       cancelled_or_disconnected_execution_count AS cancel_count,
       timed_out_execution_count AS to_count
FROM spanner_sys.query_stats_top_minute
WHERE all_failed_execution_count > 0
ORDER BY interval_end;
interval_end text_fingerprint execution_count failed_count cancel_count to_count
2020-07-24T16:52:00Z 5505124206529314852 3 1 1 0
2020-07-24T16:53:00Z 1697951036096498470 2 1 1 0
2020-07-24T16:53:00Z 5505124206529314852 5 2 1 1

Comme le montre le tableau précédent, la requête avec l'empreinte 5505124206529314852 a échoué plusieurs fois à différents intervalles de temps. Compte tenu d'un tel schéma d'échecs, il est intéressant de comparer la latence des exécutions réussies et infructueuses.

SELECT interval_end,
       avg_latency_seconds AS combined_avg_latency,
       all_failed_avg_latency_seconds AS failed_execution_latency,
       ( avg_latency_seconds * execution_count -
         all_failed_avg_latency_seconds * all_failed_execution_count
       ) / (
       execution_count - all_failed_execution_count ) AS success_execution_latency
FROM   spanner_sys.query_stats_top_hour
WHERE  text_fingerprint = 5505124206529314852;
interval_end combined_avg_latency failed_execution_latency success_execution_latency
2020-07-24T17:00:00Z 3,880420 13,830709 2,774832

Appliquer les bonnes pratiques

Après avoir identifié une requête candidate à l'optimisation, examinez le profil de la requête et essayez de l'optimiser en suivant les bonnes pratiques SQL.

Étapes suivantes