> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-trino-dialect.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Identifier les requêtes coûteuses en mémoire dans ClickHouse

> Découvrez comment utiliser la table `system.query_log` pour repérer les requêtes les plus gourmandes en mémoire dans ClickHouse, avec des exemples pour des configurations en cluster et autonomes.

<div id="using-the-systemquery-log-table">
  ## Utilisation de la table `system.query_log`
</div>

La requête suivante, très utile, montre lesquelles de vos requêtes exécutées ont consommé le plus de mémoire.

Quelques remarques à propos de cette requête :

* les résultats sont calculés sur les dernières 24 heures (`now() - toIntervalDay(1))`), mais vous pouvez facilement modifier l'intervalle de temps
* elle suppose que vous disposez d'un cluster nommé `default`, qui est le nom de votre cluster dans [ClickHouse Cloud](https://console.clickhouse.cloud). Remplacez `default` par le nom de votre cluster
* si vous n'avez pas de cluster, consultez la requête indiquée à la fin de cet article

```sql theme={null}
SELECT
    count() as nb_query,
    user,
    query,
    sum(memory_usage) AS memory,
    normalized_query_hash
FROM
    clusterAllReplicas(default, system.query_log)
WHERE
    (event_time >= (now() - toIntervalDay(1)))
    AND is_initial_query = 1
    AND query_kind = 'Select'
    AND type = 'QueryFinish'
    and user != 'monitoring-internal'
GROUP BY
    normalized_query_hash,
    query,
    user
ORDER BY
    memory DESC;
```

La réponse ressemble à ceci :

```response theme={null}
┌─nb_query─┬─user────┬─query─────────────────────────────────────────────────────────┬───memory─┬─normalized_query_hash─┐
│       11 │ default │ select version()                                              │ 46178924 │   7202516440347714159 │
│        2 │ default │ SELECT * FROM "system"."table_functions" LIMIT 31 OFFSET 0    │  8391544 │  12830067173062987695 │
└──────────┴─────────┴───────────────────────────────────────────────────────────────┴──────────┴───────────────────────┘
```

<Note>
  Si vous n’avez pas de table `system.query_log`, c’est probablement que la journalisation des requêtes n’est pas activée. Consultez les détails du paramètre [`query_log`](/fr/reference/settings/server-settings/settings/query#query_log) pour savoir comment l’activer.
</Note>

<Note>
  **`query_log` contient plus que les requêtes que vous avez soumises**

  Une même requête soumise peut apparaître sur plusieurs lignes : la requête initiale (`is_initial_query = 1`) ainsi que des étapes dérivées ou internes (`is_initial_query = 0`), comme des requêtes secondaires pour une exécution distribuée ou des requêtes internes utilisées pour évaluer des vues. Ces lignes internes ont leurs propres valeurs `query_id` — attribuées par ClickHouse et incluant parfois un libellé tel que `queryView...` — ne partez donc pas du principe que chaque `query_id` correspond à ce que votre client a signalé. Pour attribuer l’utilisation à la requête telle que vous l’avez exécutée, filtrez sur `is_initial_query = 1` ou faites correspondre `query_id = initial_query_id`. Consultez [Comment identifier les requêtes les plus coûteuses](/fr/resources/support-center/knowledge-base/performance-optimization/find-expensive-queries#initial_query_id-vs-query_id) et la [référence `query_log`](/fr/reference/system-tables/query_log) pour plus de détails.
</Note>

Si vous n’avez pas de cluster, vous pouvez interroger directement votre unique table `system.query_log` :

```sql theme={null}
SELECT
    count() as nb_query,
    user,
    query,
    sum(memory_usage) AS memory,
    normalized_query_hash
FROM
    system.query_log
WHERE
    (event_time >= (now() - toIntervalDay(1)))
    AND is_initial_query = 1
    AND query_kind = 'Select'
    AND type = 'QueryFinish'
    and user != 'monitoring-internal'
GROUP BY
    normalized_query_hash,
    query,
    user
ORDER BY
    memory DESC;
```