PolarDB:冗長な DISTINCT 操作の排除

PolarDB クラスターのパラメーターを変更する方法は、コンソールとデータベースセッションで異なります。違いは次のとおりです：

• PolarDB コンソール の場合

  • 互換性： MySQL の構成ファイルとの互換性のため、PolarDB コンソールの一部のクラスターパラメーターには loose_ プレフィックスが付いています。

  • 手順： loose_ プレフィックスが付いているパラメーターを見つけて変更します。

• データベースセッション (コマンドラインまたはクライアントを使用) の場合

  • 手順： データベースセッションで SET コマンドを使用してパラメーターを変更する場合、loose_ プレフィックスを削除し、元のパラメーター名を使用します。

シナリオ 1：射影列が定数である場合

オプティマイザーが射影列が定数であることを識別すると、DISTINCT を排除し、LIMIT 1 を追加できます。

1. データの準備： t1 テーブルを作成し、データを挿入します。

   CREATE TABLE testdb.t1 (a INT, b INT);
   INSERT INTO testdb.t1 VALUES (1, 10), (1, 20);

2. 元のクエリの実行：

   EXPLAIN SELECT DISTINCT a + 1 FROM testdb.t1 WHERE a = 1;

3. 最適化の検証： 最適化された実行計画で、warnings の情報を確認します。DISTINCT 操作が排除されています。

   SHOW warnings;
   +-------+------+-------------------------------------------------------------------------------------------------------------------+
   | Level | Code | Message                                                                                                           |
   +-------+------+-------------------------------------------------------------------------------------------------------------------+
   | Note  | 1003 | /* select#1 */ select (`testdb`.`t1`.`a` + 1) AS `a + 1` from `testdb`.`t1` where (`testdb`.`t1`.`a` = 1) limit 1 |
   +-------+------+-------------------------------------------------------------------------------------------------------------------+

シナリオ 2：関数従属性による一意性の推論

列 a が列 b を一意に決定し、かつ b が NULL でない一意キーである場合、オプティマイザーは a も一意であると推論できます。これにより、DISTINCT を排除できます。

1. データの準備： t2 テーブルを作成します。ここで、列 b は列 a から生成され、一意です。

   CREATE TABLE t2 (
     a INT,
     b INT AS (a + 1) UNIQUE
   );
   INSERT INTO t2(a) VALUES (10), (20);

2. 元のクエリの実行：

   EXPLAIN SELECT DISTINCT a FROM t2 WHERE b IS NOT NULL;

3. 最適化の検証： b の一意性が結果における a の一意性を保証するため、DISTINCT は削除されます。warnings の情報を確認します：

   SHOW warnings;
   +-------+------+---------------------------------------------------------------------------------------------------------+
   | Level | Code | Message                                                                                                 |
   +-------+------+---------------------------------------------------------------------------------------------------------+
   | Note  | 1003 | /* select#1 */ select `testdb`.`t2`.`a` AS `a` from `testdb`.`t2` where (`testdb`.`t2`.`b` is not null) |
   +-------+------+---------------------------------------------------------------------------------------------------------+

シナリオ 3：サブクエリの結果が自然に一意である場合

サブクエリ dt が一意キー c を含むため自然に一意である場合、JOIN 操作後も結果の一意性が保たれることがあります。これにより、オプティマイザーは外部の DISTINCT を排除できます。

1. データの準備： t3 テーブルを作成します。ここで、列 c は a と b から生成され、一意です。

   CREATE TABLE t3 (
     a INT NOT NULL,
     b INT NOT NULL,
     c INT AS (a + b) UNIQUE
   );
   INSERT INTO t3(a, b) VALUES (1, 10), (2, 20);

2. 元のクエリの実行：

   EXPLAIN SELECT DISTINCT a, b FROM (SELECT a, b, c FROM t3) dt, (SELECT a AS d FROM t3 limit 1) dt2 WHERE c IS NOT NULL;

3. 最適化の検証： 最適化された実行計画で、warnings の情報を確認します。DISTINCT 操作が排除されています。

   SHOW warnings;                                                                                                 
   +-------+------+----------------------------------------------------------------------------------------------------------------------------------+
   | Level | Code | Message                                                                                                                          |
   +-------+------+----------------------------------------------------------------------------------------------------------------------------------+
   | Note  | 1003 | /* select#1 */ select `testdb`.`t3`.`a` AS `a`,`testdb`.`t3`.`b` AS `b` from `testdb`.`t3` where (`testdb`.`t3`.`c` is not null) |
   +-------+------+----------------------------------------------------------------------------------------------------------------------------------+