Résumé:

Explique comment optimiserexistsDejoinTraitement de l'optimiseur de requête

Fonctions de base:

TwoDimensionalJoiner::ChooseJoinAlgorithm

JoinAlgType TwoDimensionalJoiner::ChooseJoinAlgorithm([[maybe_unused]] MultiIndex &mind, Condition &cond) {
  JoinAlgType join_alg = JoinAlgType::JTYPE_GENERAL;

  if (cond[0].IsType_JoinSimple() && cond[0].op == common::Operator::O_EQ) {
    if ((cond.Size() == 1) && !stonedb_sysvar_force_hashjoin)
      join_alg = JoinAlgType::JTYPE_MAP;  // available types checked inside
    else
      join_alg = JoinAlgType::JTYPE_HASH;
  } else {
    if (cond[0].IsType_JoinSimple() &&
        (cond[0].op == common::Operator::O_MORE_EQ || cond[0].op == common::Operator::O_MORE ||
         cond[0].op == common::Operator::O_LESS_EQ || cond[0].op == common::Operator::O_LESS))
      join_alg = JoinAlgType::JTYPE_SORT;
  }
  return join_alg;
}

Sélectionnerjoin Analyse des problèmes d'optimisation :

1. Juge seulement join simpleScénario,Non jugéexistsClause
2. cond[0].IsType_JoinSimple() Si on entre elseBranches, C'est l'équivalent d'être exécuté deux fois

ChooseJoinAlgorithmOptimisation des fonctions:

1. AdhésionexistsJugement, Par IsType_JoinSimple Et == common::Operator::O_EQ Traitement conditionnel
2. Optimiser la structure du Code, Nettoyer les redondants cond[0].IsType_JoinSimple()Mise en œuvre
3. Aucune autre logique n'est modifiée

JoinAlgType TwoDimensionalJoiner::ChooseJoinAlgorithm([[maybe_unused]] MultiIndex &mind, Condition &cond) {
  JoinAlgType join_alg = JoinAlgType::JTYPE_GENERAL;

  do {
    if (cond[0].IsExists()) {
      break;
    }

    if (!cond[0].IsType_JoinSimple()) {
      return join_alg;
    }

    if (cond[0].op == common::Operator::O_EQ) {
      break;
    }

    if (cond[0].op == common::Operator::O_MORE_EQ || cond[0].op == common::Operator::O_MORE ||
             cond[0].op == common::Operator::O_LESS_EQ || cond[0].op == common::Operator::O_LESS) {
      join_alg = JoinAlgType::JTYPE_SORT;
      return join_alg;
    }
  } while (0);

  if ((cond.Size() == 1) && !stonedb_sysvar_force_hashjoin)
      join_alg = JoinAlgType::JTYPE_MAP;  // available types checked inside
  else
      join_alg = JoinAlgType::JTYPE_HASH;

  return join_alg;
}

Après optimisation du CodeexistsAnalyse de scénarios:

1. Si la force n'est pas activée hash joinRequête, Etcond.Size() == 1, Oui.JTYPE_MAPRequête
2. Ouverture forcée requise hash joinPour entrerhash joinRequête, Le test actuel n'ouvre pas la force hash join. ParJTYPE_MAPEffectuer des tests

Optimiser la marche JTYPE_MAPTest de requête:

MAP Les sous - requêtes prennent du temps ：

mysql> select
    ->                             o_orderpriority,
    ->                             count(*) as order_count
    ->                         from
    ->                             orders
    ->                         where
    ->                             o_orderdate >= date '1993-07-01'
    ->                             and o_orderdate < date '1993-07-01' + interval '3' month
    ->                             and exists (
    ->                                 select
    ->                                     *
    ->                                 from
    ->                                     lineitem
    ->                                 where
    ->                                     l_orderkey = o_orderkey
    ->                                     and l_commitdate < l_receiptdate
    ->                             )
    ->                         group by
    ->                             o_orderpriority
    ->                         order by
    ->                             o_orderpriority ;
+-----------------+-------------+
| o_orderpriority | order_count |
+-----------------+-------------+
| 1-URGENT        |      114839 |
| 2-HIGH          |      114276 |
| 3-MEDIUM        |      114716 |
| 4-NOT SPECIFIED |      114913 |
| 5-LOW           |      114927 |
+-----------------+-------------+
5 rows in set (1.46 sec)

MAP Les sous - requêtes prennent du temps par rapport aux sous - requêtes précédentes :

JTYPE_MAP Diagramme logique de flamme

Forcez - vous.JTYPE_HASHTest de requête:

Force ouvertehash joinOptimisation, Comparez le même scénario avec mapDifférences de requête

HASH Les sous - requêtes prennent du temps :

mysql> select
    ->                             o_orderpriority,
    ->                             count(*) as order_count
    ->                         from
    ->                             orders
    ->                         where
    ->                             o_orderdate >= date '1993-07-01'
    ->                             and o_orderdate < date '1993-07-01' + interval '3' month
    ->                             and exists (
    ->                                 select
    ->                                     *
    ->                                 from
    ->                                     lineitem
    ->                                 where
    ->                                     l_orderkey = o_orderkey
    ->                                     and l_commitdate < l_receiptdate
    ->                             )
    ->                         group by
    ->                             o_orderpriority
    ->                         order by
    ->                             o_orderpriority ;
+-----------------+-------------+
| o_orderpriority | order_count |
+-----------------+-------------+
| 1-URGENT        |      114839 |
| 2-HIGH          |      114276 |
| 3-MEDIUM        |      114716 |
| 4-NOT SPECIFIED |      114913 |
| 5-LOW           |      114927 |
+-----------------+-------------+
5 rows in set (1.36 sec)

HASH Sous - requête par rapport à la Sous - requête précédente :

HASH Diagramme de flamme pour la Sous - Requête :