optimize_and_compare_chain
<, <=, >, >=, = ainsi que leurs combinaisons. Par exemple, (a < b) AND (b < c) AND (c < 5) deviendrait (a < b) AND (b < c) AND (c < 5) AND indexHint(b < 5) AND indexHint(a < 5). Les comparaisons dérivées sont encapsulées dans indexHint : elles participent à l’analyse des index (clé primaire, clé de partition, index de saut) et réduisent l’ensemble de données lu, mais n’ont aucun coût par ligne et n’affectent pas PREWHERE. Une comparaison dérivée via des expressions de tables différentes reste exécutable ((t1.a < t2.b) AND (t2.b < 5) dérive la condition simple t1.a < 5) : c’est la seule condition pouvant être poussée sous la jointure, où elle filtre une entrée de jointure que la chaîne d’origine ne peut pas atteindre. Les comparaisons dérivées qui contredisent une condition existante sont également ajoutées comme conditions simples, de sorte que le AND se réduit à false.
optimize_and_compare_chain_max_hash_work
optimize_and_compare_chain pendant l’analyse de requête, mesuré en nombre de nœuds d’arbre de requête hachés par getTreeHash (le coût dominant de cette optimisation). Lorsqu’une requête a haché plus de ce nombre de nœuds pendant l’application de l’optimisation, celle-ci cesse d’être appliquée pour le reste de la requête. Cela borne le temps d’analyse des requêtes comportant de très nombreuses chaînes AND de comparaisons ou des chaînes très longues, pour lesquelles l’optimisation pourrait sinon monopoliser l’analyse sans rien simplifier. Cet arrêt anticipé est toujours sûr : il se contente de renoncer à une optimisation et ne modifie jamais les résultats. Définissez 0 pour désactiver le budget (illimité).