Ces paramètres sont disponibles dans system.settings et sont générés automatiquement à partir du code source.
Nombre maximal de lignes dans l’ensemble utilisé pour l’optimisation lazy de FINAL. Au-delà, le système bascule sur le FINAL normal.
Le nombre maximal de lignes distinctes lors de l’utilisation de DISTINCT.
Limite le nombre de lignes dans la structure de données de droite (généralement une table de hachage) utilisée lors de la jointure entre des tables.
Ce paramètre s’applique aux opérations SELECT … JOIN et au moteur de table Join.
Si une requête contient plusieurs jointures, ClickHouse vérifie ce paramètre pour chaque résultat intermédiaire. Lorsque la limite est atteinte, l’action dépend du join_algorithm choisi — consultez ce paramètre pour connaître le comportement de chaque algorithme (spill, re-partition, switch, ou throw/break selon join_overflow_mode).
Valeurs possibles :
- Entier positif.
0 — Nombre de lignes illimité.
Le nombre maximal de lignes pour un jeu de données de la clause IN créé à partir d’une sous-requête.
max_rows_in_set_to_optimize_join
- 0 — Désactive.
- Tout entier positif.
Le nombre maximal de clés uniques reçues lors de l’agrégation. Ce paramètre permet
de limiter la consommation de mémoire lors de l’agrégation.
Si l’agrégation pendant le GROUP BY génère plus de
lignes (clés GROUP BY uniques) que le nombre spécifié, le comportement sera déterminé par
‘group_by_overflow_mode’ qui, par défaut, est throw, mais peut aussi être basculé
vers un mode GROUP BY approximatif.
Le nombre maximal de lignes pouvant être lues depuis une table lors de l’exécution d’une requête.
La restriction est vérifiée pour chaque fragment de données traité, s’applique uniquement à
l’expression de table la plus profonde et, lors d’une lecture depuis un serveur distant, n’est vérifiée que sur
le serveur distant.
Le nombre maximal de lignes pouvant être lues à partir d’une table locale sur un nœud feuille lors de
l’exécution d’une requête distribuée. Bien que les requêtes distribuées puissent envoyer plusieurs sous-requêtes
à chaque shard (feuille), cette limite n’est vérifiée qu’à l’étape de lecture sur les
nœuds feuille et est ignorée à l’étape de fusion des résultats sur le nœud racine.
Par exemple, un cluster se compose de 2 shards, et chaque shard contient une table de
100 lignes. La requête distribuée qui doit lire toutes les données des deux
tables avec le paramètre max_rows_to_read=150 échouera, car il y aura au total
200 lignes. En revanche, une requête avec max_rows_to_read_leaf=150 réussira, puisque les nœuds feuille
liront au maximum 100 lignes.
La restriction est vérifiée pour chaque fragment de données traité.
Ce paramètre est instable avec prefer_localhost_replica=1.
sort_overflow_mode, qui est défini par défaut sur throw.
Taille maximale (en lignes) pouvant être transmise à un serveur distant ou enregistrée dans une
table temporaire lors de l’exécution de la clause GLOBAL IN/JOIN. 
