Mac De Oracle: MySQL

DROP SHADOW CTRL

TEXT DROP SHADOW OFF

GaragebandとiMovieで

検索

検索用語を入力

Web Blog内

検索フォームを送信

プロフィール

Twitter

Tweets by @discus_hamburg

2024年10月
日	月	火	水	木	金	土
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

最近のトラックバック

[memo]メモを取りつつ楽しめるようなスタイル (wmo6hash::blog)
ダーリンはGoogleで軽食なり。 (今日のゴハン)
�� プログラムは読む時間の方が長い - 遥か彼方の彼方から (�� プログラムは読む時間の方が長い - 遥か彼方の彼方から)
今流行のケブンリッジ関数・・・しってました！？ (あにずむ)
poken (drmarのメモ)
Photo exhibition "Natural Faces of AIDS Orphans"　写真展「エイズ孤児の素顔」@JICA地球ひろば　広尾 (メガ放談)
創る心とおもてなし―第1回 Webエンジニア料理対決に参加する (Kwappa開発室)
創る心とおもてなし～第一回webエンジニア料理対決に参加した (Mac De Oracle)
徹底比較!! PostgreSQL vs MySQLパート2 with 勝手に vs Firebird (14) (キムラデービーブログ)
Oracle de XMLDB #18 (discus)

Oracle

OTN US

Apple

その他

ブログ de ノベルティ
ノベルティグッズをただ、ただ、記録していくブログ。Mac De Oracleでは出来ないネタなので、別ブログを立てた次第。

Googleの広告

RSS

RSSを表示する

当サイトについて

プライバシーポリシー

■プライバシーポリシー

■個人情報の利用目的

　当ブログでは、メールでのお問い合わせ、ブログへのコメントの際、名前（ハンドルネーム）等の個人情報をご登録いただく場合がございます。これらの個人情報は質問に対する回答などでご連絡する場合や、スパムコメント抑止のために利用させていただくものであり、個人情報をご提供いただく際の目的以外では利用いたしません。

■個人情報の第三者への開示

　当サイトでは、個人情報は適切に管理し、以下に該当する場合を除いて第三者に開示することはありません。

本人のご了解がある場合
法令等への協力のため、開示が必要となる場合

個人情報の開示、訂正、追加、削除、利用停止については、ご本人からの個人データの開示、訂正、追加、削除、利用停止のご希望の場合には、ご本人であることを確認させていただいた上で速やかに対応させていただきます。

■アクセス解析ツールについて

　当サイトでは、Googleによるアクセス解析ツール「Googleアナリティクス」を利用しています。このGoogleアナリティクスはトラフィックデータの収集のためにCookieを使用しています。このトラフィックデータは匿名で収集されており、個人を特定するものではありません。この機能はCookieを無効にすることで収集を拒否することが出来ますので、お使いのブラウザの設定をご確認ください。

目的：アクセス数を把握するため
送信先：Google LCC
Googleは受け取った情報をどのように利用するか：Googleの規約に従います
送信される情報：以下４点(R), ユーザー数、セッションの統計情報、おおよその位置情報、ブラウザとデバイスの情報

■広告の配信について

当サイトはGoogleとAmazonの広告を配信しています。

Googleについて

Google及びGoogleのパートナー（第三者配信事業者）の提供する広告を設置しております。その広告配信にはCookieを使用し、当サイトやその他のサイトへの過去のアクセス情報に基づいて広告を配信します。

Google が広告 Cookie を使用することにより、当サイトや他のサイトにアクセスした際の情報に基づいて、Google やそのパートナーが適切な広告を表示しています。

お客様はGoogleアカウントの広告設定ページ（https://adssettings.google.com/u/0/authenticated）で、パーソナライズ広告を無効にできます。また aboutads.info のページにアクセスして頂き、パーソナライズ広告掲載に使用される第三者配信事業者のCookieを無効にできます。

その他、Googleの広告におけるCookieの取り扱い詳細については、Googleのポリシーと規約ページ（https://policies.google.com/technologies/ads）をご覧ください。

Amazonについて

AmazonはアソシエイトリンクのURLに含まれるパラメータを通じて利用者が直前に閲覧したアソシエイトサイトに関する情報などを収集し、これをアソシエイトパートナーに対する紹介料の算定、報告及び支払いに使用したり、アソシエイトパートナーによる複数のウェブサイトや商品戦略毎のパフォーマンスの分析に供したりしています。

アソシエイトパートナーの利用目的：閲覧の傾向や履歴の分析のため広告効果の分析のため
外部送信プログラム名：Amazonアソシエイトプログラム
送信先の会社名：アマゾンジャパン合同会社
送信する情報の内容：閲覧した内容についての情報送信先の利用目的：自社の広告宣伝を目的とした広告情報の掲載のため、ウェブサイトやアプリの監視のため

Amazonによる個人に関する情報の取得及び取扱いに関する方針につきましてはAmazon.co.jpプライバシー規約をご覧ください。

■免責事項

　当サイトからリンクやバナーなどによって他のサイトに移動された場合、移動先サイトで提供される情報、サービス等について一切の責任を負いません。当サイトのコンテンツ・情報につきまして、可能な限り正確な情報を掲載するよう努めておりますが、誤情報が入り込んだり、情報が古くなっていることもございます。当サイトに掲載された内容によって生じた損害等の一切の責任を負いかねますのでご了承ください。

■プライバシーポリシーの変更について

　当サイトは、個人情報に関して適用される日本の法令を遵守するとともに、本ポリシーの内容を適宜見直しその改善に努めます。
修正された最新のプライバシーポリシーは常に本ページにて開示されます。

2024年9月 7日 (土)

VirtualBox-7.1.0_BETA2-164697 (2024-09-06T20:27:41Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録　（VM起動せず）

TestBuild Development Snapshotが　7.1.0_BETA2-164697 (2024-09-06T20:27:41Z)　になっていましたが。前回、前々回同様、7.0の初期のころに先祖返りしたような感じで、x86系VMは以下のメッセージとともに起動できず。（起動時間計測が毎回の楽しみになってきたのでw、早く組み込んでもらいたいですね7.1.0 BETAにも :)

oracle@Mac-Studio ~ % ./print_env.sh

*** mac info. ***
ProductName:		macOS
ProductVersion:		14.6.1
BuildVersion:		23G93
 
*** maxOS ver. ***
      Model Name: Mac Studio
      Chip: Apple M1 Ultra
      Total Number of Cores: 20 (16 performance and 4 efficiency)
      Memory: 64 GB
 
*** VirtualBox ver. ***
7.1.0_BETA2r164697

VMが起動するとかしないとか以前の状況、この部分だけみると先祖返りしちゃってるんで、組み込まれるまではしばらくかかりそうですね。
（7.1.0_BETAになった3度目の更新ですが....)

この状況は、以前のリリースで起動していたVMでも、VirtualBox-7.1.0_BETA2-164697 にインポートしたx86系VMでも同様です。

次の更新を楽しみにして、じっと待つ:)

一瞬、秋？みたいな感じの気温だったが、真夏に逆戻りの東京より

ではまた。:)

・MySQL 8.0.32 , PostgreSQL 13.4 and Oracle Database 21c on Oracle Linux 8 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r160702
・ySQL 8.0.32 , PostgreSQL 13.6 and Oracle Database 21c on Oracle Linux 8.5 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r161342
・MySQL 8.0.32 , PostgreSQL 13.6 and Oracle Database 21c on Oracle Linux 8.5 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r161709
・MySQL 8.0.36 , PostgreSQL 13.14, Oracle Database 21c, Oracle Database 23ai on VirtualBox for Apple Silicon Test Build 7.0.97_BETA r162957
・VirtualBox TestBuild for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録 / 7.0.97r162957(2024/4/26) / 7.0.97r163029(2024/5/3)
・VirtualBox TestBuild 7.0.97r163376 (2024-05-28T15:08:56Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録
・VirtualBox TestBuild 7.0.97r163425 (2024-06-05T13:13:46Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録
・VirtualBox TestBuild 7.0.97r163606 (2024-06-21T11:55:16Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録
・VirtualBox TestBuild 7.1.0_BETA1r164292 (2024-08-07T18:27:07Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録
・VirtualBox TestBuild 7.1.0_BETA1r164387 (2024-08-15T17:27:33Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録

投稿日時 2024年9月 7日 (土) 09時42分 Oracle, VirtualBox, MySQL, PostgreSQL, Oracle Database 19c, Oracle Database 21c, Oracle Database 23c Free Developer Release, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年8月21日 (水)

実行計画は, SQL文のレントゲン写真だ！ No.64 / 先生、私のLEFT OUTER JOINが無いんです！！（Join Elimination番外編）

色々な患者さんが来るわけですが、年に一度ぐらい、私のJOINが無いんです！　みたいなこともあります。

ということで、似たアトモスフィアを感じる

患者「先生、私のLEFT OUTER JOINが無いんです！！」
というところから、今回の物語は始まりますw

私「どれどれ」（触診というか問診というかw）　SQL文を診る。。
私「あ！w これは！！！！w 」

私「大丈夫ですよ！、りっぱな、 INNER JOIN です。栄養状態も良さそうですねwwww」
　「念の為、レントゲン（実行計画）も撮っておきましょう」

患者 (キョトン！)

私「ほら〜〜」

（以下、Oracle Databaseです）

SCOTT@orclpdb1> select banner_full from v$version;

BANNER_FULL
----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0

SCOTT@orclpdb1> @where_did_my_left_outer_join_go.sql
  1  SELECT
  2    e.empno
  3  FROM
  4    emp e
  5    LEFT OUTER JOIN dept d
  6    ON
  7      e.deptno = d.deptno
  8  WHERE
  9*   d.dname = 'ACCOUNTING'

     EMPNO
----------
      7782
      7839

解析されました。

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------
Plan hash value: 2904284165

------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |              |     4 |    80 |     3   (0)| 00:00:01 |
|   1 |  NESTED LOOPS                         |              |     4 |    80 |     3   (0)| 00:00:01 |
|   2 |   NESTED LOOPS                        |              |     4 |    80 |     3   (0)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID BATCHED| DEPT         |     1 |    13 |     2   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN                  | IX_DEPT_NAME |     1 |       |     1   (0)| 00:00:01 |
|*  5 |    INDEX RANGE SCAN                   | IX_DEPT      |     4 |       |     0   (0)| 00:00:01 |
|   6 |   TABLE ACCESS BY INDEX ROWID         | EMP          |     4 |    28 |     1   (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - access("D"."DNAME"='ACCOUNTING')
   5 - access("E"."DEPTNO"="D"."DEPTNO")

19行が選択されました。

って、コントはこれぐらいにして、本題。

最近、なんだか、なんでもかんでも LEFT OUTER JOINで書いちゃう病気多くないですかね。。:(

可読性も悪いし、本人は INNER JOINしてる意識があるのやら、ないのやら。 オプティマイザはしっかり反応して内部で書き換えてくれちゃってるので、 LEFT OUTER JOIN　なんて書かれてても、無駄だからそれ！　ということでINNER JOINにしてくれています。
Nested Loopが利用される場合、本当に、OUTER JOINなのであれば、外部表（駆動表）になる表は構文上から簡単に特定できますが、INNER JOINだとHASH JOIN同様に結合順を見極める作業も必要になるので要注意です。
(なお、Hash Joinでは外部表と内部表はオプティマイザヒントで入れ替え可能ですが、MySQLのHash Joinでは現状入れ替えることはできないので注意が必要です / 帰ってきた！標準はあるにはあるが癖の多いSQL #8、Hash Joinさせるにも癖が出る)

治療の難易度を上げてしまうだけで良いこともないので、OUTER/INNER は適切に使い分けてほしいものですよね。

単純な症例を一つ。MySQL/PostgreSQLでも同じ。

環境の準備 Oracle Databaseのemp/dept表を元に、制約は主キー制約、索引は以下のようになっています。（記載は略しますが、MySQL/PostgreSQLともに同様の表と索引を用意してあります）

SCOTT@orclpdb1> break on table_name on index_name skip page
SCOTT@orclpdb1> r
  1  select table_name,index_name,column_name
  2  from user_ind_columns
  3  where table_name in ('EMP','DEPT')
  4* order by table_name,index_name,column_position

TABLE_NAME                     INDEX_NAME                     COLUMN_NAME
------------------------------ ------------------------------ ------------------------------
DEPT                           IX_DEPT_NAME                   DNAME

TABLE_NAME                     INDEX_NAME                     COLUMN_NAME
------------------------------ ------------------------------ ------------------------------
DEPT                           PK_DEPT                        DEPTNO

TABLE_NAME                     INDEX_NAME                     COLUMN_NAME
------------------------------ ------------------------------ ------------------------------
EMP                            IX_DEPT                        DEPTNO

TABLE_NAME                     INDEX_NAME                     COLUMN_NAME
------------------------------ ------------------------------ ------------------------------
EMP                            PK_EMP                         EMPNO

SCOTT@orclpdb1> 
SCOTT@orclpdb1> select * from emp order by empno;

     EMPNO ENAME                          JOB                                MGR HIREDATE        SAL       COMM     DEPTNO
---------- ------------------------------ --------------------------- ---------- -------- ---------- ---------- ----------
      7369 SMITH                          CLERK                             7902 80-12-17        800                    20
      7499 ALLEN                          SALESMAN                          7698 81-02-20       1600        300         30
      7521 WARD                           SALESMAN                          7698 81-02-22       1250        500         30
      7566 JONES                          MANAGER                           7839 81-04-02       2975                    20
      7654 MARTIN                         SALESMAN                          7698 81-09-28       1250       1400         30
      7698 BLAKE                          MANAGER                           7839 81-05-01       2850                    30
      7782 CLARK                          MANAGER                           7839 81-06-09       2450                    10
      7839 KING                           PRESIDENT                              81-11-17       5000                    10
      7844 TURNER                         SALESMAN                          7698 81-09-08       1500          0         30
      7900 JAMES                          CLERK                             7698 81-12-03        950                    30
      7902 FORD                           ANALYST                           7566 81-12-03       3000                    20
      7934 MILLER                         CLERK                             7782 82-01-23       1300

12行が選択されました。

SCOTT@orclpdb1> select * from dept order by deptno;

    DEPTNO DNAME                                      LOC
---------- ------------------------------------------ ---------------------------------------
        10 ACCOUNTING                                 NEW YORK
        20 RESEARCH                                   DALLAS
        30 SALES                                      CHICAGO
        40 OPERATIONS                                 BOSTON

SCOTT@orclpdb1> r
  1  select table_name,constraint_name,constraint_type
  2  from user_constraints
  3  where table_name in ('EMP','DEPT')
  4* order by table_name,constraint_type

TABLE_NAME                     CONSTRAINT_NAME                CON
------------------------------ ------------------------------ ---
DEPT                           PK_DEPT                        P
EMP                            PK_EMP                         P

PostgreSQL データ量が少ない影響だと思いますが、HASH JOINになってますね。とはいえ、LEFT OUTER JOINではなく、Oracle Database同様に、INNER JOINに書き換えられています。
当然ですよね。INNER JOINなんですもの。
pg_hint_planのヒントを使ってNLJにした実行計画でも確認しておきました:)

perftestdb=> select version();
                                                 version                                                 
---------------------------------------------------------------------------------------------------------
 PostgreSQL 16.3 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-22), 64-bit
(1 行)

perftestdb=> \! cat where_did_my_left_outer_join_go.sql
SELECT
  e.empno
FROM
  emp e
  LEFT OUTER JOIN dept d
  ON
    e.deptno = d.deptno
WHERE
  d.dname = 'ACCOUNTING'
;

explain 
SELECT
  e.empno
FROM
  emp e
  LEFT OUTER JOIN dept d
  ON
    e.deptno = d.deptno
WHERE
  d.dname = 'ACCOUNTING'
;

SELECT
  /*+
    Leading(d e)
    NestLoop(d e)
    IndexScan(d ix_dname)
    IndexScan(e ix_deptno)
  */
  e.empno
FROM
  emp e
  LEFT OUTER JOIN dept d
  ON
    e.deptno = d.deptno
WHERE
  d.dname = 'ACCOUNTING'
;

explain 
SELECT
  /*+
    Leading(d e)
    NestLoop(d e)
    IndexScan(d ix_dname)
    IndexScan(e ix_deptno)
  */
  e.empno
FROM
  emp e
  LEFT OUTER JOIN dept d
  ON
    e.deptno = d.deptno
WHERE
  d.dname = 'ACCOUNTING'
;
perftestdb=> \i where_did_my_left_outer_join_go.sql
 empno 
-------
  7782
  7839
(2 行)

                            QUERY PLAN                            
------------------------------------------------------------------
 Hash Join  (cost=1.06..2.27 rows=3 width=5)
   Hash Cond: (e.deptno = d.deptno)
   ->  Seq Scan on emp e  (cost=0.00..1.14 rows=14 width=10)
   ->  Hash  (cost=1.05..1.05 rows=1 width=5)
         ->  Seq Scan on dept d  (cost=0.00..1.05 rows=1 width=5)
               Filter: ((dname)::text = 'ACCOUNTING'::text)
(6 行)

 empno 
-------
  7782
  7839
(2 行)

                                  QUERY PLAN                                  
------------------------------------------------------------------------------
 Nested Loop  (cost=0.27..16.39 rows=3 width=5)
   ->  Index Scan using ix_dname on dept d  (cost=0.13..8.15 rows=1 width=5)
         Index Cond: ((dname)::text = 'ACCOUNTING'::text)
   ->  Index Scan using ix_deptno on emp e  (cost=0.14..8.21 rows=4 width=10)
         Index Cond: (deptno = d.deptno)
(5 行)

perftestdb=>

MySQL MySQLもInner Joinに書き換えてますよね。だって、どこからどうみても、INNER JOINですもの。

mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+
1 row in set (0.00 sec)

mysql> 
mysql> \! cat where_did_my_left_outer_join_go.sql
SELECT
  e.empno
FROM
  emp e
  LEFT OUTER JOIN dept d
  ON
    e.deptno = d.deptno
WHERE
  d.dname = 'ACCOUNTING'
;

explain format=tree
SELECT
  e.empno
FROM
  emp e
  LEFT OUTER JOIN dept d
  ON
    e.deptno = d.deptno
WHERE
  d.dname = 'ACCOUNTING'
;
mysql> \. where_did_my_left_outer_join_go.sql
+-------+
| empno |
+-------+
|  7782 |
|  7839 |
+-------+
2 rows in set (0.08 sec)

+-------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                   |
+-------------------------------------------------------------------------------------------+
| -> Nested loop inner join  (cost=0.95 rows=3.5)
    -> Filter: (d.deptno is not null)  (cost=0.35 rows=1)
        -> Covering index lookup on d using ix_dname (dname='ACCOUNTING')  (cost=0.35 rows=1)
    -> Covering index lookup on e using emp_deptno (deptno=d.deptno)  (cost=0.6 rows=3.5)
 |
+-------------------------------------------------------------------------------------------+
1 row in set (0.07 sec)

では、また。

いつまで、この酷暑が続くのやら。。。。

投稿日時 2024年8月21日 (水) 12時00分 Oracle, チューニング, FAQ, SQL, MySQL, PostgreSQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2024年8月16日 (金)

VirtualBox TestBuild 7.1.0_BETA1r164387 (2024-08-15T17:27:33Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録

VirtualBox 7.1.0_BETA1r164378が8/15に公開されていましたが、今回もGuestVM起動できず、計測不能でした。

ちなみに、VirtualBox Extension PackもVersionが古く(7.0.97.163425なのでかなり古いですね)インストールできないミスマッチの状態となっているので、そのあたりも影響しているのかもしれません。TestBuildsですからね。長ーい目で見守りましょう。　7.1になってから二回目の更新ですし:)

インストールされたVirtualBoxのリリースは、7.1.0_BETA1r164378

ということで、強烈な台風が近づいている東京より。

みなさん、安全を最優先に:)

ではまた。

投稿日時 2024年8月16日 (金) 06時00分 Oracle, Mac, VirtualBox, MySQL, PostgreSQL, Oracle Database 21c, Oracle Database 23c Free Developer Release, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年8月 8日 (木)

VirtualBox TestBuild 7.1.0_BETA1r164292 (2024-08-07T18:27:07Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録

VirtualBox TestBuild 7.1.0_BETA1r164292 (2024-08-07T18:27:07Z) が公開されていました。

7.1になり、アイコンやスプラッシュも変更されたようですが、、、久しぶりに計測できず！　（次回に期待したいと思います！）

以下、M1/M2いずれもGuest VM起動できませんでした！

*** mac info. ***
ProductName:		macOS
ProductVersion:		14.6.1
BuildVersion:		23G93
 
*** maxOS ver. ***
      Model Name: Mac Studio
      Chip: Apple M1 Ultra
      Total Number of Cores: 20 (16 performance and 4 efficiency)
      Memory: 64 GB
 
*** VirtualBox ver. ***
7.1.0_BETA1r164292

*** mac info. ***
      Model Name: MacBook Air
      Chip: Apple M2
      Total Number of Cores: 8 (4 performance and 4 efficiency)
      Memory: 24 GB

*** macOS ver. ***
ProductName:		macOS
ProductVersion:		14.5
BuildVersion:		23F79

*** VirtualBox ver. ***
7.1.0_BETA1r164292

7.1になった影響だろうか。。。
なお、今回は旧リリースのVirtualBox TestBuild 7.0.97r163779 (2024-07-04T18:53:02Z)　をアップデートしただけ（本来それで良いはずだが）なので、VMのインポートし直した場合も同様の結果、No Supported 。どうなってるんだろう。どうなるかまでは未確認です。
（検証後、本エントリーへ追加する予定）

しかし、酷暑と夕方のCloud 9もくもく後のゲリラ豪雨が、夏のニューノーマルになってしまうと夏のイベントは秋にでもしないと無理かもしれないですねー。花笠祭りも影響受けたようですし。
ちなみに、多摩川花火大会は、何年か前のゲリラ豪雨以後、10月開催に切り替えた経緯がありますよね。。

ではまた。

・
・MySQL 8.0.32 , PostgreSQL 13.4 and Oracle Database 21c on Oracle Linux 8 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r160702
・ySQL 8.0.32 , PostgreSQL 13.6 and Oracle Database 21c on Oracle Linux 8.5 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r161342
・MySQL 8.0.32 , PostgreSQL 13.6 and Oracle Database 21c on Oracle Linux 8.5 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r161709
・MySQL 8.0.36 , PostgreSQL 13.14, Oracle Database 21c, Oracle Database 23ai on VirtualBox for Apple Silicon Test Build 7.0.97_BETA r162957
・VirtualBox TestBuild for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録 / 7.0.97r162957(2024/4/26) / 7.0.97r163029(2024/5/3)
・VirtualBox TestBuild 7.0.97r163376 (2024-05-28T15:08:56Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録
・VirtualBox TestBuild 7.0.97r163425 (2024-06-05T13:13:46Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録
・VirtualBox TestBuild 7.0.97r163606 (2024-06-21T11:55:16Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録
・VirtualBox TestBuild 7.0.97r163779 (2024-07-04T18:53:02Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録

投稿日時 2024年8月 8日 (木) 06時45分 Oracle, VirtualBox, MySQL, PostgreSQL, Oracle Database 21c, Oracle Database 23c Free Developer Release, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年7月24日 (水)

実行計画は, SQL文のレントゲン写真だ！ No.63 / Join Elimination （再び）その3

Previously on Mac De Oracle
実行計画は, SQL文のレントゲン写真だ！ No.63 / Join Elimination （再び）その2では、限定的なようですが、PostgreSQL 16では Join Elimination が行われることを確認しました。（全く行わないとわけではないようですね。PostgreSQL。）

今日は、Join Elimination (再び) の最後に、もう一つだけ、めちゃめちゃシンプルな Join Elimination の挙動を追ってみることにします。

前回り作成した、foo/barの2表を少々作り変えて foo2 / bar2 の2表を作成します。
Oracle Database同様の表をMySQL/PostgreSQLにも作成して検証。（今回もデータの有無は影響しないので、データは未登録です）
(なおデータ型は、MySQL/PostgreSQLに合わせて変更しています。e.g. NUMBER->INTEGER, VARCHAR2 -> VARCHAR。データは未登録では統計情報は PostgreSQL/MySQLでも取得します)

COTT@orclpdb1> l
  1  CREATE TABLE foo2 (
  2    id NUMBER
  3   , note VARCHAR2(100)
  4   , PRIMARY KEY (id)
  5* )
SCOTT@orclpdb1> /

表が作成されました。

SCOTT@orclpdb1> l
  1  CREATE TABLE bar2 (
  2    id NUMBER
  3   , sq NUMBER NOT NULL
  4   , memo VARCHAR2(100)
  5   , PRIMARY KEY (id, sq)
  6* )
SCOTT@orclpdb1> /

表が作成されました。

SCOTT@orclpdb1> @gather_tab_stats foo2

PL/SQLプロシージャが正常に完了しました。

SCOTT@orclpdb1> @gather_tab_stats bar2

PL/SQLプロシージャが正常に完了しました。

上記表を作成後、以下のSQL文を実行します。これもOracle Databaseでは Join Elimination される構文にしています。2つ目の例に類似していますが、 foo2.id = bar2.id は、 1 : 0..* の関係にあります。
したがって　foo2.id = bar2.id という結合条件では Join Elimination できませんが、代わりにインラインビュー内で小細工しています。:)
bar2 WHERE 1=0 として、インライビューの結果は、常に0行となり、そもそも結合不要なので結合自体を除外してしまえ！　というシンプルな Join Elimination の確認です。
この手の文、トリッキーでわかりにくいので個人的には好みではありませんが、ERPなどでは結構、見るような気がしますw

SELECT
  foo2.id
 , foo2.note
FROM
  foo2
  LEFT OUTER JOIN
  (
     SELECT * FROM bar2 WHERE 1=0
  ) bar2
  ON
    foo2.id = bar2.id;

Oracle Database (21c) Oracle Databaseの場合、無駄な結合を除外しているのことを確認できますよね。
この挙動を知っているからこそ、動的SQLの代替としてこのような記述をする傾向があることも理解はしていますが、元の文は読みにくくなるし、ヒント文も埋め込みにくいので、素直に動的SQLにしてくれたらいいのに。。と思ったことがなんとかありますw （Oracle DatabaseのオプティマイザーはSQL文を書き換えて最適化することも多く、この手の構文とヒントによるチューニングは相性的に悪いことが多く、チューニング難易度があがることもあり、個人的には嫌いだ！！　というのもあるのですけどもw）

SCOTT@orclpdb1> l
  1  EXPLAIN PLAN FOR
  2  SELECT
  3    foo2.id
  4   , foo2.note
  5  FROM
  6    foo2
  7    LEFT OUTER JOIN
  8    (
  9       SELECT * FROM bar2 WHERE 1=0
 10    ) bar2
 11    ON
 12*     foo2.id = bar2.id
SCOTT@orclpdb1> /

解析されました。

経過: 00:00:00.01
SCOTT@orclpdb1> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------
Plan hash value: 2844017661

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    65 |     3   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| FOO2 |     1 |    65 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------

8行が選択されました。

PostgreSQL (16.3) ちょっと微妙な感じですが、 Join elimination ではないですね。Nested Loop Left Joinが残ってますし。
とはいえ、 bar2にはアクセスしていないことは確認できるので似たような挙動にはなるのかも。。。
興味深いですね。。。

perftestdb=> EXPLAIN verbose
perftestdb-> SELECT
perftestdb->   foo2.id
perftestdb->  , foo2.note
perftestdb-> FROM
perftestdb->   foo2
perftestdb->   LEFT OUTER JOIN
perftestdb->   (
perftestdb(>      SELECT * FROM bar2 WHERE 1=0
perftestdb(>   ) bar2
perftestdb->   ON
perftestdb->     foo2.id = bar2.id;
                            QUERY PLAN 
-------------------------------------------------------------------
 Nested Loop Left Join  (cost=0.00..0.01 rows=1 width=222)
   Output: foo2.id, foo2.note
   Join Filter: (false AND (foo2.id = id))
   ->  Seq Scan on public.foo2  (cost=0.00..0.00 rows=1 width=222)
         Output: foo2.id, foo2.note
   ->  Result  (cost=0.00..0.00 rows=0 width=4)
         Output: id
         One-Time Filter: false
(8 行)

MySQL (8.0.36) MySQLもPostgreSQLと類似しています。Left Hash Joinは残っているので、Join eliminationではないと考えて良いと思います。

mysql> EXPLAIN format=tree
    -> SELECT
    ->   foo2.id
    ->  , foo2.note
    -> FROM
    ->   foo2
    ->   LEFT OUTER JOIN
    ->   (
    ->      SELECT * FROM bar2 WHERE 1=0
    ->   ) bar2
    ->   ON
    ->     foo2.id = bar2.id;
+-----------------------------------------------------------------------------------+
| EXPLAIN                                                                           |
+-----------------------------------------------------------------------------------+
| -> Left hash join (no condition)  (cost=0.25 rows=0)
    -> Table scan on foo2  (cost=0.35 rows=1)
    -> Hash
        -> Zero rows (Impossible filter)  (cost=0..0 rows=0)
 |
+-----------------------------------------------------------------------------------+
1 row in set (0.01 sec)

今回のレントゲン。いや、実行計画の比較。たまたま閃いたので試してみたのですが想像の斜め上をいく面白さでした。

まとめると、

Oracle Database
Join eliminationによる結合の最適化を行う

PostgreSQL (16以前では未確認)

特定のケースでは、Join elimination できるようだ。（全く行っていないわけではない）

MySQL

現時点8.0までは、Join eliminationは実装されていないようだ。

では、また。

Enjoy SQL! and Execution Plan!

実行計画は, SQL文のレントゲン写真だ！ No.63 / Join Elimination （再び）その1で検証に利用した表の作成ログです。
Oracle Databaseのscottユーザで作成したcustomers/orders表をcsv形式でエクスポート後、Oracle Databaseのcustomers/ordersと同じ表をPostgreSQL/MySQLそれぞれで作成、最後にcsvファイルからデータをロードしています。
試してみたい方は参考にしてみてください。

ーーーcustomers/orders表作成ログーーー

Oracle Database サンプルスキーマ OE で scottユーザへ　customers/orders表へのSELECT権限を付与後、scottユーザ側で、customers/orders表をCTAS。その後、csv形式で、それぞれのデータをexportしています。

oeユーザで。

OE@orclpdb1> grant select on customers to scott;

権限付与が成功しました。

OE@orclpdb1> grant select on orders to scott;

権限付与が成功しました。

以降、scottユーザで。

SCOTT@orclpdb1> l
  1  CREATE TABLE customers AS
  2   SELECT
  3     cust.customer_id
  4     , cust.cust_first_name AS first_name
  5     , cust.cust_last_name AS last_name
  6     , cust.address
  7     , cust.phone# AS phone_number
  8   FROM
  9   (
 10     SELECT
 11       c.customer_id
 12       , c.cust_first_name
 13       , c.cust_last_name
 14       , c.cust_address.street_address AS address
 15       , cr.COLUMN_VALUE AS phone#
 16       , ROW_NUMBER()
 17           OVER (
 18             PARTITION BY c.customer_id
 19             ORDER BY c.customer_id
 20       ) AS phone_count
 21     FROM
 22       oe.customers c
 23       , TABLE(c.phone_numbers) cr
 24     ORDER BY
 25       c.customer_id
 26       , phone_count
 27   ) cust
 28   WHERE
 29*    cust.phone_count = 1
SCOTT@orclpdb1> /

表が作成されました。

SCOTT@orclpdb1> alter table customers add constraint pk_customers primary key (customer_id) using index;

表が変更されました。

SCOTT@orclpdb1> create table orders as select * from oe.orders;

表が作成されました。

SCOTT@orclpdb1> desc orders                                  
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ORDER_ID                                           NUMBER(12)
 ORDER_DATE                                NOT NULL TIMESTAMP(6) WITH LOCAL TIME ZONE
 ORDER_MODE                                         VARCHAR2(8)
 CUSTOMER_ID                               NOT NULL NUMBER(6)
 ORDER_STATUS                                       NUMBER(2)
 ORDER_TOTAL                                        NUMBER(8,2)
 SALES_REP_ID                                       NUMBER(6)
 PROMOTION_ID                                       NUMBER(6)

SCOTT@orclpdb1> alter table orders add constraint pk_orders primary key (order_id) using index;

表が変更されました。

SCOTT@orclpdb1> alter table orders add constraint fk_orders_customers foreign key (customer_id) references customers;

表が変更されました。

SCOTT@orclpdb1> desc customers
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 CUSTOMER_ID                                        NUMBER(6)
 FIRST_NAME                                NOT NULL VARCHAR2(20)
 LAST_NAME                                 NOT NULL VARCHAR2(20)
 ADDRESS                                            VARCHAR2(40)
 PHONE_NUMBER                                       VARCHAR2(25)

SCOTT@orclpdb1> create index fk_orders_customers on orders(customer_id);

索引が作成されました。

SCOTT@orclpdb1> l
  1  select
  2    table_name
  3    , index_name
  4    , column_name
  5  from
  6    user_ind_columns
  7  where
  8    table_name in ('CUSTOMERS', 'ORDERS')
  9  order by
 10    table_name
 11    , index_name
 12*   , column_position
SCOTT@orclpdb1> /

TABLE_NAME                     INDEX_NAME                     COLUMN_NAME
------------------------------ ------------------------------ ------------------------------
CUSTOMERS                      PK_CUSTOMERS                   CUSTOMER_ID
ORDERS                         FK_ORDERS_CUSTOMERS            CUSTOMER_ID
ORDERS                         PK_ORDERS                      ORDER_ID

SCOTT@orclpdb1> r
  1  select
  2    table_name
  3    , constraint_name
  4    , constraint_type
  5    , r_owner
  6    , r_constraint_name
  7  from
  8    user_constraints
  9  where
 10    table_name in ('CUSTOMERS','ORDERS')
 11*   and constraint_type in ('P','R')

TABLE_NAME                     CONSTRAINT_NAME      CON R_OWNER              R_CONSTRAINT_NAME
------------------------------ -------------------- --- -------------------- --------------------
ORDERS                         FK_ORDERS_CUSTOMERS  R   SCOTT                PK_CUSTOMERS
CUSTOMERS                      PK_CUSTOMERS         P
ORDERS                         PK_ORDERS            P

SCOTT@orclpdb1> select count(1) from customers;

  COUNT(1)
----------
       319

SCOTT@orclpdb1> select count(1) from orders;

  COUNT(1)
----------
       105

SCOTT@orclpdb1> 
SCOTT@orclpdb1> !cat gather_tab_stats.sql
set verify on
exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>upper('&1'),cascade=>true,no_invalidate=>false);
set verify off
undefine 1

SCOTT@orclpdb1> @gather_tab_stats.sql orders

PL/SQLプロシージャが正常に完了しました。

SCOTT@orclpdb1> @gather_tab_stats.sql customers

PL/SQLプロシージャが正常に完了しました。

SCOTT@orclpdb1> 
SCOTT@orclpdb1> !cat makecsv.sql
-- 
-- parameter 1 : table name
-- 
set feed off
set timi off
set head off
set termout off
set veri off
set markup csv on
spool loaddata_&1..csv
select * from &1; 
spo off
set markup csv off
set termout on
set head on
set feed on
set veri on
undefine 1

SCOTT@orclpdb1> @makecsv customers
SCOTT@orclpdb1> @makecsv orders
SCOTT@orclpdb1> !ls -l loaddata*.csv
-rw-r--r--. 1 oracle oinstall 19021  7月 13 19:42 loaddata_customers.csv
-rw-r--r--. 1 oracle oinstall  6064  7月 13 19:42 loaddata_orders.csv

PostgreSQL (16.3) customers/orders表を作成（主キー制約や、参照整合性制約含む）、外部キー列に索引を作成したあと、copyコマンドでcsvファイルからデータをロードして統計情報取得という内容です。

perftestdb=> 
perftestdb=> CREATE TABLE customers
perftestdb-> (
perftestdb(>   customer_id INTEGER NOT NULL
perftestdb(>   , first_name VARCHAR(20) NOT NULL
perftestdb(>   , last_name VARCHAR(20) NOT NULL
perftestdb(>   , address VARCHAR(40)
perftestdb(>   , phone_number VARCHAR(25)
perftestdb(>   , CONSTRAINT pk_customers PRIMARY KEY (customer_id)
perftestdb(> );
CREATE TABLE
perftestdb=> CREATE TABLE orders
perftestdb-> (
perftestdb(>   order_id INTEGER NOT NULL
perftestdb(>   , order_date TIMESTAMP WITH TIME ZONE NOT NULL
perftestdb(>   , order_mode VARCHAR(8)
perftestdb(>   , customer_id INTEGER NOT NULL
perftestdb(>   , order_status SMALLINT
perftestdb(>   , order_total NUMERIC(8,2)vperftestdb(>   , sales_rep_id INTEGER
perftestdb(>   , promotion_id  INTEGER
perftestdb(>   , CONSTRAINT pk_orders PRIMARY KEY (order_id)
perftestdb(>   , CONSTRAINT fk_orders_customers foreign key (customer_id) references customers
perftestdb(> );
CREATE TABLE
perftestdb=> 
perftestdb=> CREATE INDEX fk_orders_customers ON orders(customer_id);
CREATE INDEX
perftestdb=> 
perftestdb=> \copy customers(customer_id,first_name,last_name,address,phone_number) from 'loaddata_customers.csv' csv
COPY 319
perftestdb=> \copy orders(order_id,order_date,order_mode,customer_id,order_status,order_total,sales_rep_id,promotion_id) from 'loaddata_orders.csv' csv
COPY 105
perftestdb=> vacuum analyze customers;
VACUUM
perftestdb=> vacuum analyze orders;
VACUUM
perftestdb=> 
 count 
-------
   319
(1 行)

perftestdb=> select count(1) from orders;
 count 
-------
   105
(1 行)

MySQL (8.0.36) customers/orders表を作成（主キー制約や、参照整合性制約含む）、外部キー列に索引を作成後、loadコマンドでcsvファイルからデータをロードして、統計情報取得という流れになっています
(loadコマンドでワーニングでてたりしますが、今回のテストでは影響ないので気にしないでください。。(^^;;;

mysql> CREATE TABLE customers
    -> (
    ->   customer_id INTEGER NOT NULL
    ->   , first_name VARCHAR(20) NOT NULL
    ->   , last_name VARCHAR(20) NOT NULL
    ->   , address VARCHAR(40)
    ->   , phone_number VARCHAR(25)
    ->   , CONSTRAINT pk_customers PRIMARY KEY (customer_id)
    -> );
Query OK, 0 rows affected (0.18 sec)

mysql> CREATE TABLE orders
    -> (
    ->   order_id INTEGER NOT NULL
    ->   , order_date TIMESTAMP NOT NULL
    ->   , order_mode VARCHAR(8)
    ->   , customer_id INTEGER NOT NULL
    ->   , order_status SMALLINT
    ->   , order_total NUMERIC(8,2)
    ->   , sales_rep_id INTEGER
    ->   , promotion_id  INTEGER
    ->   , CONSTRAINT pk_orders PRIMARY KEY (order_id)
    ->   , CONSTRAINT fk_orders_customers foreign key (customer_id) references customers (customer_id) 
    -> );
Query OK, 0 rows affected (0.07 sec)
mysql> CREATE INDEX fk_orders_customers ON orders(customer_id);
Query OK, 0 rows affected (0.09 sec)
Records: 0  Duplicates: 0  Warnings: 0

[master@localhost ~]$ mysql -u root -D perftestdb -p --local-infile=1
Enter password: 

....中略....

mysql> 
mysql> \! ls -l load*
-rw-rw-r--. 1 master master 19021  7月 14 19:26 loaddata_customers.csv
-rw-rw-r--. 1 master master  6064  7月 14 19:27 loaddata_orders.csv

mysql> load data local infile "./loaddata_customers.csv" into table perftestdb.customers fields terminated by ',' optionally enclosed by '"';
Query OK, 319 rows affected (0.10 sec)
Records: 319  Deleted: 0  Skipped: 0  Warnings: 0

mysql> load data local infile "./loaddata_orders.csv" into table perftestdb.orders fields terminated by ',' optionally enclosed by '"';
Query OK, 105 rows affected, 140 warnings (0.05 sec)
Records: 105  Deleted: 0  Skipped: 0  Warnings: 140

mysql> analyze table  perftestdb.customers;
+----------------------+---------+----------+----------+
| Table                | Op      | Msg_type | Msg_text |
+----------------------+---------+----------+----------+
| perftestdb.customers | analyze | status   | OK       |
+----------------------+---------+----------+----------+
1 row in set (0.05 sec)

mysql> analyze table  perftestdb.orders;
+-------------------+---------+----------+----------+
| Table             | Op      | Msg_type | Msg_text |
+-------------------+---------+----------+----------+
| perftestdb.orders | analyze | status   | OK       |
+-------------------+---------+----------+----------+
1 row in set (0.02 sec)

mysql> select count(1) from perftestdb.customers;
+----------+
| count(1) |
+----------+
|      319 |
+----------+
1 row in set (0.02 sec)

mysql> select count(1) from perftestdb.orders;
+----------+
| count(1) |
+----------+
|      105 |
+----------+
1 row in set (0.07 sec)

投稿日時 2024年7月24日 (水) 12時00分 Oracle, チューニング, FAQ, SQL, MySQL, PostgreSQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2024年7月23日 (火)

実行計画は, SQL文のレントゲン写真だ！ No.63 / Join Elimination （再び）その2

Previously on Mac De Oracle
実行計画は, SQL文のレントゲン写真だ！ No.63 / Join Elimination （再び）その1では、参照整合性制約を利用した Join Elimination の挙動を確認しました。

PostgreSQL、意外にも（知ってたくせに〜w）行われませんでしたね　MySQLは事前の想定通りでしたが:)

では、次の Join Elimination のテストケースを確認してみましょう。

シンプルな例で試しています。Oracle Database / PostgreSQL / MySQL それぞれに以下の2表を作成しておきます。
どちらの表も id 列が主キーですが、前回のケースのような参照整合性制約はありません。

Oracle Database同様の表をMySQL/PostgreSQLにも作成して検証。（データはあってもなくても結合の除外には影響しないためデータは登録していません）
(なおデータ型は、MySQL/PostgreSQLに合わせて変更しています。e.g. NUMBER->INTEGER, VARCHAR2 -> VARCHAR。　また、MySQL/PostgreSQLそれぞれで統計情報も取得しておきます）

SCOTT@orclpdb1> CREATE TABLE foo (id NUMBER PRIMARY KEY, note VARCHAR2(100));

表が作成されました。

SCOTT@orclpdb1> CREATE TABLE bar (id NUMBER PRIMARY KEY, memo VARCHAR2(100));

表が作成されました。

SCOTT@orclpdb1> !cat gather_tab_stats.sql
set verify on
exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>upper('&1'),cascade=>true,no_invalidate=>false);
set verify off
undefine 1

SCOTT@orclpdb1> @gather_tab_stats foo

PL/SQLプロシージャが正常に完了しました。

SCOTT@orclpdb1> @gather_tab_stats bar

PL/SQLプロシージャが正常に完了しました。

前述の表を使い、以下のSQL文を実行します！
このSQL文では、bar表を外部結合していますが、SELECTリストでは bar表を参照していません。
また、foo.id = bar.id は 1 : 0..1 であるため、bar表の対象行の結合されるかどうかは問合せ結果に影響しないようにしてあります。つまり、bar表は結合しなくてもよい問合せにしてあります。。。
（さあ、どうなるでしょうね。楽しくなってきました）

SELECT
  foo.id
  , foo.note
FROM
  foo
  LEFT OUTER JOIN bar
  ON
    foo.id = bar.id;

Oracle Database (21c)
すばらしい。無駄な結合を見つけ、Join Elimination していることを確認できます。（分かってましたけどw）

SCOTT@orclpdb1> l
  1  EXPLAIN PLAN FOR
  2  SELECT
  3    foo.id
  4    , foo.note
  5  FROM
  6    foo
  7    LEFT OUTER JOIN bar
  8    ON
  9*     foo.id = bar.id
 SCOTT@orclpdb1> /

解析されました。

経過: 00:00:00.01
SCOTT@orclpdb1> @?/rdbms/admin/utlxpls 

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------
Plan hash value: 1245013993

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    65 |     3   (0)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| FOO  |     1 |    65 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------

8行が選択されました。

PostgreSQL (16.3)
おおおおおおおーーーーーーーっ。このケースでは、PostgreSQLも Join Elimination しています！！！！！
bar表が結合されていません！　これまた新しい気づき。メモメモw

PostgreSQLのプランナー。 Join Elimination を全く実装していないのかと思いましたが、限定的なようですが、 Join Elimination が実装されているように見えますよね。
興味深い。発展途上というところか。。（次回のPostgreSQL アンカンファレンスで聞いてみようかな）

perftestdb=> EXPLAIN verbose
perftestdb-> SELECT
perftestdb->   foo.id
perftestdb->   , foo.note
perftestdb-> FROM
perftestdb->   foo
perftestdb->   LEFT OUTER JOIN bar
perftestdb->   ON
perftestdb->     foo.id = bar.id;

                         QUERY PLAN                         
------------------------------------------------------------
 Seq Scan on public.foo  (cost=0.00..0.00 rows=1 width=222)
   Output: foo.id, foo.note
(2 行)

MySQL (8.0.36)
んーーーーっ。MySQLのオプティマイザーは、Join Elimination は考慮していないように見えますよ。軽量なオプティマイザーが売りだからだろうか。。

mysql> EXPLAIN format=tree
    -> SELECT
    ->   foo.id
    ->   , foo.note
    -> FROM
    ->   foo
    ->   LEFT OUTER JOIN bar
    ->   ON
    ->     foo.id = bar.id;
+-----------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                       |
+-----------------------------------------------------------------------------------------------+
| -> Nested loop left join  (cost=0.7 rows=1)
    -> Table scan on foo  (cost=0.35 rows=1)
    -> Single-row covering index lookup on bar using PRIMARY (id=foo.id)  (cost=0.35 rows=1)
 |
+-----------------------------------------------------------------------------------------------+
1 row in set (0.03 sec)

海外のブログでは、実装されてない！　と言い切られているのもありましたが、PostgreSQL 16 では限定的ですが行われるようですね。（PostgreSQL 16より前のリリースってどうなんだろう。。13のままにしてたほうがおもしろかったかな。。。むむむ

ということで、次回へつづく。

投稿日時 2024年7月23日 (火) 12時00分 Oracle, チューニング, FAQ, SQL, MySQL, PostgreSQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2024年7月22日 (月)

実行計画は, SQL文のレントゲン写真だ！ No.63 / Join Elimination （再び）その1

Previously on Mac De Oracle
前回はコレクション型をアクセスした場合の実行計画がどうなるのかを確認しました。

今回は少し嗜好を変えて。。

先日、Oracle Databaseの Join Elimination が行われている実行計画を、ぼーっと眺めていたのですが、、そういえば、PostgreSQL / MySQL ってどうなんだっけ？　と。気になりまして。はい。
ちょいとぐぐると、海外のブログ等では、Join Elimination - Advanced SQL tuningなど含め、PostgreSQL / MySQL 共に実装されてない。ということが書かれているのが多かったのですが、とにかく自分の目で確かめてみるか。。。ということに。。

Oracle Databaseの実行計画の話ではないですが、本「実行計画は, SQL文のレントゲン写真だ！」シリーズの番外編的な位置付けで、今回含め3回に分けた現時点の動きを確認してみます。

まずは、Oracle Databaseでの Join elimination の復習 - 無駄に結合してないですよね？

・Join Elimination（結合の排除）と参照整合性制約　/ FAQ
・実行計画は, SQL文のレントゲン写真だ！　Oracle Database (全部俺）Advent Calendar 2022 Day 18 / No.53 / Join Elimination
・join elimination（結合の排除）のバリエーション / FAQ

Oracle Databaseの主要な Join Elimination 思い出しましたか？　復讐できましたよね！？　
ということで、PostgreSQL / MySQL 含め確認していきますよ〜っ！

今回は以下のバージョンのOracle Database/PostgreSQL/MySQLを利用。（PostgreSQL、やっと16にした! w

SCOTT@orclpdb1> select banner_full from v$version;

BANNER_FULL
----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0

perftestdb=> select version();
                                                 version                                                 
---------------------------------------------------------------------------------------------------------
 PostgreSQL 16.3 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-22), 64-bit
(1 行)

mysql>
+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+
1 row in set (0.00 sec)

この検証では、 Oracle Database のサンプルスキーマの一つである OE スキーマから、cusotomersの一部の列、および orders表を元に scottスキーマへ複製し、参照整合性制約を追加（ orders表のcustomer_idからcustomers表の主キーを参照 )します。データはあってもなくても構わないのですが、customers/orders表に関しては別ネタで検証する際に利用することも兼ねてデータもロードしています。
（表や参照整合性など利用したオブジェクト、ロード等含めたログは、最後 ( 後日公開予定 / 実行計画は, SQL文のレントゲン写真だ！ No.63 / Join Elimination （再び）その3 ) に記載しています）

さっそく、結果から見ていきましよう（面白いですよー、そうなの！！！　いう感じではありました。Oraclerからするとw

まずは、参照整合性制約で保証されていることで、結合不要と判断される Join Elimination から。 ( db tech showcase Tokyo 2013 - A35 特濃JPOUG：潮溜まりでジャブジャブ、SQLチューニングの「参照整合性制約アレルギー」でも紹介していたので、この挙動については知っているかたは多いと思います。参照整合性制約を使ってないとお目にかかることはないタイプの Join Elimination ではあるのですけどもw )

Oracle Database / PostgreSQL / MySQL それぞれに以下のような表と主キー制約、および、参照整合性制約 (orders.customer_id -> customers.customer_id)を作成します。

Oracle Databaseでの定義内容 (なおデータ型は、MySQL/PostgreSQLに合わせて変更しています。e.g. NUMBER(n)->INTEGER or SMALLINT, VARCHAR2-> VARCHAR, TIMESTAMP WITH LOCAL TIME ZONE -> TIMESTAMP WITH TIME ZONE, TIMESTAMP)

SCOTT@orclpdb1> desc customers
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 CUSTOMER_ID                                        NUMBER(6)
 FIRST_NAME                                NOT NULL VARCHAR2(20)
 LAST_NAME                                 NOT NULL VARCHAR2(20)
 ADDRESS                                            VARCHAR2(40)
 PHONE_NUMBER                                       VARCHAR2(25)

SCOTT@orclpdb1> desc orders                                  
 名前                                    NULL?    型
 ----------------------------------------- -------- ----------------------------
 ORDER_ID                                           NUMBER(12)
 ORDER_DATE                                NOT NULL TIMESTAMP(6) WITH LOCAL TIME
                                                     ZONE
 ORDER_MODE                                         VARCHAR2(8)
 CUSTOMER_ID                               NOT NULL NUMBER(6)
 ORDER_STATUS                                       NUMBER(2)
 ORDER_TOTAL                                        NUMBER(8,2)
 SALES_REP_ID                                       NUMBER(6)
 PROMOTION_ID                                       NUMBER(6)

TABLE_NAME                     INDEX_NAME                     COLUMN_NAME
------------------------------ ------------------------------ ------------------------------
CUSTOMERS                      PK_CUSTOMERS                   CUSTOMER_ID
ORDERS                         FK_ORDERS_CUSTOMERS            CUSTOMER_ID
ORDERS                         PK_ORDERS                      ORDER_ID

TABLE_NAME                     CONSTRAINT_NAME      CON R_OWNER              R_CONSTRAINT_NAME
------------------------------ -------------------- --- -------------------- --------------------
ORDERS                         FK_ORDERS_CUSTOMERS  R   SCOTT                PK_CUSTOMERS
CUSTOMERS                      PK_CUSTOMERS         P
ORDERS                         PK_ORDERS            P

このケースで実行するSQL文はそれぞれ共通で以下を使います。

SELECT
  DISTINCT
  order_id
FROM
  orders o 
  INNER JOIN customers c
  ON o.customer_id = c.customer_id
WHERE
  order_id < 2400;

Oracle Database (21c) customers表は結合されず、join elimination されていることがわかります。inner join で保証しようとしている orders 表に存在している order_idだcustomer表に存在している顧客の注文であるということが参照整合性制約で保証されているため、結合は不要と判断されたわけです。
参照整合性制約アレルギーのみなさんには耳の痛い話ではありますが、この制約のメリットの一つは、Join Eliminationだったりします。
話は少し脱線しますが、発症すると一生ものの参照整合性制約アレルギーなのでw うまく付き合っていきたいものですよね。使いたい！と思えなくなってしまうものなので、Pros/Consをよーーーーーく考えて上で判断したい仕組みですよね。

SCOTT@orclpdb1> l
  1  EXPLAIN PLAN FOR
  2  SELECT
  3    DISTINCT
  4    order_id
  5  FROM
  6    orders o
  7    INNER JOIN customers c
  8    ON o.customer_id = c.customer_id
  9  WHERE
 10*   order_id < 2400
SCOTT@orclpdb1> /

解析されました。

経過: 00:00:00.01
SCOTT@orclpdb1> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------
Plan hash value: 2834288864

------------------------------------------------------------------------------
| Id  | Operation        | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |           |    46 |   184 |     1   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| PK_ORDERS |    46 |   184 |     1   (0)| 00:00:01 |
------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("ORDER_ID"<2400)

13行が選択されました。

念のため、参照整合性制約が無い場合はどうなるか確認しておきましょう。
Join Elimination されず、customers表が結合されている状況が確認できますよね！！

SCOTT@orclpdb1> alter table orders disable constraint fk_orders_customers;

表が変更されました。

経過: 00:00:00.31
SCOTT@orclpdb1> l
  1  EXPLAIN PLAN FOR
  2  SELECT
  3    DISTINCT
  4    order_id
  5  FROM
  6    orders o
  7    INNER JOIN customers c
  8    ON o.customer_id = c.customer_id
  9  WHERE
 10*   order_id < 2400
SCOTT@orclpdb1> /

解析されました。

経過: 00:00:00.01
SCOTT@orclpdb1> @?/rdbms/admin/utlxpls

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------
Plan hash value: 572428435

----------------------------------------------------------------------------------------------
| Id  | Operation                     | Name         | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |              |    46 |   552 |     3  (34)| 00:00:01 |
|   1 |  SORT UNIQUE NOSORT           |              |    46 |   552 |     3  (34)| 00:00:01 |
|   2 |   NESTED LOOPS SEMI           |              |    46 |   552 |     2   (0)| 00:00:01 |
|   3 |    TABLE ACCESS BY INDEX ROWID| ORDERS       |    46 |   368 |     2   (0)| 00:00:01 |
|*  4 |     INDEX RANGE SCAN          | PK_ORDERS    |    46 |       |     1   (0)| 00:00:01 |
|*  5 |    INDEX UNIQUE SCAN          | PK_CUSTOMERS |     1 |     4 |     0   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - access("ORDER_ID"<2400)
   5 - access("O"."CUSTOMER_ID"="C"."CUSTOMER_ID")

18行が選択されました。

PostgreSQL (16.3) なんとーーー。PostgreSQLの場合は、Join elimination しないのか。（初めて知った！！！）　脳のシワが一つ増えた！

perftestdb=> explain verbose
perftestdb-> SELECT
perftestdb->   DISTINCT
perftestdb->   order_id
perftestdb-> FROM
perftestdb->   orders o 
perftestdb->   INNER JOIN customers c
perftestdb->   on o.customer_id = c.customer_id
perftestdb-> WHERE
perftestdb->   order_id < 2400;
                                                QUERY PLAN                                                 
-----------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=7.52..7.98 rows=46 width=4)
   Output: o.order_id
   Group Key: o.order_id
   ->  Merge Join  (cost=3.73..7.40 rows=46 width=4)
         Output: o.order_id
         Merge Cond: (c.customer_id = o.customer_id)
         ->  Index Only Scan using pk_customers on public.customers c  (cost=0.15..12.93 rows=319 width=4)
               Output: c.customer_id
         ->  Sort  (cost=3.58..3.70 rows=46 width=8)
               Output: o.order_id, o.customer_id
               Sort Key: o.customer_id
               ->  Seq Scan on public.orders o  (cost=0.00..2.31 rows=46 width=8)
                     Output: o.order_id, o.customer_id
                     Filter: (o.order_id < 2400)
(14 行)

Join Eliminationされていないので参照整合性制約の有無が影響しないのは自明ですが、念の為w 参照整合性制約を削除して実行計画を確認してみます。
(PostgreSQLでは参照整合性制約を無効化／有効化することができないため、dropすることで無効化しています)

一目瞭然、影響していないことがわかります。（そうなのかーーーー。まじで知らなかったこれ）

perftestdb=> alter table orders drop constraint fk_orders_customers;
ALTER TABLE
perftestdb=*> commit;
COMMIT
perftestdb=> explain verbose
perftestdb-> SELECT
perftestdb->   DISTINCT
perftestdb->   order_id
perftestdb-> FROM
perftestdb->   orders o 
perftestdb->   INNER JOIN customers c
perftestdb->   ON o.customer_id = c.customer_id
perftestdb-> WHERE
perftestdb->   order_id < 2400;
                                                QUERY PLAN                                                 
-----------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=7.52..7.98 rows=46 width=4)
   Output: o.order_id
   Group Key: o.order_id
   ->  Merge Join  (cost=3.73..7.40 rows=46 width=4)
         Output: o.order_id
         Merge Cond: (c.customer_id = o.customer_id)
         ->  Index Only Scan using pk_customers on public.customers c  (cost=0.15..12.93 rows=319 width=4)
               Output: c.customer_id
         ->  Sort  (cost=3.58..3.70 rows=46 width=8)
               Output: o.order_id, o.customer_id
               Sort Key: o.customer_id
               ->  Seq Scan on public.orders o  (cost=0.00..2.31 rows=46 width=8)
                     Output: o.order_id, o.customer_id
                     Filter: (o.order_id < 2400)
(14 行)

MySQL (8.0.36) MySQLもPostgreSQL同様に、参照整合性制約があったとしても customers表を結合しており、Join elimination は行われていません。
（海外の記事の通り、MySQL/PostgreSQLでは Join Elimination　による結合の最適化は実装されていないように見えますね。これまでのところは。）

mysql> explain format=tree
    -> SELECT
    ->   DISTINCT
    ->   order_id
    -> FROM
    ->   orders o 
    ->   INNER JOIN customers c
    ->   ON o.customer_id = c.customer_id
    -> WHERE
    ->   order_id < 2400;
+---------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                             |
+---------------------------------------------------------------------------------------------------------------------+
| -> Table scan on   (cost=30.2..33.3 rows=46)
    -> Temporary table with deduplication  (cost=30.2..30.2 rows=46)
        -> Nested loop inner join  (cost=25.6 rows=46)
            -> Filter: (o.order_id < 2400)  (cost=9.48 rows=46)
                -> Index range scan on o using PRIMARY over (order_id < 2400)  (cost=9.48 rows=46)
            -> Limit: 1 row(s)  (cost=0.252 rows=1)
                -> Single-row covering index lookup on c using PRIMARY (customer_id=o.customer_id)  (cost=0.252 rows=1)
 |
+---------------------------------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

MySQLでも同様に、参照整合性制約を無効化します。
（こちらも、有効／無効だけを制御することはできず、参照整合性制約を削除して無効化する必要があります。戻すどきめんどくさいのだけどもw FOREIGN_KEY_CHECKSでチェックしないという方法はあるらしい）

こちらも参照整合性制約の有無は影響していないことは明らかですね。

mysql> alter table orders drop foreign key fk_orders_customers;
Query OK, 0 rows affected (0.03 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> explain format=tree
    -> SELECT
    ->   DISTINCT
    ->   order_id
    -> FROM
    ->   orders o 
    ->   INNER JOIN customers c
    ->   ON o.customer_id = c.customer_id
    -> WHERE
    ->   order_id < 2400;
+---------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                             |
+---------------------------------------------------------------------------------------------------------------------+
| -> Table scan on   (cost=30.2..33.3 rows=46)
    -> Temporary table with deduplication  (cost=30.2..30.2 rows=46)
        -> Nested loop inner join  (cost=25.6 rows=46)
            -> Filter: (o.order_id < 2400)  (cost=9.48 rows=46)
                -> Index range scan on o using PRIMARY over (order_id < 2400)  (cost=9.48 rows=46)
            -> Limit: 1 row(s)  (cost=0.252 rows=1)
                -> Single-row covering index lookup on c using PRIMARY (customer_id=o.customer_id)  (cost=0.252 rows=1)
 |
+---------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

いきなり違いが見えて、楽しいーーーーぞっ。 :)

海側も無茶苦茶暑いのだろうか、海風吹いてそうでもないのだろうか。。と湘南方面を見ながらw

ということで、次回へつつく。

投稿日時 2024年7月22日 (月) 12時00分 Oracle, チューニング, FAQ, SQL, MySQL, PostgreSQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2024年7月11日 (木)

帰ってきた！標準はあるにはあるが癖の多いSQL #16 - FROM句のインラインビューのエイリアスにもクセがある（必須だったり、任意だったり）

Previously on Mac De Oracle
前回の癖は、SELECTリストに記述したスカラー副問合せが実行計画上どうみせられるかにも癖がでるというお話でした。

今日は副問合せは副問合せでもインラインビューの話題です。
FROM句でインラインビューを使う場合、表エイリアスを記述しなくてもエラーにはならいってのは、Oraclerを長年やってると不思議なことではないというか、そういうものだと思ってたりします。
とはいえ、可読性含や不思議な結果になったりする不具合などに遭遇するリスクを回避する意味でも表エイリアスを記述するのが手癖になっているかたも多いのではないでしょうか。私もそうですw（コーディング規約にも記載されていることは多いと思いますし）

ということで、今日の癖を見てみることにしますw

Oracle Database (23ai) インラインビューで表エイリアスを記述しなくても文法エラーにはなりません。
Oracle Database / Release 19 / SQL言語リファレンス / SELECT / table_reference::=のダイアグラムにあるように表エイリアスを省略可能です。（前述したように省略しないことの方が多いですけども、可読性向上のためにも）

SCOTT@localhost:1521/freepdb1> @inlineview_alias_name.sql
  1  SELECT
  2    empno
  3   ,ename
  4  FROM
  5  (
  6    SELECT
  7      empno
  8     ,ename
  9     ,mgr
 10    FROM
 11      emp
 12  )
 13  WHERE
 14*   mgr IS NULL

     EMPNO ENAME
---------- ----------
      7839 KING


  1  SELECT
  2    empno
  3   ,ename
  4  FROM
  5  (
  6    SELECT
  7      /*+ NO_MERGE */
  8      empno
  9     ,ename
 10     ,mgr
 11    FROM
 12      emp
 13  )
 14  WHERE
 15*   mgr IS NULL

     EMPNO ENAME
---------- ----------
      7839 KING


  1  SELECT
  2    empno
  3   ,ename
  4  FROM
  5  (
  6    SELECT
  7      empno
  8     ,ename
  9     ,mgr
 10    FROM
 11      emp
 12  ) iv_emp
 13  WHERE
 14*   mgr IS NULL

     EMPNO ENAME
---------- ----------
      7839 KING

MySQL (8.0.36) インラインビューに表エイリアスを記述しないと見事にエラーになります。コーディング規約で書くこと！なんて明記しなくても、書かないとシンタックスエラーなので書き忘れて、あ”〜っということはないわけすw
MySQL 8.0 リファレンスマニュアル / SQL ステートメント / データ操作ステートメント / SELECT ステートメント / 13.2.10.2 JOIN 句 / table_subqueryに、”table_subquery は、FROM 句では導出テーブルまたはサブクエリーとも呼ばれます。セクション13.2.11.8「導出テーブル」を参照してください。このようなサブクエリーには、サブクエリーの結果にテーブル名を指定するエイリアスを含める必要があります。”と記載されています。

mysql> SELECT
    ->   empno
    ->  ,ename
    -> FROM
    -> (
    ->   SELECT 
    ->     empno
    ->    ,ename
    ->    ,mgr
    ->   FROM
    ->     emp
    -> )
    -> WHERE
    ->   mgr IS NULL
    -> ;
ERROR 1248 (42000): Every derived table must have its own alias


mysql> SELECT
    ->   empno
    ->  ,ename
    -> FROM
    -> (
    ->   SELECT
    ->     empno
    ->    ,ename
    ->    ,mgr
    ->   FROM
    ->     emp
    -> ) iv_emp
    -> WHERE
    ->   mgr IS NULL
    -> ;
+-------+-------+
| empno | ename |
+-------+-------+
|  7839 | KING  |
+-------+-------+
1 row in set (0.00 sec)


mysql> SELECT
    ->   /*+ NO_MERGE(iv_emp) */
    ->   empno
    ->  ,ename
    -> FROM
    -> (
    ->   SELECT
    ->     empno
    ->    ,ename
    ->    ,mgr
    ->   FROM
    ->     emp
    -> ) iv_emp
    -> WHERE
    ->   mgr IS NULL
    -> ;
+-------+-------+
| empno | ename |
+-------+-------+
|  7839 | KING  |
+-------+-------+
1 row in set (0.02 sec)

PostgreSQL (13.14) PostgreSQLもMySQLと同じ挙動ですね。
PostgreSQL 13.1文書 / 第7章問い合わせ / 7.2. テーブル式 / 7.2.1. FROM句 / 7.2.1.3. 副問い合わせに、"7.2.1.3. 副問い合わせ派生テーブルを指定する副問い合わせは括弧で囲む必要があります。また、（7.2.1.2にあるように）必ずテーブル別名が割り当てられている必要があります。例を示します。"とあります。

perftestdb=> SELECT
perftestdb->   empno
perftestdb->  ,ename
perftestdb-> FROM
perftestdb-> (
perftestdb(>   SELECT 
perftestdb(>     empno
perftestdb(>    ,ename
perftestdb(>    ,mgr
perftestdb(>   FROM
perftestdb(>     emp
perftestdb(> )
perftestdb-> WHERE
perftestdb->   mgr IS NULL
perftestdb-> ;
ERROR:  subquery in FROM must have an alias
行 5: (
      ^
HINT:  For example, FROM (SELECT ...) [AS] foo.

perftestdb=> SELECT
perftestdb->   empno
perftestdb->  ,ename
perftestdb-> FROM
perftestdb-> (
perftestdb(>   SELECT
perftestdb(>     empno
perftestdb(>    ,ename
perftestdb(>    ,mgr
perftestdb(>   FROM
perftestdb(>     emp
perftestdb(> ) iv_emp
perftestdb-> WHERE
perftestdb->   mgr IS NULL
perftestdb-> ;
 empno | ename 
-------+-------
  7839 | KING
(1 行)

実際、この手の癖に遭遇したOracle Databaseなど表エイリアス不要の世界の方々は、「おまえは、なにをいっているんだぁ〜」という感じで一瞬固まったあとに、あ〜〜〜〜っ！　、なるとは思いますけどw

ところで、最近のdown pour半端ない感じがします。私の子供の頃でも台風以外でみたことのないような集中的な豪雨が頻発しています。用心しても来るものはきてしまうわけですが、正しい情報を入手して早めに避難するなりしましょうね。と。実家近くの川の水位が落ち着いたのをみて安堵する。。。

Enjoy SQL! and 癖。

投稿日時 2024年7月11日 (木) 12時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL | 固定リンク | 0 | コメント (0)

2024年7月10日 (水)

帰ってきた！標準はあるにはあるが癖の多いSQL #15 - 実行計画でスカラー副問合せの見せ方にも癖がでる

さて、今日はまた、癖の話をしたいと思います！
今回のネタには標準があるわけではないですが、SELECTリストに記述するスカラー副問合せの実行計画上の見せ方の癖というか違いw

実は、このネタ、2020年ぐらいに、目黒方面（ご存知の方だけwww）にある某所で定期開催される内部勉強会的なLT大会で使ったネタだったのですが、そのあとゴタゴタしていて、ブログで書き漏らしていたことを、昨日ネタリストを纏めていた時に思い出した次いでに小ネタとして書いておきます。　(その時のKeynoteのタイトルページだけ載せておきますw）

この癖を把握していれば、SELECTリストに記述されたスカラー副問合せチューニングするような案件に遭遇してしまったときでも何かの役に立つかもしれません。
（少なくとも実行計画を見ただけで、これはSELECTリストにスカラー副問合せがある！　ということは一瞬で理解できるようになるはず。。。）

では早速見てみましょう。(Oracle Databaseではお馴染みの表とデータをMySQL/PostgreSQLでも事前に作成してあります)

SCOTT@orclpdb1> select * from dept;

    DEPTNO DNAME                                      LOC
---------- ------------------------------------------ ---------------------------------------
        10 ACCOUNTING                                 NEW YORK
        20 RESEARCH                                   DALLAS
        30 SALES                                      CHICAGO
        40 OPERATIONS                                 BOSTON
        
SCOTT@orclpdb1> select * from emp;

     EMPNO ENAME                          JOB                                MGR HIREDATE        SAL       COMM     DEPTNO
---------- ------------------------------ --------------------------- ---------- -------- ---------- ---------- ----------
      7369 SMITH                          CLERK                             7902 80-12-17        800                    20
      7499 ALLEN                          SALESMAN                          7698 81-02-20       1600        300         30
      7521 WARD                           SALESMAN                          7698 81-02-22       1250        500         30
      7566 JONES                          MANAGER                           7839 81-04-02       2975                    20
      7654 MARTIN                         SALESMAN                          7698 81-09-28       1250       1400         30
      7698 BLAKE                          MANAGER                           7839 81-05-01       2850                    30
      7782 CLARK                          MANAGER                           7839 81-06-09       2450                    10
      7839 KING                           PRESIDENT                              81-11-17       5000                    10
      7844 TURNER                         SALESMAN                          7698 81-09-08       1500          0         30
      7900 JAMES                          CLERK                             7698 81-12-03        950                    30
      7902 FORD                           ANALYST                           7566 81-12-03       3000                    20
      7934 MILLER                         CLERK                             7782 82-01-23       1300                    10

実行計画で見えるSELECT中のスカラー副問合せの位置に注目してください。（赤字にしてあります）

Oracle Databaseでは本体のクエリーより上に表示されますが、PostgreSQL/MySQLでは逆で、下に表示されます。

このような見せ方の違いが逆になるのって以前もご紹介したの覚えているでしょうか？
そう、帰ってきた！標準はあるにはあるが癖の多いSQL #7 - Hash Joinの実行計画の見せ方にも癖がでるで紹介した癖ですね。
HASH JOINのBUILD/PROBEは実行計画上、Oracle DatabaseとPostgreSQL/MySQLでは順序が逆に表現されていましたよね！

これに気づけば、あなたも、道にまようこともなく実行計画を追っていけるはず！！ :)

Oracle Database (21c)
（このようにスカラー副問合せ部分が性能上ネックになりそうな場合、Oracle Databaseのオプティマイザは、スカラー副問合せを結合に書き換えて最適化することがあるため、この例ではそれを無効化するNO_UNNESTヒントを利用しています。）

Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0
に接続されました。
SCOTT@orclpdb1> !cat scalar_subquery_plan.sql
SELECT	
  deptno
  ,dname
  ,(
     SELECT
       /*+ NO_UNNEST */
       MAX(sal)
     FROM
       emp 
     WHERE
       emp.deptno = dept.deptno
  ) AS max_sal
FROM
  dept
ORDER BY 
  deptno
;

SCOTT@orclpdb1> set autot trace exp stat
SCOTT@orclpdb1> @scalar_subquery_plan.sql

経過: 00:00:00.18

実行計画
----------------------------------------------------------
Plan hash value: 1445953226

------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |         |     5 |    65 |     9   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE                      |         |     1 |     7 |            |          |
|   2 |   TABLE ACCESS BY INDEX ROWID BATCHED| EMP     |     4 |    28 |     2   (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN                  | IX_DEPT |     4 |       |     1   (0)| 00:00:01 |
|   4 |  TABLE ACCESS BY INDEX ROWID         | DEPT    |     5 |    65 |     3   (0)| 00:00:01 |
|   5 |   INDEX FULL SCAN                    | PK_DEPT |     5 |       |     1   (0)| 00:00:01 |
------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - access("EMP"."DEPTNO"=:B1)

見ての通り、PostgreSQL/MySQLはスカラー副問合せ部分の実行計画の位置がOracle Databaseのそれとは異なることがわかると思います。:)
PostgreSQL(13.14)

perftestdb=> \! cat scalar_subquery_plan.sql
EXPLAIN ANALYZE
SELECT	
  deptno
  ,dname
  ,(
     SELECT
       MAX(sal)
     FROM
       emp 
     WHERE
       emp.deptno = dept.deptno
  ) AS max_sal
FROM
  dept
ORDER BY 
  deptno
;
perftestdb=> \i scalar_subquery_plan.sql
                                                   QUERY PLAN                                                    
-----------------------------------------------------------------------------------------------------------------
 Sort  (cost=5.87..5.88 rows=4 width=46) (actual time=0.246..0.247 rows=4 loops=1)
   Sort Key: dept.deptno
   Sort Method: quicksort  Memory: 25kB
   ->  Seq Scan on dept  (cost=0.00..5.83 rows=4 width=46) (actual time=0.065..0.095 rows=4 loops=1)
         SubPlan 1
           ->  Aggregate  (cost=1.19..1.20 rows=1 width=32) (actual time=0.016..0.017 rows=1 loops=4)
                 ->  Seq Scan on emp  (cost=0.00..1.18 rows=5 width=5) (actual time=0.003..0.006 rows=4 loops=4)
                       Filter: (deptno = dept.deptno)
                       Rows Removed by Filter: 10
 Planning Time: 1.916 ms
 Execution Time: 0.843 ms
(11 行)

MySQL(8.0.36)

mysql> \! cat scalar_subquery_plan.sql
EXPLAIN FORMAT=tree
SELECT	
  deptno
  ,dname
  ,(
     SELECT
       MAX(sal)
     FROM
       emp 
     WHERE
       emp.deptno = dept.deptno
  ) AS max_sal
FROM
  dept
ORDER BY 
  deptno
;

mysql> \. scalar_subquery_plan.sql
+----------------------------------------------------------------------+
| EXPLAIN                                                              |
+----------------------------------------------------------------------+
| -> Index scan on dept using PRIMARY  (cost=0.65 rows=4)
-> Select #2 (subquery in projection; dependent)
    -> Aggregate: max(emp.sal)  (cost=1.28 rows=1)
        -> Filter: (emp.deptno = dept.deptno)  (cost=1.14 rows=1.4)
            -> Table scan on emp  (cost=1.14 rows=14)
 |
+----------------------------------------------------------------------+
1 row in set, 1 warning (0.05 sec)
mysql> show warnings;
+-------+------+------------------------------------------------------------------------------------+
| Level | Code | Message                                                                            |
+-------+------+------------------------------------------------------------------------------------+
| Note  | 1276 | Field or reference 'perftestdb.dept.deptno' of SELECT #2 was resolved in SELECT #1 |
+-------+------+------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

ただし、Oracle DatabaseだけはSELECTリストのスカラー副問合せをUNNESTして結合に書き換える最適化を行うこともあるので、実行計画だけだと元のSQL文に記述されているSELECTリスト中のスカラー副問合せに気付けないこともあります.
とはいえ、一般的には、そこに至るまでの間に、SQL文は抜き出せているでしょうから困ることはないでしょうね。（現場がリモートで、実行計画だけ送られてきた！なんてことでもなければw）

SELECTリスト中に記載したスカラー副問合せがUNNESTされてMERGE JOINに書き換えられた例（UNNESTヒント利用）
2013年、Oracle Database 12cR1で実装された最適化機能で、Scalar Subquery Unnesting Transformation (Oracle Database 12c R1 New Feature)でも説明していますので、詳しく知りたい方は参考にしてみてください。

SCOTT@orclpdb1> !cat scalar_subquery_unnest.sql
SELECT
  deptno
  ,dname
  ,(
     SELECT
       /*+ UNNEST */
       MAX(sal)
     FROM
       emp
     WHERE
       emp.deptno = dept.deptno
  ) AS max_sal
FROM
  dept
ORDER BY
  deptno
;

SCOTT@orclpdb1> @scalar_subquery_unnest.sql

経過: 00:00:00.17

実行計画
----------------------------------------------------------
Plan hash value: 2834279049

-----------------------------------------------------------------------------------------
| Id  | Operation                    | Name     | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |          |     5 |   145 |    11  (19)| 00:00:01 |
|   1 |  MERGE JOIN OUTER            |          |     5 |   145 |    11  (19)| 00:00:01 |
|   2 |   TABLE ACCESS BY INDEX ROWID| DEPT     |     5 |    65 |     3   (0)| 00:00:01 |
|   3 |    INDEX FULL SCAN           | PK_DEPT  |     5 |       |     1   (0)| 00:00:01 |
|*  4 |   SORT JOIN                  |          |     4 |    64 |     8  (25)| 00:00:01 |
|   5 |    VIEW                      | VW_SSQ_1 |     4 |    64 |     7  (15)| 00:00:01 |
|   6 |     HASH GROUP BY            |          |     4 |    28 |     7  (15)| 00:00:01 |
|   7 |      TABLE ACCESS FULL       | EMP      |    14 |    98 |     6   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - access("ITEM_1"(+)="DEPT"."DEPTNO")
       filter("ITEM_1"(+)="DEPT"."DEPTNO")

Enjoy SQL! and 癖

ではまた。

投稿日時 2024年7月10日 (水) 17時00分 Oracle, チューニング, FAQ, SQL, MySQL, PostgreSQL, Oracle Database 12c release 1, パフォーマンス, Oracle Database 12c Release 2, Oracle Database 18c, Oracle Database 19c, Oracle Database 21c, Oracle Database 23c Free Developer Release | 固定リンク | 0 | コメント (0)

2024年7月 8日 (月)

VirtualBox TestBuild 7.0.97r163779 (2024-07-04T18:53:02Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録

2024-07-04T18:53:02Z に最新のTestBuild ( development revision 163779 ) が公開されていました。

恒例のOracle Database 21c on VirtualBox TestBuild for macOS/ARM64 の起動時間の記録です。

今回は、M1/M2とも前回とほぼ同じぐらい。改善は次回に期待 :) :) :) :) :)
とはいえ、そろそろ大詰め？　な感じもしなくもない。。。。

oracle@Mac-Studio ~ % ./print_env.sh 
 
*** mac info. ***
ProductName:		macOS
ProductVersion:		14.5
BuildVersion:		23F79
 
*** maxOS ver. ***
      Model Name: Mac Studio
      Chip: Apple M1 Ultra
      Total Number of Cores: 20 (16 performance and 4 efficiency)
      Memory: 64 GB
 
*** VirtualBox ver. ***
7.0.97r163779

起動1回目 : 168 sec
停止1回目 :  77 sec
起動2回目 : 156 sec
停止2回目 :  48 sec

oracle@angelfish ~ % ./print_env.sh

*** mac info. ***
      Model Name: MacBook Air
      Chip: Apple M2
      Total Number of Cores: 8 (4 performance and 4 efficiency)
      Memory: 24 GB

*** macOS ver. ***
ProductName:		macOS
ProductVersion:		14.5
BuildVersion:		23F79

*** VirtualBox ver. ***
7.0.97r163779

起動1回目 :  93 sec
停止1回目 :  33 sec
起動2回目 :  95 sec
停止2回目 :  55 sec

VMのOSバージョンなどは過去のエントリーを見ていただくとして、M1/M2 それぞれ以下のPostgreSQL/MySQL/Oracle Databaseが起動することを確認。ルーティーン :)

MySQL

[master@localhost ~]$ mysql -u scott -D perftestdb -p -h localhost -e 'select version();'
Enter password: 
+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+

PostgreSQL

[master@localhost ~]$ sudo su - postgres -c 'psql -d perftestdb -U discus -p 5432 -W -h localhost -c "select version()"'
パスワード： 
                                                 version                                                  
----------------------------------------------------------------------------------------------------------
 PostgreSQL 13.14 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20), 64-bit
(1 行)

Oracle Database (21c)

[oracle@localhost ~]$ sqlplus / as sysdba @version

....中略....

BANNER_FULL
-----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0

Oracle Database (23ai)

[oracle@localhost ~]$ sqlplus hr/oracle@localhost:1521/freepdb1 @version

....中略....

BANNER_FULL
--------------------------------------------------------------------------------
Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.4.0.24.05

では、次回の起動停止時間ログをお楽しみに:)
最近のペースだと、7月の後半にありそうですよね.

投稿日時 2024年7月 8日 (月) 12時34分 Oracle, Mac, VirtualBox, MySQL, PostgreSQL, Oracle Database 21c, Oracle Database 23c Free Developer Release, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年7月 1日 (月)

帰ってきた！標準はあるにはあるが癖の多いSQL #14 - コメントを書く位置にも癖がでる (SQL Clientにも癖がある)

Previously on Mac De Oracle
前回は、帰ってきた！標準はあるにはあるが癖の多いSQL #13 - コメント書くにも癖があるでした。
今回は、続編w とは言ってもMySQLが主役ではありませんし、DBMSのエンジンの癖でもなく、SQL Clentの癖のお話です。

前回利用したSQL文（SQLスクリプト化してありますが、スクリプト化せずコピペしても同じ）に以下のような位置に一行コメントを書いてみました。
MySQLの制限も考慮して、(--)の後には半角スペースを忘れずに！

MySQL (8.0.26) ふむふむ、という感じですよね。

[master@localhost ~]$ mysql -u scott -D perftestdb -p 
Enter password: 

....略...

mysql> \! cat one_more_thing.sql
SELECT 
  empno
 ,ename
FROM
  emp
WHERE
  mgr IS NULL; -- It means president of the company.
mysql> 
mysql> 
mysql> \. one_more_thing.sql
+-------+-------+
| empno | ename |
+-------+-------+
|  7839 | KING  |
+-------+-------+
1 row in set (0.01 sec)

mysql>

PostgreSQL (13.14) PostgreSQLもふむふむという感じ。

psql -d perftestdb -U discus -p 5432 -W -h localhost
パスワード： 
psql (13.14)
"help"でヘルプを表示します。

....略...

perftestdb=> \! cat one_more_thing.sql
SELECT 
  empno
 ,ename
FROM
  emp
WHERE
  mgr IS NULL; -- It means president of the company.
perftestdb=> 
perftestdb=> 
perftestdb=> \i one_more_thing.sql
 empno | ename 
-------+-------
  7839 | KING
(1 行)

perftestdb=>

Oracle Database (23ai)

さて、お待ちかね、今回の癖の持ち主も実はOracle。といっても、SQL clientのSQL*Plusです。挙動を見てみましょう。
おやおや〜〜〜〜。結果が返らずスクリプトが終了しちゃいました。どういうこと？

[oracle@localhost ~]$ sqlplus -version

SQL*Plus: Release 23.0.0.0.0 - Production
Version 23.4.0.24.05

[oracle@localhost ~]$ sqlplus scott/tiger@localhost:1521/freepdb1

....略...

SCOTT@localhost:1521/freepdb1> !cat one_more_thing.sql
SELECT 
  empno
 ,ename
FROM
  emp
WHERE
  mgr IS NULL; -- It means president of the company.


SCOTT@localhost:1521/freepdb1> @one_more_thing.sql

SQL文はしっかりSQL*Plusのバッファにあるに、どういうことでしょう。 r または / で再実行させると、、

え、え、エラ〜だぁ！　。。。。
いったい、おまえは、何をいっているんだぁ（ジョジョ風）

SCOTT@localhost:1521/freepdb1> l
  1  SELECT
  2    empno
  3   ,ename
  4  FROM
  5    emp
  6  WHERE
  7*   mgr IS NULL; -- It means president of the company.
SCOTT@localhost:1521/freepdb1> /
  mgr IS NULL; -- It means president of the company.
             *
ERROR at line 7:
ORA-03048: SQL reserved word ';' is not syntactically valid following '...FROM
emp
WHERE
mgr IS NULL'
Help: https://docs.oracle.com/error-help/db/ora-03048/

これ、一行コメントの位置がまずいんです。 SQL*PLusの癖せいです。（昔からの癖ですので。。。
(;)セミコロンの後に記述されている一行コメントを該当行の上において、セミコロンより前になるように修正してみましょう！

こんどは正しい結果が返ってきました！ wwww SQL*Plusの癖もわかりにくいですね。癖の存在をしらないと。。。（マニュアルにも記載されているので参考にしてください）

SCOTT@localhost:1521/freepdb1> edit one_more_thing.sql

SCOTT@localhost:1521/freepdb1> !cat one_more_thing.sql
SELECT 
  empno
 ,ename
FROM
  emp
WHERE
  -- It means president of the company.
  mgr IS NULL;

SCOTT@localhost:1521/freepdb1> @one_more_thing.sql

     EMPNO ENAME
---------- ----------
      7839 KING

参考）

Oracle Database / Release 19 / ユーザーズ・ガイドおよびリファレンス / 5 SQL*Plusでのスクリプトの使用 / 文の終了記号(ピリオド、セミコロンまたはスラッシュ)の後に、コメントを挿入しないでください。

では、最後に、Oracle純正のSQL client、実は、最近はもう一つあるんです。 Oraclerならみなさんご存知の、SQLcl です。
こちら、SQL*Plusと異なり、前述した癖がありません。MySQL/PostgreSQL純正のSQL clientと同じ位置に一行コメントを書いても怒られることはありません。なかなか難しいですね。Oracle純正でも挙動が異なるのでご注意くださいね。。。（苦笑いw

この挙動の違い、私もついさっき気づいたんですけどね。wwwww このエントリー書きながらwwwww (本当ですw)

[oracle@localhost ~]$ sql -version

SQLcl: リリース24.1.0.0 Production ビルド: 24.1.0.087.0929

[oracle@localhost ~]$ sql scott/tiger@localhost:1521/freepdb1

....略...

SCOTT@localhost:1521/freepdb1> !cat one_more_thing.sql
SELECT 
  empno
 ,ename
FROM
  emp
WHERE
  mgr IS NULL;  -- It means president of the company.

SCOTT@localhost:1521/freepdb1> 
SCOTT@localhost:1521/freepdb1> @one_more_thing.sql

   EMPNO ENAME    
________ ________ 
    7839 KING

SQL Client特有の癖もあるので本体以外でも癖には注意しましょうね。

Enjoy SQL! and 癖。

ではまた。

投稿日時 2024年7月 1日 (月) 20時25分 Oracle, FAQ, SQL, MySQL, PostgreSQL, SQL Client | 固定リンク | 0 | コメント (0)

帰ってきた！標準はあるにはあるが癖の多いSQL #13 - コメント書くにも癖がある

人間、なくて七癖。とか申しまして、わしゃ癖がない。といぅ人でも、七つぐらいは癖がある。と言ぅんですなぁ。
SQLも同じで、標準に対応しています。と言う割には、びっくりするぐらい癖があります。
（なぜか落語風w）

ということで、本日の癖、SQLにコメントを書くときは、どのタイプがお好きですかね？　みなさん。
複数行コメントと単一行コメント併用していますが、知ってる人しかしらない（そりゃそうだ）w
コメントを書くにも、ちょっとした癖の持ち主もいたりします。

Oracle Database (23ai)

SCOTT@localhost:1521/freepdb1> !cat sqlcomment.sql
SELECT
  /*
    foo
    bar
  */
  empno
 ,ename  --foobar
FROM
  emp
WHERE
  empno = 7900;

SCOTT@localhost:1521/freepdb1> @sqlcomment.sql

     EMPNO ENAME
---------- ----------
      7900 JAMES

PostgreSQL (13.14) Oracle Databaseと同じルールなのでそのまま使えます

perftestdb=> \! cat sqlcomment.sql
SELECT
  /*
    foo
    bar
  */
  empno
 ,ename  --foobar
FROM
  emp
WHERE
  empno = 7900;
perftestdb=> \i sqlcomment.sql
 empno | ename 
-------+-------
  7900 | JAMES
(1 行)

MySQL (8.0.36) MySQLでは一行コメント(--)の後に半角スペースが必須となっているので注意なのね。

mysql> \! cat sqlcomment.sql
SELECT
  /*
    foo
    bar
  */
  empno
 ,ename  --foobar
FROM
  emp
WHERE
  empno = 7900;
mysql> 
mysql> \. sqlcomment.sql
ERROR 1054 (42S22): Unknown column 'foobar' in 'field list'
mysql>

なかなか、いい癖もってますよね。MySQL

MySQLの場合、一行コメントとして、(#)もサポートされていて、こちらは、(#)の半角スペースは必須ではないと！！

mysql> \! cat sqlcomment.sql
SELECT
  /*
    foo
    bar
  */
  empno
 ,ename  #foobar
FROM
  emp
WHERE
  empno = 7900;
mysql> \. sqlcomment.sql
+-------+-------+
| empno | ename |
+-------+-------+
|  7900 | JAMES |
+-------+-------+
1 row in set (0.04 sec)

最後に、MySQLで有効なコメント記述を確認しておこう。(/* */)や(-- )という記述にしておけば、他のRDBMSで使う時にも楽そうではありますよね。(--)のスペースが必須なのは注意するとして。。

mysql> \! cat sqlcomment.sql
SELECT
  /*
    foo
    bar
  */
  empno  -- Do not forget "white space" following "--"
 ,ename  #foobar
FROM
  emp
WHERE
  empno = 7900;
mysql> 
mysql> 
mysql> \. sqlcomment.sql
+-------+-------+
| empno | ename |
+-------+-------+
|  7900 | JAMES |
+-------+-------+
1 row in set (0.01 sec)

おあとがよろしいようで。。。。

一行コメント(--)の後に空白を置くか置かないかってとこまで気を使う必要があるみたいなので、MySQLへ乗り換えたり、MySQLでも実行できるSQL文やスクリプトを用意する場合には注意したい部分ですすねー。ハマりそうなきもするけどw（一行コメントの部分もケアされているSQLコーディング標準がああって厳格に管理されていれば問題ないと思いますけども）

参考）

・Oracle Database / Release 19 / SQL言語リファレンス / コメント
・PostgreSQL 13.1文書 / 第4章 SQLの構文 / 4.1.5. コメント
・MySQL 8.0 リファレンスマニュアル / 言語構造 / コメント

梅雨らしい雨の降る、ちがさき、、いや、東京よりw。
ではまた。

投稿日時 2024年7月 1日 (月) 12時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL | 固定リンク | 0 | コメント (0)

2024年6月29日 (土)

帰ってきた！標準はあるにはあるが癖の多いSQL #12 - 引用符にも癖がでるし、NULLのソート構文にも癖がある！（後編）ー列エイリアスの扱いにも癖がある！

Previously on Mac De Oracle
前回は、帰ってきた！標準はあるにはあるが癖の多いSQL #11 - 引用符にも癖がでるし、NULLのソート構文にも癖がある！（前編）でした、

引用符にも多少の方言が存在すること、NULLのソート方法にも同様に方言が存在することを確認しました。
今回はその後編です。

引用符で囲んだ識別子（列名、表名、列エイリアス、表エイリアス）を英語だと、Quoted Identifier と記載されシノニムはあまり見かけません。（SQL-1992などでは、delimited identifier と記されている程度ですかね）日本語のマニュアル等では翻訳影響だと思いますが、多少揺れていたりします。

Oraclerのみなさんだと、引用識別子　のほうが馴染み深い日本語訳だと思いますが、他のRDBMSの日本語マニュアルでは、引用符付き識別子　と記載されていたりします。とうのは前回にも書いてますが、Oracle Database/PostgreSQL/MySQLの間でも多少表現は違ったりします。

参考）
・Database Oracle / Release 19 / SQL言語リファレンス / データベース・オブジェクト名および修飾子 / データベース・オブジェクトのネーミング規則
・MySQL 8.0 リファレンスマニュアル / 言語構造 / スキーマオブジェクト名
・PostgreSQL 13.1文書 / 第4章 SQLの構文 / 4.1. 字句の構造

という前置きはこれぐらいで。本日のお題。列エイリアスの扱いの癖！

今日のお題は、列エイリアスの扱いの癖　を見てみます（気づかないと意外にハマりますよーーw）

今回も前回同様、お馴染みの、emp表を、Oracle Database 23ai/PostgreSQL 13.14/MySQL 8.0.36　それぞれに作成してあります。（以下はOracle Database）

SCOTT@localhost:1521/freepdb1> desc emp
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 EMPNO                                     NOT NULL NUMBER(4)
 ENAME                                              VARCHAR2(10)
 JOB                                                VARCHAR2(9)
 MGR                                                NUMBER(4)
 HIREDATE                                           DATE
 SAL                                                NUMBER(7,2)
 COMM                                               NUMBER(7,2)
 DEPTNO                                             NUMBER(2)

SCOTT@localhost:1521/freepdb1> select * from emp order by empno;

     EMPNO ENAME      JOB              MGR HIREDATE        SAL       COMM     DEPTNO
---------- ---------- --------- ---------- -------- ---------- ---------- ----------
      7369 SMITH      CLERK           7902 80-12-17        800                    20
      7499 ALLEN      SALESMAN        7698 81-02-20       1600        300         30
      7521 WARD       SALESMAN        7698 81-02-22       1250        500         30
      7566 JONES      MANAGER         7839 81-04-02       2975                    20
      7654 MARTIN     SALESMAN        7698 81-09-28       1250       1400         30
      7698 BLAKE      MANAGER         7839 81-05-01       2850                    30
      7782 CLARK      MANAGER         7839 81-06-09       2450                    10
      7788 SCOTT      ANALYST         7566 87-04-19       3000                    20
      7839 KING       PRESIDENT            81-11-17       5000                    10
      7844 TURNER     SALESMAN        7698 81-09-08       1500          0         30
      7876 ADAMS      CLERK           7788 87-05-23       1100                    20
      7900 JAMES      CLERK           7698 81-12-03        950                    30
      7902 FORD       ANALYST         7566 81-12-03       3000                    20
      7934 MILLER     CLERK           7782 82-01-23       1300                    10

14 rows selected.

では、前回のおさらいから、MySQLだけ癖が強い結果となりましたが、問い合わせたい結果はどれも正しいですよね！（標準はあるにはあるが、癖の多いSQLらしい。素晴らしい結果ですよねw）

Oracle Database 23ai

SCOTT@localhost:1521/freepdb1> set null [null]
SCOTT@localhost:1521/freepdb1> @quoted_identification.sql
  1  SELECT
  2    mgr AS "Boss's emp no."
  3  , COUNT(empno) AS head_counts
  4  FROM
  5    emp
  6  GROUP BY
  7    "Boss's emp no."
  8  ORDER BY
  9*   "Boss's emp no." NULLS FIRST

Boss's emp no. HEAD_COUNTS
-------------- -----------
[null]                   1
          7566           2
          7698           5
          7782           1
          7788           1
          7839           3
          7902           1

7 rows selected.

PostgreSQL 13.14

perftestdb=> \pset null [null]
Null表示は"[null]"です。
perftestdb=> \! cat quoted_identification.sql
SELECT
  mgr AS "Boss's emp no."
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  "Boss's emp no."
ORDER BY 
  "Boss's emp no." NULLS FIRST
;
perftestdb=> \i quoted_identification.sql
 Boss's emp no. | head_counts 
----------------+-------------
         [null] |           1
           7566 |           2
           7698 |           5
           7782 |           1
           7788 |           1
           7839 |           3
           7902 |           1
(7 行)

MySQL 8.0.36

mysql> \! cat quoted_identification.sql
SELECT
  mgr AS `Boss's emp no.`
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  `Boss's emp no.`
ORDER BY 
  `Boss's emp no.` IS NULL DESC
 ,`Boss's emp no.` ASC
;
mysql> 
mysql> \. quoted_identification.sql
+----------------+-------------+
| Boss's emp no. | head_counts |
+----------------+-------------+
|           NULL |           1 |
|           7566 |           2 |
|           7698 |           5 |
|           7782 |           1 |
|           7788 |           1 |
|           7839 |           3 |
|           7902 |           1 |
+----------------+-------------+
7 rows in set (0.01 sec)

今日は、上記のクエリー列エイリアスにちょっと意地の悪い変更を行なって、その挙動の違いを見てみたいと思います。（おもしろいよ、それぞれの個性が出てて）
オリジナルでは、mgr AS "Boss's emp no."　としていた列エイリアスですが、まずは、 mgr AS empno と、非識別引用子にして、かつ、emp表の列名である　empno と同じ名称にしてあります。。。 AS 列エイリアス　にはなっているので文法的には正しいです。。。よね。ちょっと嫌な予感はしますがw

(MySQLの場合、ORDER BY句の構文が異なります。以下、Oracle Database 23ai/PostgreSQL向け)

Before

SELECT
  mgr AS Boss's emp no."
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  "Boss's emp no."
ORDER BY 
  "Boss's emp no." NULLS FIRST;

After

SELECT
  mgr AS empno
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  empno
ORDER BY 
  empno NULLS FIRST;

では、早速、MySQLから実験してみましょう！

mysql> desc emp;
+----------+--------------+------+-----+---------+-------+
| Field    | Type         | Null | Key | Default | Extra |
+----------+--------------+------+-----+---------+-------+
| empno    | smallint     | NO   | PRI | NULL    |       |
| ename    | varchar(10)  | YES  |     | NULL    |       |
| job      | varchar(10)  | YES  |     | NULL    |       |
| mgr      | smallint     | YES  |     | NULL    |       |
| hiredate | date         | YES  |     | NULL    |       |
| sal      | decimal(7,2) | YES  |     | NULL    |       |
| comm     | decimal(7,2) | YES  |     | NULL    |       |
| deptno   | smallint     | YES  |     | NULL    |       |
+----------+--------------+------+-----+---------+-------+
8 rows in set (0.05 sec)

mysql> \! cat quoted_identification2.sql
SELECT
  mgr AS empno
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  empno
ORDER BY 
  empno IS NULL DESC
 ,empno ASC
;

おおおおおおおおおーーーーーーー。想定外の結果がががががー（いや、予想してましたよw）。

mysql> \. quoted_identification2.sql
+-------+-------------+
| empno | head_counts |
+-------+-------------+
|  NULL |           1 |
|  7566 |           1 |
|  7566 |           1 |
|  7698 |           1 |
|  7698 |           1 |
|  7698 |           1 |
|  7698 |           1 |
|  7698 |           1 |
|  7782 |           1 |
|  7788 |           1 |
|  7839 |           1 |
|  7839 |           1 |
|  7839 |           1 |
|  7902 |           1 |
+-------+-------------+
14 rows in set, 1 warning (0.02 sec)

ワーニングがでてますね。覗いてみると、どうやら、empno が曖昧だけど、実行しておいたから。。。。と。emp表のempnoと　mgr列に対する列エイリアス、どちらか曖昧だけど、とりあえず、emp表のempno列の方でやっといたでーーー。ということみたいですね。まじか。。。 AS 列エイリアス　とSQLで書いてるから列エイリアスとしてみてくれんの？？？（ちょっとわざとらしいセリフを入れてみましたw）

mysql> show warnings;
+---------+------+------------------------------------------------+
| Level   | Code | Message                                        |
+---------+------+------------------------------------------------+
| Warning | 1052 | Column 'empno' in group statement is ambiguous |
+---------+------+------------------------------------------------+
1 row in set (0.00 sec)

そうか、列エイリアスと表の列名が被ってて、曖昧だと。　では、　引用符を使って、これは、列エイリアスだーーーーーーとわかるように書けば良いのでは？？　　
ということで試してみる。

MySQLのデフォルトの引用符(`)バッククォートで囲った結果。。。だめだ。。。。引用識別子にしても、表の列側としてハンドリングされている。。。。。

mysql> \! cat quoted_identification2.sql
SELECT
  mgr AS `empno`
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  `empno`
ORDER BY 
  `empno` IS NULL DESC
 ,`empno` ASC
;
mysql> \. quoted_identification2.sql
+-------+-------------+
| empno | head_counts |
+-------+-------------+
|  NULL |           1 |
|  7566 |           1 |
|  7566 |           1 |
|  7698 |           1 |
|  7698 |           1 |
|  7698 |           1 |
|  7698 |           1 |
|  7698 |           1 |
|  7782 |           1 |
|  7788 |           1 |
|  7839 |           1 |
|  7839 |           1 |
|  7839 |           1 |
|  7902 |           1 |
+-------+-------------+
14 rows in set, 1 warning (0.00 sec)

mysql> show warnings;
+---------+------+------------------------------------------------+
| Level   | Code | Message                                        |
+---------+------+------------------------------------------------+
| Warning | 1052 | Column 'empno' in group statement is ambiguous |
+---------+------+------------------------------------------------+
1 row in set (0.00 sec)

mysql>

気を取り直して、PostgreSQL ではどうなのでしょう？

perftestdb=> \d+ emp
                                          テーブル"public.emp"
    列    |        タイプ         | 照合順序 | Null 値を許容 | デフォルト | ストレージ | 統計目標 | 説明 
----------+-----------------------+----------+---------------+------------+------------+----------+------
 empno    | numeric(4,0)          |          | not null      |            | main       |          | 
 ename    | character varying(10) |          |               |            | extended   |          | 
 job      | character varying(9)  |          |               |            | extended   |          | 
 mgr      | numeric(4,0)          |          |               |            | main       |          | 
 hiredate | date                  |          |               |            | plain      |          | 
 sal      | numeric(7,2)          |          |               |            | main       |          | 
 comm     | numeric(7,2)          |          |               |            | main       |          | 
 deptno   | numeric(2,0)          |          |               |            | main       |          | 
インデックス:
    "pk_emp" PRIMARY KEY, btree (empno)
    "ix_deptno" btree (deptno)
外部キー制約:
    "fk_deptno" FOREIGN KEY (deptno) REFERENCES dept(deptno)
アクセスメソッド: heap

perftestdb=> \! cat quoted_identification.sql
SELECT
  mgr AS empno
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  empno
ORDER BY 
  empno NULLS FIRST
;

ギョギョ！　サカナくんみたいな声がでますね！w MySQLと同じ挙動です！！！！　なーーーーーーーんーーーーーーだってーーーーーーーっ。　MySQLとは異なりワーニングもなく、結果が想定結果を違うんだーー。というところから列エイリアスが列エイリアスと認識されていないことに気づいてあげないとならないですね。。。これだと。　難易度が上がったw
MySQL、意外と親切かも。ワーニングで教えてくれるなんて。。。

perftestdb=> \pset null [null]
Null表示は"[null]"です。
perftestdb=> \i quoted_identification.sql
 empno  | head_counts 
--------+-------------
 [null] |           1
   7566 |           1
   7566 |           1
   7698 |           1
   7698 |           1
   7698 |           1
   7698 |           1
   7698 |           1
   7782 |           1
   7788 |           1
   7839 |           1
   7839 |           1
   7839 |           1
   7902 |           1
(14 行)

では、引用識別子に書き換えてみましょう。。。。。あ、まじで、PostgreSQLもMySQLと同じ挙動ですね。列エイリアスだよーーーーーと明示しても、表の列としてのハンドリングを優先しています。。。むむむ。

perftestdb=> \pset null [null]
Null表示は"[null]"です。
perftestdb=> \! cat quoted_identification2.sql
SELECT
  mgr AS "empno"
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  "empno"
ORDER BY 
  "empno" NULLS FIRST
;
perftestdb=> \i quoted_identification2.sql
 empno  | head_counts 
--------+-------------
 [null] |           1
   7566 |           1
   7566 |           1
   7698 |           1
   7698 |           1
   7698 |           1
   7698 |           1
   7698 |           1
   7782 |           1
   7788 |           1
   7839 |           1
   7839 |           1
   7839 |           1
   7902 |           1
(14 行)

perftestdb=>

では、ここまでくると、わかりますよね。　前回のエントリーで、MySQL　の立ち位置にいるのは、Oracle Database 23ai でーーーす。
なお、23aiからGROUP BYに列エイリアスが書けるようになってます。

結果を見てみましょうw

おおおおおーーーーーー。まじでーーーー。
MySQL/PostgreSQLと異なる挙動。列エイリアス（非引用識別子）と表の列名が被ってる影響で列エイリアスがエイリアスとして認識されていないためエラーとして扱っていますね。興味深い。いや、実はミスに気づきやすいのかも。。。

SCOTT@localhost:1521/freepdb1> set null [null]
SCOTT@localhost:1521/freepdb1> edit quoted_identification.sql

SCOTT@localhost:1521/freepdb1> @quoted_identification.sql
  1  SELECT
  2    mgr AS empno
  3  , COUNT(empno) AS head_counts
  4  FROM
  5    emp
  6  GROUP BY
  7    empno
  8  ORDER BY
  9*   empno NULLS FIRST
  mgr AS empno
  *
ERROR at line 2:
ORA-00979: "MGR": must appear in the GROUP BY clause or be used in an aggregate function
Help: https://docs.oracle.com/error-help/db/ora-00979/

非識別引用子のままだと、表の列名である、empno　と区別できない（AS empno と記載しても）ので、引用識別子にしてみます。PostgreSQL/Oracle Databaseの引用符は(")ダブルクォートですよね。

実行してみると。。。。。。あーーーーら不思議、MySQL/PostgreSQLとは異なり、引用識別子にしてあげることで、emp表のempno列とはことなる、列エイリアスと認識して、正しく処理しています。。。なんと。。。というか、この実装のほうが引用識別子の意味としては理解しやすくないですかね。。どうなんだろう。

SCOTT@localhost:1521/freepdb1> !cp quoted_identification.sql quoted_identification2.sql

SCOTT@localhost:1521/freepdb1> edit quoted_identification2.sql

SCOTT@localhost:1521/freepdb1> @quoted_identification2.sql
  1  SELECT
  2    mgr AS "empno"
  3  , COUNT(empno) AS head_counts
  4  FROM
  5    emp
  6  GROUP BY
  7    "empno"
  8  ORDER BY
  9*   "empno" NULLS FIRST

     empno HEAD_COUNTS
---------- -----------
[null]               1
      7566           2
      7698           5
      7782           1
      7788           1
      7839           3
      7902           1

7 rows selected.

Elapsed: 00:00:00.01
SCOTT@localhost:1521/freepdb1> set linesize 80
SCOTT@localhost:1521/freepdb1> desc emp
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 EMPNO                                     NOT NULL NUMBER(4)
 ENAME                                              VARCHAR2(10)
 JOB                                                VARCHAR2(9)
 MGR                                                NUMBER(4)
 HIREDATE                                           DATE
 SAL                                                NUMBER(7,2)
 COMM                                               NUMBER(7,2)
 DEPTNO                                             NUMBER(2)

SCOTT@localhost:1521/freepdb1>

引用識別子/非引用識別子が既存の列名と同じ場合の評価の仕方は皆バラバラですねw。思いっきり実装依存の部分なので、列、表名に対するエイリアスを指定する場合には注意しましょう。
（個人的な感覚でしかないですがw

Oracle Databaseの実装のほうが直感的には理解しやすいきがします）

MySQLの場合、PostgreSQL同様に実行されますが、面白い特徴は、ワーニングという形で、"Warning 1052 | Column 'empno' in group statement is ambiguous" を示してくれることですね。MySQLでは warningのカウントに注意!!!　忘れないようにしたいですね。重要なコメントが書かれてたりしますw

この3者の中で、もっとも問題に気づきにくいのは、PostgreSQLでしょうか。。。
挙動がMySQL側に似ているので、MySQLのようにちょっと曖昧だけど、実行だけしておいたよ！　的なワーニングでも返してくれると、
MySQLのように気づきやすくなるかもしれませんね。＞　各位

これだから、癖のあるSQLとの付き合いはやめられないwww

Enjoy SQL！　そして、癖！　もw

ではまた。

投稿日時 2024年6月29日 (土) 07時19分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Oracle Database 23c Free Developer Release | 固定リンク | 0 | コメント (0)

2024年6月23日 (日)

VirtualBox TestBuild 7.0.97r163606 (2024-06-21T11:55:16Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録

2024-06-21に最新のTestBuildが公開されていました。

恒例のOracle Database 21c on VirtualBox TestBuild for macOS/ARM64 の起動時間の記録です。

oracle@Mac-Studio ~ % ./print_env.sh
 
*** mac info. ***
ProductName:		macOS
ProductVersion:		14.5
BuildVersion:		23F79
 
*** maxOS ver. ***
      Model Name: Mac Studio
      Chip: Apple M1 Ultra
      Total Number of Cores: 20 (16 performance and 4 efficiency)
      Memory: 64 GB
 
*** VirtualBox ver. ***
7.0.97r163606

M1で停止時間が2桁秒台になったほか、起動時間も改善してますね！

起動1回目 : 130 sec
停止1回目 :  66 sec
起動2回目 : 145 sec
停止2回目 :  45 sec

oracle@angelfish ~ % ./print_env.sh

*** mac info. ***
      Model Name: MacBook Air
      Chip: Apple M2
      Total Number of Cores: 8 (4 performance and 4 efficiency)
      Memory: 24 GB

*** macOS ver. ***
ProductName:		macOS
ProductVersion:		14.5
BuildVersion:		23F79

*** VirtualBox ver. ***
7.0.97r163606

起動停止時間の記録をとり始めてから、M2でも最短記録ですね！！！！　

起動1回目 : 108 sec
停止1回目 :  34 sec
起動2回目 :  91 sec
停止2回目 :  49 sec

今回は、起動停止時間ともこれまでの最速値です。(^^) (^^) (^^)

次回のリリースが楽しみですね。。。

VMのOSバージョンなどは過去のエントリーを見ていただくとして、M1/M2 それぞれ以下のPostgreSQL/MySQL/Oracle Databaseが起動することを確認。

PostgreSQL

[master@localhost ~]$ sudo su - postgres -c 'psql -d perftestdb -U discus -p 5432 -W -h localhost -c "select version()"'

                                                 version                                                  
----------------------------------------------------------------------------------------------------------
 PostgreSQL 13.14 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20), 64-bit
(1 行)

MySQL

[master@localhost ~]$ mysql -u scott -D perftestdb -p -h localhost -e 'select version();'

+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+

Oracle Database 21c

[oracle@localhost ~]$ sqlplus / as sysdba @version

...略...

BANNER_FULL
----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0

Oracle Database 23ai

[oracle@localhost ~]$ sql hr/oracle@localhost:1521/freepdb1 @version

...略...

BANNER_FULL                                                                                             
________________________________________________________________________________
Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.4.0.24.05

VirtualBox Team　がんばれ〜〜〜〜〜 :)

では、次回の起動停止時間ログをお楽しみに:)

投稿日時 2024年6月23日 (日) 17時29分 Oracle, Mac, SQL, VirtualBox, MySQL, PostgreSQL, Oracle Database 21c, Oracle Database 23c Free Developer Release, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年6月22日 (土)

帰ってきた！標準はあるにはあるが癖の多いSQL #11 - 引用符にも癖がでるし、NULLのソート構文にも癖がある！（前編）

Oracle ACE Program的に新年度に切り替わり。今期もOracle ACE Proに認定されました。:)

前置きはそれぐらいにして、今日の本題。

column expressionのaliasや、 table, view, subqueryなどのaliasを指定する際に利用することがある引用符、通常は (")ダブルクォートで囲むわけですが、そんな引用符にも癖があるというお話。
SQL-1992のドラフトではありますが以下のドキュメントを delimited identifier で検索すると見つけることができます。
( (Second Informal Review Draft) ISO/IEC 9075:1992, Database Language SQL- July 30, 1992 )

ついでに、世間ではいろいろ言われて肩身の狭い？想いをしているかもしれない NULL. そのNULLのソートが必要になってしまった場合にも、ソートの構文に癖がある！！

ほんと、みんな、癖多すぎますよね！（w
いい感じに差し支えない単語にすると、個性　があるというか... これだからSQLは楽しいって話もありますけども。人によるかなw

Oracle Database 23ai / PostgreSQL 13.14 / MySQL 8.0.36 のそれぞれで、どうなるか見てみましょう。

それぞれのデータベースに以下のような emp表を事前に作成しておきます。Oraclerにはお馴染みの表です:)

SCOTT@localhost:1521/freepdb1> select * from emp order by empno;

     EMPNO ENAME      JOB              MGR HIREDATE        SAL       COMM     DEPTNO
---------- ---------- --------- ---------- -------- ---------- ---------- ----------
      7369 SMITH      CLERK           7902 80-12-17        800                    20
      7499 ALLEN      SALESMAN        7698 81-02-20       1600        300         30
      7521 WARD       SALESMAN        7698 81-02-22       1250        500         30
      7566 JONES      MANAGER         7839 81-04-02       2975                    20
      7654 MARTIN     SALESMAN        7698 81-09-28       1250       1400         30
      7698 BLAKE      MANAGER         7839 81-05-01       2850                    30
      7782 CLARK      MANAGER         7839 81-06-09       2450                    10
      7788 SCOTT      ANALYST         7566 87-04-19       3000                    20
      7839 KING       PRESIDENT            81-11-17       5000                    10
      7844 TURNER     SALESMAN        7698 81-09-08       1500          0         30
      7876 ADAMS      CLERK           7788 87-05-23       1100                    20
      7900 JAMES      CLERK           7698 81-12-03        950                    30
      7902 FORD       ANALYST         7566 81-12-03       3000                    20
      7934 MILLER     CLERK           7782 82-01-23       1300                    10

14 rows selected.

まず、Oracle Database 23ai
なぜ最新にしたかと言うと、GROUP BYで　alias が利用可能になった最初のリリースだからなのですw　（例で利用するクエリで利用する必要があるので）
（ GROUP BY列の別名または位置の指定が可能に！ / 23ai〜 / SQL / FAQ ）

SCOTT@localhost:1521/freepdb1> select banner_full from v$version;

BANNER_FULL
-------------------------------------------------------------------------------
Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.4.0.24.05

この例では、別名に空白などを含めているため引用符が必要になります。
Oracle Databaseの場合は昔から (") ダブルクォートですね。
一般的には引用符を必要としない記述にすることが多いのではないでしょうか。プログラムで扱うには面倒ですからね。（印字するだけの目的なら別ですが）
とはいえ、引用符の利用が必須のケースや、コーディング規約次第というところはあります。
SQL言語リファレンス/ データベース・オブジェクト名および修飾子/ データベース・オブジェクトのネーミング規則

NULLの位置が最初に来るようにソートするには、NULLS FIRSTですよね。みなさんもご存知のはず。

Oraclerのみなさんには GROUP BY でいきなりaliasを使う構文で目新しいですよね。すっきり書けるようになって嬉しい:)

SCOTT@localhost:1521/freepdb1> set null [null]
SCOTT@localhost:1521/freepdb1> @quoted_identification.sql
  1  SELECT
  2    mgr AS "Boss's emp no."
  3  , COUNT(empno) AS head_counts
  4  FROM
  5    emp
  6  GROUP BY
  7    "Boss's emp no."
  8  ORDER BY
  9*   "Boss's emp no." NULLS FIRST

Boss's emp no. HEAD_COUNTS
-------------- -----------
[null]                   1
          7566           2
          7698           5
          7782           1
          7788           1
          7839           3
          7902           1

7 rows selected.

次は、PostgreSQL　
Oracle Database同様、引用符が必要な別名は、ダブルクォートを利用します。( PostgreSQL 16.0 / 4.1.1. 識別子とキーワード )

NULLS FIRSTでNULLをいい感じにソートする方法も同じですね。

perftestdb=> select version();
                                                 version                                                  
----------------------------------------------------------------------------------------------------------
 PostgreSQL 13.14 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20), 64-bit
(1 行)

perftestdb=> 
perftestdb=> \pset null [null]
Null表示は"[null]"です。
perftestdb=> \! cat quoted_identification.sql
SELECT
  mgr AS "Boss's emp no."
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  "Boss's emp no."
ORDER BY 
  "Boss's emp no." NULLS FIRST;
;
perftestdb=> \i quoted_identification.sql
 Boss's emp no. | head_counts 
----------------+-------------
         [null] |           1
           7566 |           2
           7698 |           5
           7782 |           1
           7788 |           1
           7839 |           3
           7902 |           1
(7 行)

さて、最後は、MySQLです。

気付いたかと思いますが、本日の癖の主役ですw

MySQLのデフォルトの引用符は、なんと、(`) バッククォートです。手癖で、ダブルクォートをタイプして、え！と一瞬固まる、Oraclerが。。＞　俺だよw
( MySQL 8.0 リファレンスマニュアル / 言語構造 / スキーマオブジェクト名 )

また、NULLのソートも可能ですが、見たこともない構文でソートします。私まだよくわかってないですが、これで良いらしい。この癖に慣れる必要もありそう。。

+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+
1 row in set (0.00 sec)

mysql> \! cat quoted_identification.sql
SELECT
  mgr AS `Boss's emp no.`
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  `Boss's emp no.`
ORDER BY 
  `Boss's emp no.` IS NULL DESC
 ,`Boss's emp no.` ASC
;
mysql> 
mysql> \. quoted_identification.sql
+----------------+-------------+
| Boss's emp no. | head_counts |
+----------------+-------------+
|           NULL |           1 |
|           7566 |           2 |
|           7698 |           5 |
|           7782 |           1 |
|           7788 |           1 |
|           7839 |           3 |
|           7902 |           1 |
+----------------+-------------+
7 rows in set (0.01 sec)

ところで、MySQLでも、(")ダブルクォートを引用符にすることができます。
( MySQL 8.0 リファレンスマニュアル / 5.1.11 サーバー SQL モード / ANSI_QUOTES 参照のこと )

sql_modeに ANSI_QUOTESを設定することで使えるようになります。。。。あ〜っ、スッキリ。NULLのソート構文以外はw

mysql> select @@sql_mode;
+-----------------------------------------------------------------------------------------------------------------------+
| @@sql_mode                                                                                                            |
+-----------------------------------------------------------------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+-----------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> set session sql_mode = concat(@@sql_mode,',ANSI_QUOTES');
Query OK, 0 rows affected (0.01 sec)

mysql> select @@sql_mode;
+-----------------------------------------------------------------------------------------------------------------------------------+
| @@sql_mode                                                                                                                        |
+-----------------------------------------------------------------------------------------------------------------------------------+
| ANSI_QUOTES,ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+-----------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> \! cat quoted_identification.sql
SELECT
  mgr AS "Boss's emp no."
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  "Boss's emp no."
ORDER BY 
  "Boss's emp no." IS NULL DESC
 ,"Boss's emp no." ASC
;
mysql> \. quoted_identification.sql
+----------------+-------------+
| Boss's emp no. | head_counts |
+----------------+-------------+
|           NULL |           1 |
|           7566 |           2 |
|           7698 |           5 |
|           7782 |           1 |
|           7788 |           1 |
|           7839 |           3 |
|           7902 |           1 |
+----------------+-------------+
7 rows in set (0.00 sec)

mysql>

ANSI_QUOTESを無効にすると、GROUP BY で指定した alias 無効となり、デフォルトで有効化されているONLY_FULL_GROUP_BYのため、ERROR 1055　となります。なんとなく理解した！

mysql> select @@sql_mode;
+-----------------------------------------------------------------------------------------------------------------------------------+
| @@sql_mode                                                                                                                        |
+-----------------------------------------------------------------------------------------------------------------------------------+
| ANSI_QUOTES,ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+-----------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

mysql> set session sql_mode = replace(@@sql_mode,'ANSI_QUOTES,','');
Query OK, 0 rows affected (0.00 sec)

mysql> select @@sql_mode;
+-----------------------------------------------------------------------------------------------------------------------+
| @@sql_mode                                                                                                            |
+-----------------------------------------------------------------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+-----------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> \! cat quoted_identification.sql
SELECT
  mgr AS "Boss's emp no."
, COUNT(empno) AS head_counts
FROM
  emp
GROUP BY
  "Boss's emp no."
ORDER BY 
  "Boss's emp no." IS NULL DESC
 ,"Boss's emp no." ASC
;
mysql> \. quoted_identification.sql
ERROR 1055 (42000): Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'perftestdb.emp.mgr' which is not functionally dependent on columns in GROUP BY clause; this is incompatible
 with sql_mode=only_full_group_by

そういえば、
英語だと、大抵は、quoted identifier と書かれていますが、日本語表記だと引用符付き識別子とか、引用識別子、各社のドキュメントで微妙に違いがあったりして難しいなぁ。と思ったり。
quoted identifier　ってカタカタにしたら長くてタイプするの面倒、結局、Oraclerなので、引用識別子/非引用識別子　で通りしゃったりしますけど。

ではでは。
次回へつづく。

投稿日時 2024年6月22日 (土) 11時56分 Oracle, FAQ, SQL, MySQL, PostgreSQL, NULL, Oracle Database 23c Free Developer Release | 固定リンク | 0 | コメント (0)

2024年6月15日 (土)

VirtualBox TestBuild 7.0.97r163425 (2024-06-05T13:13:46Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録

さて、恒例のOracle Database 21c on VirtualBox TestBuild for macOS/ARM64 の起動時間の記録です。
2024-06-05T13:13:46Zに公開されていた。起動自体は非常に安定してきましたね。細かいところは色々あるようですが、正式リリースが待ち遠しい。

oracle@Mac-Studio ~ % ./print_env.sh 
 
*** mac info. ***
ProductName:		macOS
ProductVersion:		14.5
BuildVersion:		23F79
 
*** maxOS ver. ***
      Model Name: Mac Studio
      Chip: Apple M1 Ultra
      Total Number of Cores: 20 (16 performance and 4 efficiency)
      Memory: 64 GB
 
*** VirtualBox ver. ***
7.0.97r163425

Oracle Database 21c / Mac Studio M1
微妙な差なので変化なしという感じですね。

起動1回目 : 202 sec
停止1回目 :  86 sec
起動2回目 : 163 sec
停止2回目 : 143 sec

oracle@angelfish ~ % ./print_env.sh

*** mac info. ***
      Model Name: MacBook Air
      Chip: Apple M2
      Total Number of Cores: 8 (4 performance and 4 efficiency)
      Memory: 24 GB

*** macOS ver. ***
ProductName:		macOS
ProductVersion:		14.5
BuildVersion:		23F79

*** VirtualBox ver. ***
7.0.97r163425

Oracle Database 21c / MacBook Air M2
若干、前回公開されたTestBuildより遅くなってる気がしますよね。（たった二回しか起動停止させてないので、参考記録程度なわけですけども）

起動1回目 : 244 sec
停止1回目 : 136 sec    
起動2回目 : 201 sec
停止2回目 : 101 sec

その他、いつもの起動確認。
PostgreSQL 13.14 / MySQL 8.0.36 / Oracle Database 21c　及び、 23ai (M1/M2それぞれ起動)
GuestOSのバージョンなどはこれまでと同じなので省略して、それぞれのバージョン確認ログで起動確認。

[master@localhost ~]$ mysql -u scott -D perftestdb -p -h localhost -e 'select version();'
Enter password: 
+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+

[master@localhost ~]$ sudo su - postgres -c 'psql -d perftestdb -U discus -p 5432 -W -h localhost -c "select version()"'
パスワード： 
                                                 version                                                  
----------------------------------------------------------------------------------------------------------
 PostgreSQL 13.14 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20), 64-bit
(1 行)

[oracle@localhost ~]$ sqlplus scott@orclpdb1 @version

...略...

BANNER_FULL
-----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0


[oracle@localhost ~]$ sql hr@192.168.1.138:1521/freepdb1 @version

...略...

BANNER_FULL                                                                                             
________________________________________________________________________________
Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.4.0.24.05

[oracle@localhost ~]$ cat version.sql
select banner_full from v$version;
exit

これ、ルーティーンになりそうw

ではまた。

投稿日時 2024年6月15日 (土) 19時20分 Oracle, Mac, VirtualBox, MySQL, PostgreSQL, Oracle Database 21c, Oracle Database 23c Free Developer Release, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年5月31日 (金)

VirtualBox TestBuild 7.0.97r163376 (2024-05-28T15:08:56Z) for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録

VirtualBox TestBuild 7.0.97r163376 (2024-05-28T15:08:56Z) / macOS/ARM64 Dev Previewがリリースされていたので、いつもの、起動確認と、Oracle Database 21cの起動時間比較を。
前回の記録は、VirtualBox TestBuild for macOS/ARM64における現時点でのOracle Database 21cの起動、停止時間の記録 / 7.0.97r162957(2024/4/26) / 7.0.97r163029(2024/5/3)を見てもらうとして、結果的には大きくな変化なし！。

頑張って！ :)　

oracle@Mac-Studio ~ % ./print_env.sh 
 
*** mac info. ***
ProductName:		macOS
ProductVersion:		14.5
BuildVersion:		23F79
 
*** maxOS ver. ***
      Model Name: Mac Studio
      Chip: Apple M1 Ultra
      Total Number of Cores: 20 (16 performance and 4 efficiency)
      Memory: 64 GB
 
*** VirtualBox ver. ***
7.0.97r163376

Oracle Database 21c Mac Studio M1

起動1回目 : 217sec
停止1回目 : 153sec
起動2回目 : 186sec
停止2回目 : 119sec

oracle@angelfish ~ % ./print_env.sh 

*** mac info. ***
      Model Name: MacBook Air
      Chip: Apple M2
      Total Number of Cores: 8 (4 performance and 4 efficiency)
      Memory: 24 GB

*** macOS ver. ***
ProductName:		macOS
ProductVersion:		14.5
BuildVersion:		23F79

*** VirtualBox ver. ***
7.0.97r163376

Oracle Database 21c MacBook Air M2

起動1回目 : 138sec
停止1回目 : 108sec
起動2回目 : 128sec
停止2回目 :  83sec

その他、いつもの起動確認。
PostgreSQL 13.14 / MySQL 8.0.36 / Oracle Database 21c　及び、 23ai 、それぞれ、VirtualBox TestBuild 7.0.97r163376 （024-05-28T15:08:56Z）でも起動した！　（このあたりはマジで安定してきた）

oracle@Mac-Studio ~ % ./print_env.sh 
 
*** mac info. ***
ProductName:		macOS
ProductVersion:		14.5
BuildVersion:		23F79
 
*** maxOS ver. ***
      Model Name: Mac Studio
      Chip: Apple M1 Ultra
      Total Number of Cores: 20 (16 performance and 4 efficiency)
      Memory: 64 GB
 
*** VirtualBox ver. ***
7.0.97r163376

[master@localhost ~]$ cat /etc/*release*
Oracle Linux Server release 8.5
NAME="Oracle Linux Server"
VERSION="8.5"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="8.5"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Oracle Linux Server 8.5"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:8:5:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://bugzilla.oracle.com/"

ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"
ORACLE_BUGZILLA_PRODUCT_VERSION=8.5
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=8.5
Red Hat Enterprise Linux release 8.5 (Ootpa)
Oracle Linux Server release 8.5
cpe:/o:oracle:linux:8:5:server
[master@localhost ~]$

PostgreSQL 13.14 - 起動した！

[master@localhost ~]$ sudo su - postgres
[postgres@localhost ~]$ psql -d perftestdb -U discus -p 5432 -W -h localhost
パスワード： 
psql (13.14)
"help"でヘルプを表示します。

perftestdb=> select version();
                                                 version                                                  
----------------------------------------------------------------------------------------------------------
 PostgreSQL 13.14 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20), 64-bit
(1 行)

perftestdb=> exit

MySQL 8.0.36 - 起動した！

[master@localhost ~]$ mysql -u scott -D perftestdb -p -h 192.168.1.125
Enter password: 
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 8.0.36 Source distribution

Copyright (c) 2000, 2024, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+
1 row in set (0.01 sec)

mysql> exit
Bye

Oracle Database 21c - 起動した！

[oracle@localhost ~]$ cat /etc/*release*
Oracle Linux Server release 8.4
NAME="Oracle Linux Server"
VERSION="8.4"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="8.4"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Oracle Linux Server 8.4"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:8:4:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://bugzilla.oracle.com/"

ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"
ORACLE_BUGZILLA_PRODUCT_VERSION=8.4
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=8.4
Red Hat Enterprise Linux release 8.4 (Ootpa)
Oracle Linux Server release 8.4
cpe:/o:oracle:linux:8:4:server
[oracle@localhost ~]$ 
[oracle@localhost ~]$ sqlplus / as sysdba

SYS@ORCLCDB> select banner_full from v$version;

BANNER_FULL
-----------------------------------------------------------------------
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0

SYS@ORCLCDB> exit

Oracle Database 23ai - 起動した！

[oracle@localhost ~]$ cat /etc/*release*
Oracle Linux Server release 8.9
NAME="Oracle Linux Server"
VERSION="8.9"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="8.9"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Oracle Linux Server 8.9"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:8:9:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://github.com/oracle/oracle-linux"

ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"
ORACLE_BUGZILLA_PRODUCT_VERSION=8.9
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=8.9
Red Hat Enterprise Linux release 8.9 (Ootpa)
Oracle Linux Server release 8.9
cpe:/o:oracle:linux:8:9:server
[oracle@localhost ~]$ sql scott/@192.168.1.138:1521/freepdb1


SQL> select banner_full from v$version;

BANNER_FULL                                                                                             
_______________________________________________________________________________
Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.4.0.24.05    

SQL>

これが、本当の5月最後の投稿ということでw

では、また。

投稿日時 2024年5月31日 (金) 13時00分 Oracle, Mac, VirtualBox, MySQL, PostgreSQL, Oracle Database 21c, Oracle Database 23c Free Developer Release, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年5月29日 (水)

帰ってきた！標準はあるにはあるが癖の多いSQL #10、BOOLEAN型にも癖が出る（後編）

Previously on Mac De Oracle
前回は、BOOLEAN型に使える値の差異について、Oracle Database 23ai/PostgreSQL/MySQLで比較してみました。なかなか癖がありますよね。それぞれw Oracle Database 23aiは、Db2やSnowflakeの仕様に類似していそうでしたよね。（未検証ですが）
ということで、5月もラストスパートwで、BOOLEANネタ後編で締めたいと思いますw

BOOLEAN/BOOL型どちらでもOKということなので、一応確認しておきます。

Oracle Database

SCOTT@freepdb1> create table sample3 (b1 boolean, b2 bool);

Table created.

SCOTT@freepdb1> desc sample3
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 B1                                                 BOOLEAN
 B2                                                 BOOLEAN
 
SCOTT@freepdb1> drop table sample3 purge;Table dropped.

PostgreSQL

perftestdb=> create table sample3 (b1 boolean, b2 bool);
CREATE TABLE
perftestdb=> \d sample3
               テーブル"public.sample3"
 列 | タイプ  | 照合順序 | Null 値を許容 | デフォルト 
----+---------+----------+---------------+------------
 b1 | boolean |          |               | 
 b2 | boolean |          |               | 

perftestdb=> drop table sample3;
DROP TABLE
perftestdb=>

MySQL

mysql> create table sample3 (b1 boolean, b2 bool);
Query OK, 0 rows affected (0.27 sec)

mysql> desc sample3;
+-------+------------+------+-----+---------+-------+
| Field | Type       | Null | Key | Default | Extra |
+-------+------------+------+-----+---------+-------+
| b1    | tinyint(1) | YES  |     | NULL    |       |
| b2    | tinyint(1) | YES  |     | NULL    |       |
+-------+------------+------+-----+---------+-------+
2 rows in set (0.04 sec)

mysql> drop table sample3;
Query OK, 0 rows affected (0.10 sec)

次は、データサイズ。
MySQL/PostgreSQLそれぞれマニュアルにて、1バイトと記載されていますが、Oracle Databaseでは発見できす（仕方ないので直接確認してみますw）
PostgreSQL - https://www.postgresql.jp/document/13/html/datatype-boolean.html MySQL BOOLEAN = TINYINT - https://dev.mysql.com/doc/refman/8.0/ja/other-vendor-data-types.html MySQL TINYINTのサイズ - https://dev.mysql.com/doc/refman/8.0/ja/integer-types.html

Oracleも1バイトのようですね！

SCOTT@freepdb1> set null [null]
SCOTT@freepdb1> col dump(b1) for a30
SCOTT@freepdb1> col vsize(b1) for 9990
SCOTT@freepdb1> select dump(b1),vsize(b1) from example2

DUMP(B1)                       VSIZE(B1)
------------------------------ ---------
Typ=252 Len=1: 1                       1
Typ=252 Len=1: 1                       1
Typ=252 Len=1: 1                       1
Typ=252 Len=1: 1                       1

...中略...

Typ=252 Len=1: 0                       1
Typ=252 Len=1: 0                       1
Typ=252 Len=1: 0                       1
Typ=252 Len=1: 0                       1
NULL                           [null]

33 rows selected.

BOOLEAN型を文字、数値へキャストするとどうなるでしょう？

Oracle Database BOOLEAN型の数値へのキャストは、1 (true) / 0 (false)、文字列へのキャストは、'TRUE' / 'FALSE' になるようですね。CHAR型へのキャストの場合、空白埋めされるようですね（マニュアルより）。

SCOTT@freepdb1> select id,b1,to_number(b1),memo from example2 order by id;

        ID B1          TO_NUMBER(B1) MEMO
---------- ----------- ------------- ----------
         1 TRUE                    1 TRUE
         2 TRUE                    1 true
         3 TRUE                    1 True
         4 TRUE                    1 ON
         5 TRUE                    1 on
         6 TRUE                    1 On
         7 TRUE                    1 YES
         8 TRUE                    1 yes
         9 TRUE                    1 Yes
        10 TRUE                    1 T
        11 TRUE                    1 t
        12 TRUE                    1 Y
        13 TRUE                    1 y
        14 TRUE                    1 1
        15 TRUE                    1 0.01
        16 TRUE                    1 -0.01
        17 TRUE                    1 10
        18 TRUE                    1 -12
        19 FALSE                   0 FALSE
        20 FALSE                   0 false
        21 FALSE                   0 False
        22 FALSE                   0 OFF
        23 FALSE                   0 off
        24 FALSE                   0 Off
        25 FALSE                   0 NO
        26 FALSE                   0 no
        27 FALSE                   0 No
        28 FALSE                   0 F
        29 FALSE                   0 f
        30 FALSE                   0 N
        31 FALSE                   0 n
        32 FALSE                   0 0
        33 [null]      [null]        null

33 rows selected.

SCOTT@freepdb1> select id,b1,to_char(b1),memo from example2 order by id;

        ID B1          TO_CHA MEMO
---------- ----------- ------ ----------
         1 TRUE        TRUE   TRUE
         2 TRUE        TRUE   true
         3 TRUE        TRUE   True
         4 TRUE        TRUE   ON
         5 TRUE        TRUE   on
         6 TRUE        TRUE   On
         7 TRUE        TRUE   YES
         8 TRUE        TRUE   yes
         9 TRUE        TRUE   Yes
        10 TRUE        TRUE   T
        11 TRUE        TRUE   t
        12 TRUE        TRUE   Y
        13 TRUE        TRUE   y
        14 TRUE        TRUE   1
        15 TRUE        TRUE   0.01
        16 TRUE        TRUE   -0.01
        17 TRUE        TRUE   10
        18 TRUE        TRUE   -12
        19 FALSE       FALSE  FALSE
        20 FALSE       FALSE  false
        21 FALSE       FALSE  False
        22 FALSE       FALSE  OFF
        23 FALSE       FALSE  off
        24 FALSE       FALSE  Off
        25 FALSE       FALSE  NO
        26 FALSE       FALSE  no
        27 FALSE       FALSE  No
        28 FALSE       FALSE  F
        29 FALSE       FALSE  f
        30 FALSE       FALSE  N
        31 FALSE       FALSE  n
        32 FALSE       FALSE  0
        33 [null]      [null] null

33 rows selected.

PostgreSQL PostgreSQLは想定の範囲内ですね。'true'/'false', 1/0 になるようですね

perftestdb=> \pset null [null]
Null表示は"[null]"です。
perftestdb=> 
perftestdb=> select id,b1,b1::varchar,memo from example2 order by id;
 id |   b1   |   b1   | memo  
----+--------+--------+-------
  1 | t      | true   | TRUE
  2 | t      | true   | true
  3 | t      | true   | True
  4 | t      | true   | ON
  5 | t      | true   | on
  6 | t      | true   | On
  7 | t      | true   | YES
  8 | t      | true   | yes
  9 | t      | true   | Yes
 10 | t      | true   | T
 11 | t      | true   | t
 12 | t      | true   | Y
 13 | t      | true   | y
 14 | t      | true   | 1
 17 | t      | true   | 10
 19 | f      | false  | FALSE
 20 | f      | false  | false
 21 | f      | false  | False
 22 | f      | false  | OFF
 23 | f      | false  | off
 24 | f      | false  | Off
 25 | f      | false  | NO
 26 | f      | false  | no
 27 | f      | false  | No
 28 | f      | false  | F
 29 | f      | false  | f
 30 | f      | false  | N
 31 | f      | false  | n
 32 | f      | false  | 0
 33 | [null] | [null] | null
(30 行)

perftestdb=> select id,b1,b1::integer,memo from example2 order by id;
 id |   b1   |   b1   | memo  
----+--------+--------+-------
  1 | t      |      1 | TRUE
  2 | t      |      1 | true
  3 | t      |      1 | True
  4 | t      |      1 | ON
  5 | t      |      1 | on
  6 | t      |      1 | On
  7 | t      |      1 | YES
  8 | t      |      1 | yes
  9 | t      |      1 | Yes
 10 | t      |      1 | T
 11 | t      |      1 | t
 12 | t      |      1 | Y
 13 | t      |      1 | y
 14 | t      |      1 | 1
 17 | t      |      1 | 10
 19 | f      |      0 | FALSE
 20 | f      |      0 | false
 21 | f      |      0 | False
 22 | f      |      0 | OFF
 23 | f      |      0 | off
 24 | f      |      0 | Off
 25 | f      |      0 | NO
 26 | f      |      0 | no
 27 | f      |      0 | No
 28 | f      |      0 | F
 29 | f      |      0 | f
 30 | f      |      0 | N
 31 | f      |      0 | n
 32 | f      |      0 | 0
 33 | [null] | [null] | null
(30 行)

MySQL TINYINTのまま文字列に変換されちゃいますね。これはこれで癖が強いといえば強い

mysql> select id,b1,cast(b1 as char),memo from example2 order by id;
+----+------+------------------+-------+
| id | b1   | cast(b1 as char) | memo  |
+----+------+------------------+-------+
|  1 |    1 | 1                | TRUE  |
|  2 |    1 | 1                | true  |
|  3 |    1 | 1                | True  |
| 14 |    1 | 1                | 1     |
| 15 |    0 | 0                | 0.01  |
| 16 |    0 | 0                | -0.01 |
| 19 |    0 | 0                | FALSE |
| 20 |    0 | 0                | false |
| 21 |    0 | 0                | False |
| 32 |    0 | 0                | 0     |
| 33 | NULL | NULL             | null  |
+----+------+------------------+-------+

Boolean型は索引にも利用できるので、念の為、Boolean型の検索でリテラルとして使える記述がどう評価されるか確認しておきましょうね。
暗黙のキャストやらなんやらあるのかないのか。。。索引に含めた場合、キャストされて索引として利用できないないケースなど把握しておくと便利ですよー。:)

Oracle Database 23ai Oracleの場合、簡易な方法として、SQL*Plusのオートトレースを利用し、 Predicate Information（述語情報）を見て filterの際に、関数が適用され内部的にキャストされてしまうかどうかで判断していくことにします。
ついでに、boolean列に非ユニーク索引（単一列索引）を作成しておき、索引が利用されることも見ておきます。

全てのケースは実施していませんが、大文字小文字は無視される前提で、小文字で検証しています。
TRUEとして解釈されるリテラル値 (文字列は大文字小文字は無視される。数値は、0以外の数値は全て、TRUEと解釈される。e.g. -1,10,0.1,-1.5 など) TRUE. 'ON', 'YES', 'T', 'Y', 1, 0以外の数値

FALSEとして解釈されるリテラル値 (文字列は大文字小文字は無視される。数値は、0のみFALSEと解釈される) FALSE, 'OFF', 'NO', 'F', 'N', 0

以上が、OracleのBOOELAN型で利用できるリテラル値なので、

true, 'on', 'yes', 't', 'y', 1, 0以外の数値(10, 0.1, -2, -0.1)、全てにおいて、内部的にTRUEとしてハンドリングされていることがわかります。
（キャストされているわけではなく、TRUEとして評価されていることが、predicate information及び、index only scanになっているところでも判断できます）

ますます、　true/false, nullだけ使えばいいじゃんって感じがしますね。

以下、検証ログ

SCOTT@freepdb1> create index ix_bool_example2 on example2(b1);

Index created.

SCOTT@freepdb1> select b1 from example2 where b1 = true;

18 rows selected.

...中略...

-------------------------------------------------------------------------------------
| Id  | Operation        | Name             | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                  |    16 |    16 |     1   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| IX_BOOL_EXAMPLE2 |    16 |    16 |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("B1"=TRUE)

Statistics
----------------------------------------------------------
          7  recursive calls
          4  db block gets

...中略...

         18  rows processed

SCOTT@freepdb1> select b1 from example2 where b1 = 't';

18 rows selected.

...中略...

-------------------------------------------------------------------------------------
| Id  | Operation        | Name             | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                  |    16 |    16 |     1   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| IX_BOOL_EXAMPLE2 |    16 |    16 |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("B1"=TRUE)

Statistics
----------------------------------------------------------
          1  recursive calls
...中略...

         18  rows processed

SCOTT@freepdb1> select b1 from example2 where b1 = 'y';

18 rows selected.

...中略...

-------------------------------------------------------------------------------------
| Id  | Operation        | Name             | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                  |    16 |    16 |     1   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| IX_BOOL_EXAMPLE2 |    16 |    16 |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("B1"=TRUE)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets

...中略...

         18  rows processed

SCOTT@freepdb1> select b1 from example2 where b1 = 'yes';

18 rows selected.

...中略...

-------------------------------------------------------------------------------------
| Id  | Operation        | Name             | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                  |    16 |    16 |     1   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| IX_BOOL_EXAMPLE2 |    16 |    16 |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("B1"=TRUE)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets

...中略...

         18  rows processed

SCOTT@freepdb1> select b1 from example2 where b1 = 'on';

18 rows selected.

...中略...

-------------------------------------------------------------------------------------
| Id  | Operation        | Name             | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                  |    16 |    16 |     1   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| IX_BOOL_EXAMPLE2 |    16 |    16 |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("B1"=TRUE)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets

...中略...

         18  rows processed

SCOTT@freepdb1> select b1 from example2 where b1 = 1;

18 rows selected.

...中略...

-------------------------------------------------------------------------------------
| Id  | Operation        | Name             | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                  |    16 |    16 |     1   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| IX_BOOL_EXAMPLE2 |    16 |    16 |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("B1"=TRUE)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets

...中略...

         18  rows processed

SCOTT@freepdb1> select b1 from example2 where b1 = 10;

18 rows selected.

...中略...

-------------------------------------------------------------------------------------
| Id  | Operation        | Name             | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                  |    16 |    16 |     1   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| IX_BOOL_EXAMPLE2 |    16 |    16 |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("B1"=TRUE)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets

...中略...

         18  rows processed

SCOTT@freepdb1> select b1 from example2 where b1 = 0.1;

18 rows selected.

...中略...

-------------------------------------------------------------------------------------
| Id  | Operation        | Name             | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                  |    16 |    16 |     1   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| IX_BOOL_EXAMPLE2 |    16 |    16 |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("B1"=TRUE)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets

...中略...

         18  rows processed

05:53:05 SCOTT@192.168.1.23:1521/freepdb1> select b1 from example2 where b1 = -2;

18 rows selected.

...中略...

-------------------------------------------------------------------------------------
| Id  | Operation        | Name             | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                  |    16 |    16 |     1   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| IX_BOOL_EXAMPLE2 |    16 |    16 |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - access("B1"=TRUE)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets

...中略...

         18  rows processed

SCOTT@freepdb1> select b1 from example2 where b1 = -0.1;

18 rows selected.

...中略...

-------------------------------------------------------------------------------------
| Id  | Operation        | Name             | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                  |    16 |    16 |     1   (0)| 00:00:01 |
|*  1 |  INDEX RANGE SCAN| IX_BOOL_EXAMPLE2 |    16 |    16 |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

  1 - access("B1"=TRUE)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets

...中略...

         18  rows processed

PostgreSQL

TRUEとして解釈されるリテラル値 (文字列は大文字小文字は無視される。数値は、正の整数のみTRUEと解釈され、負の整数や少数はエラーとなる。　-1, 0.1, -1.5などはエラー) TRUE. 'ON', 'YES', 'T', 'Y', 1, 0以外の正の整数のみ（ただし、booleanへのキャストが必要）

FALSEとして解釈されるリテラル値 (文字列は大文字小文字は無視される。数値は、0のみFALSEと解釈される) FALSE, 'OFF', 'NO', 'F', 'N', 0

true, 'on', 'yes', 't', 'y', 1, 0以外の正の整数のみ（ただし、booleanへのキャスト必須）(10) 全てにおいて、内部的にTRUEとしてハンドリングされていることがわかります。
（キャストされているわけではなく、Index Cond:及び、、hintで矯正していますが、Index Scan uging..になっているところでも判断できます）

0以外の正の整数以外(0.1, -2, -0.1)は、エラーになっていることが確認できます。

perftestdb=> create index ix_bool_example2 on example2(b1);
CREATE INDEX
perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where b1 = true;
                                                             QUERY PLAN                                                             
------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using ix_bool_example2 on public.example2  (cost=0.14..8.40 rows=15 width=1) (actual time=0.093..0.098 rows=15 loops=1)
   Output: b1
   Index Cond: (example2.b1 = true)
 Planning Time: 13.020 ms
 Execution Time: 8.653 ms
(5 行)
perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where b1 = 'on';
                                                             QUERY PLAN                                                             
------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using ix_bool_example2 on public.example2  (cost=0.14..8.40 rows=15 width=1) (actual time=0.038..0.046 rows=15 loops=1)
   Output: b1
   Index Cond: (example2.b1 = true)
 Planning Time: 0.259 ms
 Execution Time: 0.142 ms
(5 行)

perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where b1 = 'yes';
                                                             QUERY PLAN                                                             
------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using ix_bool_example2 on public.example2  (cost=0.14..8.40 rows=15 width=1) (actual time=0.021..0.026 rows=15 loops=1)
   Output: b1
   Index Cond: (example2.b1 = true)
 Planning Time: 0.168 ms
 Execution Time: 0.087 ms
(5 行)

perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where b1 = 't';
                                                             QUERY PLAN                                                             
------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using ix_bool_example2 on public.example2  (cost=0.14..8.40 rows=15 width=1) (actual time=0.022..0.030 rows=15 loops=1)
   Output: b1
   Index Cond: (example2.b1 = true)
 Planning Time: 0.173 ms
 Execution Time: 0.117 ms
(5 行)

perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where b1 = 'y';
                                                             QUERY PLAN                                                             
------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using ix_bool_example2 on public.example2  (cost=0.14..8.40 rows=15 width=1) (actual time=0.017..0.021 rows=15 loops=1)
   Output: b1
   Index Cond: (example2.b1 = true)
 Planning Time: 0.119 ms
 Execution Time: 0.066 ms
(5 行)

perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where b1 = 1;
ERROR:  operator does not exist: boolean = integer
行 1: ...example2 ix_bool_example2) */ b1 from example2 where b1 = 1;
                                                                 ^
HINT:  No operator matches the given name and argument types. You might need to add explicit type casts.
perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where b1 = 1::boolean;
                                                             QUERY PLAN                                                             
------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using ix_bool_example2 on public.example2  (cost=0.14..8.40 rows=15 width=1) (actual time=0.010..0.015 rows=15 loops=1)
   Output: b1
   Index Cond: (example2.b1 = true)
 Planning Time: 0.125 ms
 Execution Time: 0.067 ms
(5 行)
perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where b1 = 0.1::boolean;
ERROR:  cannot cast type numeric to boolean
行 1: ..._bool_example2) */ b1 from example2 where b1 = 0.1::boolean;
                                                           ^
perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where b1 = -2::boolean;
ERROR:  operator does not exist: - boolean
行 1: ... ix_bool_example2) */ b1 from example2 where b1 = -2::boolea...
                                                           ^
HINT:  No operator matches the given name and argument type. You might need to add an explicit type cast.
perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where b1 = -0.1::boolean; 
ERROR:  cannot cast type numeric to boolean
行 1: ...bool_example2) */ b1 from example2 where b1 = -0.1::boolean;

暗黙型変換ではないですが、暗黙変換同様に関数が利用された場合は、索引が利用できなくなることが確認できますよね。

perftestdb=> explain (analyze,verbose) select /*+ IndexScan(example2 ix_bool_example2) */ b1 from example2 where (b1::integer - 1)::boolean = false;
                                                          QUERY PLAN                                                           
-------------------------------------------------------------------------------------------------------------------------------
 Seq Scan on public.example2  (cost=10000000000.00..10000000001.52 rows=20 width=1) (actual time=0.027..0.041 rows=15 loops=1)
   Output: b1
   Filter: (NOT (((example2.b1)::integer - 1))::boolean)
   Rows Removed by Filter: 15
 Planning Time: 0.171 ms
 Execution Time: 2.737 ms
(6 行)

MySQL

TRUEとして解釈されるリテラル値
TRUE, 1のみ。（エラーにはならないが、0以外の数字は数字として整数として登録さえるので要注意）

FALSEとして解釈されるリテラル値
FALSE, 0のみ

なので、true,1 は内部的に　　true と扱われていることがわかります。
'yes'はやなりエラーですね。

mysql> create index ix_bool_example2 on example2(b1);
Query OK, 0 rows affected (1.28 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> explain analyze select b1 from example2 where b1 = true;
+---------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                               |
+---------------------------------------------------------------------------------------------------------------------------------------+
| -> Covering index lookup on example2 using ix_bool_example2 (b1=true)  (cost=0.651 rows=4) (actual time=0.04..0.0441 rows=4 loops=1)
 |
+---------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.03 sec)

mysql> explain analyze select b1 from example2 where b1 = 1;
+--------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                              |
+--------------------------------------------------------------------------------------------------------------------------------------+
| -> Covering index lookup on example2 using ix_bool_example2 (b1=1)  (cost=0.651 rows=4) (actual time=0.0165..0.0203 rows=4 loops=1)
 |
+--------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

文字列だとエラーになるかと思いきや。ワーニング扱いですね。文字列がトランケートされた結果、述語が b1 = 0 に変更されてしまっています。これはダメですね。

mysql> explain analyze select b1 from example2 where b1 = 'yes';
+--------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                              |
+--------------------------------------------------------------------------------------------------------------------------------------+
| -> Covering index lookup on example2 using ix_bool_example2 (b1=0)  (cost=0.851 rows=6) (actual time=0.0179..0.0222 rows=6 loops=1)
 |
+--------------------------------------------------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.01 sec)
mysql> show warnings;
+---------+------+-----------------------------------------+
| Level   | Code | Message                                 |
+---------+------+-----------------------------------------+
| Warning | 1292 | Truncated incorrect DOUBLE value: 'yes' |
+---------+------+-----------------------------------------+
1 row in set (0.01 sec)

整数の正の値、負の値。予想通りそのまま、数値として比較されています。エラーにならないのでこれは避けた方が良さそう

mysql> explain analyze select b1 from example2 where b1 = 100;
+---------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                               |
+---------------------------------------------------------------------------------------------------------------------------------------+
| -> Covering index lookup on example2 using ix_bool_example2 (b1=100)  (cost=0.35 rows=1) (actual time=0.0214..0.0214 rows=0 loops=1)
 |
+---------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

mysql> explain analyze select b1 from example2 where b1 = -100;
+------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                                  |
+------------------------------------------------------------------------------------------------------------------------------------------+
| -> Covering index lookup on example2 using ix_bool_example2 (b1=-(100))  (cost=0.35 rows=1) (actual time=0.0147..0.0147 rows=0 loops=1)
 |
+------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

少数の場合もエラーにはなりません。述語は (Impossible WHERE)　なことになってますね。これらも避けた方が良さそう。

mysql> explain analyze select b1 from example2 where b1 = 0.1;
+--------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                          |
+--------------------------------------------------------------------------------------------------+
| -> Zero rows (Impossible WHERE)  (cost=0..0 rows=0) (actual time=281e-6..281e-6 rows=0 loops=1)
 |
+--------------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)

mysql> explain analyze select b1 from example2 where b1 = -0.1;
+--------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                          |
+--------------------------------------------------------------------------------------------------+
| -> Zero rows (Impossible WHERE)  (cost=0..0 rows=0) (actual time=176e-6..176e-6 rows=0 loops=1)
 |
+--------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

最後に、意地悪な検証を。

こんなことやらないと思いますけども、MySQL独特な挙動ですね。index only scanのまま、filterしてますね。TINYINTである影響なのでしょうね。面白いですが真似しないようにw。　この手の作り込んだら探すの大変そうだし。（データ積んでしっかり検証すると炙り出せるとは思うけどw）

mysql> explain analyze select b1 from example2 where (b1 - 1) = false;
+-------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                       |
+-------------------------------------------------------------------------------------------------------------------------------+
| -> Filter: ((example2.b1 - 1) = false)  (cost=1.35 rows=11) (actual time=1.78..1.8 rows=4 loops=1)
    -> Covering index scan on example2 using ix_bool_example2  (cost=1.35 rows=11) (actual time=0.234..0.251 rows=11 loops=1)
 |
+-------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.05 sec)

BOOLEAN型の癖、総まとめ

BOOLEAN/BOOLどちらでも定義可能 (Oracle/PostgreSQL/MySQL)
(MySQLは内部的には、TINYINT型なのでそれ由来の癖がある)

データサイズは、1バイト (Oracle/PostgreSQL/MySQL)

利用可能なリテラル値（INSERT/UPDATEでセットする場合） TRUEとして扱われる値 TRUE　
(Oracle/PostgreSQL/MySQL, No case sensitive)

'ON'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'YES'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'T'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'Y'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

1
(Oracle/MySQL)
(PostgreSQL booleanへのキャストが必要)

0以外の数値
(Oracle 少数及び負の整数も含む)
(PostgreSQL 正の整数のみ)
(MySQL 少数以下を切り捨てた整数として扱われるのでCHECK制約などで保護した方が安全なのではないだろうか。内部的にTINYINTである影響だろう)

FALSEとして扱われる値 FALSE
(Oracle/PostgreSQL/MySQL, No case sensitive)

'OFF'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'NO'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'F'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'N'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

0
(Oracle/MySQL)
(PostgreSQL booleanへのキャストが必要)

利用可能なリテラル値（述語で利用する場合） TRUEとして扱われる値 TRUE　
(Oracle/PostgreSQL/MySQL, No case sensitive)

'ON'
(Oracle/PostgreSQL, No case sensitive)
(MySQL　利用すると値が切り捨てられ、WHERE boolean列 = 'ON' が WHERE boolean列 = 0 に書き換えられてします。ワーニングなどで確認できるが、避けた方が良い。 sql_mode挙動が変わったりするのかは未確認)

'YES'
(Oracle/PostgreSQL, No case sensitive)
(MySQL　利用すると値が切り捨てられ、WHERE boolean列 = 'YES' が WHERE boolean列 = 0 に書き換えられてします。ワーニングなどで確認できるが、避けた方が良い。 sql_mode挙動が変わったりするのかは未確認)

'T'
(Oracle/PostgreSQL, No case sensitive)
(MySQL　利用すると値が切り捨てられ、WHERE boolean列 = 'T' が WHERE boolean列 = 0 に書き換えられてします。ワーニングなどで確認できるが、避けた方が良い。 sql_mode挙動が変わったりするのかは未確認)

'Y'
(Oracle/PostgreSQL, No case sensitive)
(MySQL　利用すると値が切り捨てられ、WHERE boolean列 = 'Y' が WHERE boolean列 = 0 に書き換えられてします。ワーニングなどで確認できるが、避けた方が良い。 sql_mode挙動が変わったりするのかは未確認)

1
(Oracle/MySQL)
(PostgreSQL booleanへのキャストが必要)

0以外の数値
(Oracle 少数及び負の整数も含む)
(PostgreSQL 正の整数のみ)
(MySQL 内部的にTINYINTである影響だろうか、エラーとはならず、数値として扱われたり、切り捨てられたりする。避けた方が良い。 e.g. WHERE boolean列 = 100や、WHERE boolean列 = 0.1 など。 sql_mode挙動が変わったりするのかは未確認)

FALSEとして扱われる値 FALSE
(Oracle/PostgreSQL/MySQL, No case sensitive)

'OFF'
(Oracle/PostgreSQL, No case sensitive)
(MySQL　利用すると値が切り捨てられ、WHERE boolean列 = 'OFF' が WHERE boolean列 = 0 に書き換えられてします。ワーニングなどで確認できるが、避けた方が良い。 sql_mode挙動が変わったりするのかは未確認)

'NO'
(Oracle/PostgreSQL, No case sensitive)
(MySQL　利用すると値が切り捨てられ、WHERE boolean列 = 'NO' が WHERE boolean列 = 0 に書き換えられてします。ワーニングなどで確認できるが、避けた方が良い。 sql_mode挙動が変わったりするのかは未確認)

'F'
(Oracle/PostgreSQL, No case sensitive)
(MySQL　利用すると値が切り捨てられ、WHERE boolean列 = 'F' が WHERE boolean列 = 0 に書き換えられてします。ワーニングなどで確認できるが、避けた方が良い。 sql_mode挙動が変わったりするのかは未確認)

'N'
(Oracle/PostgreSQL, No case sensitive)
(MySQL　利用すると値が切り捨てられ、WHERE boolean列 = 'N' が WHERE boolean列 = 0 に書き換えられてします。ワーニングなどで確認できるが、避けた方が良い。 sql_mode挙動が変わったりするのかは未確認)

0
(Oracle/MySQL)
(PostgreSQL booleanへのキャストが必要)

全体的に、true/false (null) を使うように規約で制限したり、CHECK制約で保護しておいた方が混乱を避けられるのではないだろうか。。

癖ありすぎ！　w w

では、また。

投稿日時 2024年5月29日 (水) 19時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Oracle Database 23c Free Developer Release | 固定リンク | 0 | コメント (0)

帰ってきた！標準はあるにはあるが癖の多いSQL #9、BOOLEAN型にも癖が出る

PostgreSQL/MySQLには実装済みだった Boolean型がやっとOracle Database 23aiで追加されました。長ーい間実装されなかったデータ型なので、number型を使ったりして代替されていたわけですが、23ai以降は普通に使えるってことですね。
ただ、タイトルの通り、標準はあるものの、それぞれの実装には癖があります！！！！w

どのような癖があるのか、知っておきましょう。　（兼、自分用メモ）
Oracle/PostgreSQL/MySQLで違いを見てみます。

Oracle Database 23ai

SCOTT@freepdb1> select banner_full from v$version;

BANNER_FULL
--------------------------------------------------------------------------------
Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.4.0.24.05

PostgreSQL
例によってw こちらの都合により、13.14を使っています。

perftestdb=> select version();
                                                 version                                                  
----------------------------------------------------------------------------------------------------------
 PostgreSQL 13.14 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20), 64-bit
(1 行)

MySQL

mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.36    |
+-----------+
1 row in set (0.02 sec)

データ登録時、どの値がBOOLEANとして扱われるのかマニュアルから拾った値を元に確認しておきたいと思います。キャストが必要だったりする場合には、暗黙型変換とか気にしておいた方が良いですからね。索引にも使えるデータ型ですし。。。

Oracle Database 23ai
TRUEとして解釈されるリテラル値 (文字列は大文字小文字は無視される。数値は、0以外の数値は全て、TRUEと解釈される。e.g. -1,10,0.1,-1.5 など)
TRUE. 'ON', 'YES', 'T', 'Y', 1, 0以外の数値

FALSEとして解釈されるリテラル値 (文字列は大文字小文字は無視される。数値は、0のみFALSEと解釈される)
FALSE, 'OFF', 'NO', 'F', 'N', 0

この仕様、Db2やSnowflakeのBOOLEAN型と同じように見えますね。（試してないですけどw）

マニュアルに記載されている通りの挙動。。。数値を指定した時の解釈もマニュアル通りなのですが、こんな使い方したくないですよねw 挙動確認なので試してはいますが。。。。

SCOTT@freepdb1> @boolean_literals.sql

Table dropped.
Table created.
1 row created.
1 row created.

...中略...

1 row created.
1 row created.
Commit complete.

        ID B1          MEMO
---------- ----------- ----------
         1 TRUE        TRUE
         2 TRUE        true
         3 TRUE        True
         4 TRUE        ON
         5 TRUE        on
         6 TRUE        On
         7 TRUE        YES
         8 TRUE        yes
         9 TRUE        Yes
        10 TRUE        T
        11 TRUE        t
        12 TRUE        Y
        13 TRUE        y
        14 TRUE        1
        15 TRUE        0.01
        16 TRUE        -0.01
        17 TRUE        10
        18 TRUE        -12
        19 FALSE       FALSE
        20 FALSE       false
        21 FALSE       False
        22 FALSE       OFF
        23 FALSE       off
        24 FALSE       Off
        25 FALSE       NO
        26 FALSE       no
        27 FALSE       No
        28 FALSE       F
        29 FALSE       f
        30 FALSE       N
        31 FALSE       n
        32 FALSE       0
        33 [null]      null

33 rows selected.

PostgreSQL 13.14
TRUEとして解釈されるリテラル値 (文字列は大文字小文字は無視される。数値は、正の整数のみTRUEと解釈され、負の整数や少数はエラーとなる。　-1, 0.1, -1.5などはエラー)
TRUE. 'ON', 'YES', 'T', 'Y', 1, 0以外の正の整数のみ（ただし、booleanへのキャストが必要）

FALSEとして解釈されるリテラル値 (文字列は大文字小文字は無視される。数値は、0のみFALSEと解釈される)
FALSE, 'OFF', 'NO', 'F', 'N', 0

Oracleに類似していますが、数値の扱いが微妙に違いますね。

perftestdb=> \i boolean_literals.sql
DROP TABLE
CREATE TABLE
INSERT 0 1
INSERT 0 1

...中略...

INSERT 0 1
INSERT 0 1
INSERT 0 1
psql:boolean_literals.sql:19: ERROR:  column "b1" is of type boolean but expression is of type integer
行 1: insert into example2 values(14, 1, '1');
                                      ^
HINT:  You will need to rewrite or cast the expression.
INSERT 0 1
psql:boolean_literals.sql:21: ERROR:  column "b1" is of type boolean but expression is of type numeric
行 1: insert into example2 values(15, 0.01, '0.01');
                                      ^
HINT:  You will need to rewrite or cast the expression.
psql:boolean_literals.sql:22: ERROR:  cannot cast type numeric to boolean
行 1: insert into example2 values(15, 0.01::boolean, '0.01');v                                          ^
psql:boolean_literals.sql:23: ERROR:  column "b1" is of type boolean but expression is of type numeric
行 1: insert into example2 values(16, -0.1, '-0.01');
                                      ^
HINT:  You will need to rewrite or cast the expression.
psql:boolean_literals.sql:24: ERROR:  cannot cast type numeric to boolean
行 1: insert into example2 values(16, -0.1::boolean, '-0.01');
                                          ^
psql:boolean_literals.sql:25: ERROR:  column "b1" is of type boolean but expression is of type integer
行 1: insert into example2 values(17, 10, '10');
                                      ^
HINT:  You will need to rewrite or cast the expression.
INSERT 0 1
psql:boolean_literals.sql:27: ERROR:  column "b1" is of type boolean but expression is of type integer
行 1: insert into example2 values(18, -12, '-12');
                                      ^
HINT:  You will need to rewrite or cast the expression.
psql:boolean_literals.sql:28: ERROR:  operator does not exist: - boolean
行 1: insert into example2 values(18, -12::boolean, '-12');
                                      ^
HINT:  No operator matches the given name and argument type. You might need to add an explicit type cast.
INSERT 0 1
INSERT 0 1

...中略...

INSERT 0 1
INSERT 0 1
psql:boolean_literals.sql:44: ERROR:  column "b1" is of type boolean but expression is of type integer
行 1: insert into example2 values(32, 0, '0');
                                      ^
HINT:  You will need to rewrite or cast the expression.
INSERT 0 1
INSERT 0 1
Null表示は"[null]"です。
 id |   b1   | memo  
----+--------+-------
  1 | t      | TRUE
  2 | t      | true
  3 | t      | True
  4 | t      | ON
  5 | t      | on
  6 | t      | On
  7 | t      | YES
  8 | t      | yes
  9 | t      | Yes
 10 | t      | T
 11 | t      | t
 12 | t      | Y
 13 | t      | y
 14 | t      | 1
 17 | t      | 10
 19 | f      | FALSE
 20 | f      | false
 21 | f      | False
 22 | f      | OFF
 23 | f      | off
 24 | f      | Off
 25 | f      | NO
 26 | f      | no
 27 | f      | No
 28 | f      | F
 29 | f      | f
 30 | f      | N
 31 | f      | n
 32 | f      | 0
 33 | [null] | null
(30 行)

perftestdb=>

MySQL 8.0.32
実データ型がTINYINTであるためですが、
数値の場合0,1以外ではエラーは出ないようで注意が必要ですよね。CHECK制約で保護するとかだろうか。。。

TRUEとして解釈されるリテラル値
TRUE, 1のみ。（エラーにはならないが、0以外の数字は数字として整数として登録さえるので要注意）

FALSEとして解釈されるリテラル値
FALSE, 0のみ

Oracle/PostgreSQLとも違い、最低限に絞ってるって感じですが、数値を指定した時の挙動には要注意ですね。内部の型はTINYINTなので。。。文字列を全て受け付けないのは、これもTINYINTである影響ですかね?

mysql> select @@sql_mode; +-----------------------------------------------------------------------------------------------------------------------+ | @@sql_mode | +-----------------------------------------------------------------------------------------------------------------------+ | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION | +-----------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.01 sec) mysql> \. boolean_literals.sql Query OK, 0 rows affected (0.05 sec) ...中略... Query OK, 1 row affected (0.01 sec) ERROR 1366 (HY000): Incorrect integer value: 'ON' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'on' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'On' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'YES' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'yes' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'Yes' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'T' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 't' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'Y' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'y' for column 'b1' at row 1 Query OK, 1 row affected (0.01 sec) ...中略... Query OK, 1 row affected (0.01 sec) ERROR 1366 (HY000): Incorrect integer value: 'OFF' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'off' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'Off' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'NO' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'no' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'No' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'F' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'f' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'N' for column 'b1' at row 1 ERROR 1366 (HY000): Incorrect integer value: 'n' for column 'b1' at row 1 Query OK, 1 row affected (0.01 sec) Query OK, 1 row affected (0.01 sec) +----+------+-------+ | id | b1 | memo | +----+------+-------+ | 1 | 1 | TRUE | | 2 | 1 | true | | 3 | 1 | True | | 14 | 1 | 1 | | 15 | 0 | 0.01 | | 16 | 0 | -0.01 | | 17 | 10 | 10 | | 18 | -12 | -12 | | 19 | 0 | FALSE | | 20 | 0 | false | | 21 | 0 | False | | 32 | 0 | 0 | | 33 | NULL | null | +----+------+-------+ 13 rows in set (0.00 sec)

長くなりそうなので、次回へ続く！w　

今回のまとめ

Oracle > PostgreSQL > MySQLのような感じで使える値の種類はサブセットになってる感じですね。　なので、true/false , nullだけ使ってればどこに行っても問題はなさそう。。ではあります。

Oracle Database 23ai/MySQL/PostgreSQL共通
BOOLEAN/BOOL型として定義可能。
（ただし、MySQLでは実態はTINYINTなので、TINYINT由来の癖があるので注意

TRUEとして扱われる値
TRUE　
(Oracle/PostgreSQL/MySQL, No case sensitive)

'ON'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'YES'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'T'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'Y'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

1
(Oracle/MySQL)
(PostgreSQL booleanへのキャストが必要)

0以外の数値
(Oracle 少数及び負の整数も含む)
(PostgreSQL 正の整数のみ)
(MySQL 少数以下を切り捨てた整数として扱われるのでCHECK制約などで保護した方が安全なのではないだろうか。内部的にTINYINTである影響だろう)

FALSEとして扱われる値
FALSE
(Oracle/PostgreSQL/MySQL, No case sensitive)

'OFF'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'NO'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'F'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

'N'
(Oracle/PostgreSQL, No case sensitive)
(MySQLでは使えない)

0
(Oracle/MySQL)
(PostgreSQL booleanへのキャストが必要)

全体的に、true/false (null) を使うように規約等、場合によってはCHECK制約で保護しておいた方が、何かと混乱を避けられるのではないだろうか。。

補足）

この検証に利用したスクリプト
Oracle Database 23ai

SCOTT/freepdb1> !cat boolean_literals.sql drop table if exists example2; create table example2 (id number primary key, b1 boolean, memo varchar2(10)); -- TRUE insert into example2 values(1, TRUE, 'TRUE'); insert into example2 values(2, true, 'true'); insert into example2 values(3, True, 'True'); insert into example2 values(4, 'ON', 'ON'); insert into example2 values(5, 'on', 'on'); insert into example2 values(6, 'On', 'On'); insert into example2 values(7, 'YES', 'YES'); insert into example2 values(8, 'yes', 'yes'); insert into example2 values(9, 'Yes', 'Yes'); insert into example2 values(10, 'T', 'T'); insert into example2 values(11, 't', 't'); insert into example2 values(12, 'Y', 'Y'); insert into example2 values(13, 'y', 'y'); insert into example2 values(14, 1, '1'); insert into example2 values(15, 0.01, '0.01'); insert into example2 values(16, -0.1, '-0.01'); insert into example2 values(17, 10, '10'); insert into example2 values(18, -12, '-12'); -- FALSE insert into example2 values(19, FALSE, 'FALSE'); insert into example2 values(20, false, 'false'); insert into example2 values(21, False, 'False'); insert into example2 values(22, 'OFF', 'OFF'); insert into example2 values(23, 'off', 'off'); insert into example2 values(24, 'Off', 'Off'); insert into example2 values(25, 'NO', 'NO'); insert into example2 values(26, 'no', 'no'); insert into example2 values(27, 'No', 'No'); insert into example2 values(28, 'F', 'F'); insert into example2 values(29, 'f', 'f'); insert into example2 values(30, 'N', 'N'); insert into example2 values(31, 'n', 'n'); insert into example2 values(32, 0, '0'); -- NULL insert into example2 values(33, null, 'null'); commit; -- check set NULL [null] select * from example2 order by id;

PostgreSQL 13.14

erftestdb=> \! cat boolean_literals.sql drop table if exists example2; create table example2 (id integer primary key, b1 boolean, memo varchar(10)); -- TRUE insert into example2 values(1, TRUE, 'TRUE'); insert into example2 values(2, true, 'true'); insert into example2 values(3, True, 'True'); insert into example2 values(4, 'ON', 'ON'); insert into example2 values(5, 'on', 'on'); insert into example2 values(6, 'On', 'On'); insert into example2 values(7, 'YES', 'YES'); insert into example2 values(8, 'yes', 'yes'); insert into example2 values(9, 'Yes', 'Yes'); insert into example2 values(10, 'T', 'T'); insert into example2 values(11, 't', 't'); insert into example2 values(12, 'Y', 'Y'); insert into example2 values(13, 'y', 'y'); insert into example2 values(14, 1, '1'); insert into example2 values(14, 1::boolean, '1'); insert into example2 values(15, 0.01, '0.01'); insert into example2 values(15, 0.01::boolean, '0.01'); insert into example2 values(16, -0.1, '-0.01'); insert into example2 values(16, -0.1::boolean, '-0.01'); insert into example2 values(17, 10, '10'); insert into example2 values(17, 10::boolean, '10'); insert into example2 values(18, -12, '-12'); insert into example2 values(18, -12::boolean, '-12'); -- FALSE insert into example2 values(19, FALSE, 'FALSE'); insert into example2 values(20, false, 'false'); insert into example2 values(21, False, 'False'); insert into example2 values(22, 'OFF', 'OFF'); insert into example2 values(23, 'off', 'off'); insert into example2 values(24, 'Off', 'Off'); insert into example2 values(25, 'NO', 'NO'); insert into example2 values(26, 'no', 'no'); insert into example2 values(27, 'No', 'No'); insert into example2 values(28, 'F', 'F'); insert into example2 values(29, 'f', 'f'); insert into example2 values(30, 'N', 'N'); insert into example2 values(31, 'n', 'n'); insert into example2 values(32, 0, '0'); insert into example2 values(32, 0::boolean, '0'); -- NULL insert into example2 values(33, null, 'null'); -- check \pset null [null] select * from example2 order by id;

MySQL 8.0.32

mysql> \! cat boolean_literals.sql drop table if exists example2; create table example2 (id integer primary key, b1 boolean, memo varchar(10)); -- TRUE insert into example2 values(1, TRUE, 'TRUE'); insert into example2 values(2, true, 'true'); insert into example2 values(3, True, 'True'); insert into example2 values(4, 'ON', 'ON'); insert into example2 values(5, 'on', 'on'); insert into example2 values(6, 'On', 'On'); insert into example2 values(7, 'YES', 'YES'); insert into example2 values(8, 'yes', 'yes'); insert into example2 values(9, 'Yes', 'Yes'); insert into example2 values(10, 'T', 'T'); insert into example2 values(11, 't', 't'); insert into example2 values(12, 'Y', 'Y'); insert into example2 values(13, 'y', 'y'); insert into example2 values(14, 1, '1'); insert into example2 values(15, 0.01, '0.01'); insert into example2 values(16, -0.1, '-0.01'); insert into example2 values(17, 10, '10'); insert into example2 values(18, -12, '-12'); -- FALSE insert into example2 values(19, FALSE, 'FALSE'); insert into example2 values(20, false, 'false'); insert into example2 values(21, False, 'False'); insert into example2 values(22, 'OFF', 'OFF'); insert into example2 values(23, 'off', 'off'); insert into example2 values(24, 'Off', 'Off'); insert into example2 values(25, 'NO', 'NO'); insert into example2 values(26, 'no', 'no'); insert into example2 values(27, 'No', 'No'); insert into example2 values(28, 'F', 'F'); insert into example2 values(29, 'f', 'f'); insert into example2 values(30, 'N', 'N'); insert into example2 values(31, 'n', 'n'); insert into example2 values(32, 0, '0'); -- NULL insert into example2 values(33, null, 'null'); -- check select * from example2 order by id;

ここまで見た感じ、true/false,　必要があれば null を使う側のルールとしておくと、みんな幸せになれる気がするよね。BOOLEAN型って。

参考資料）
Oracle Database 23 / 開発者ガイド / 外部データ型
"https://docs.oracle.com/cd/F82042_01/lnoci/data-types.html#GUID-D69455D9-CE01-44CC-B5A9-E541C7774805

Oracle Database 23 / SQL言語リファレンス / ブールデータ型
https://docs.oracle.com/cd/F82042_01/sqlrf/Data-Types.html#GUID-285FFCA8-390D-4FA9-9A51-47B84EF5F83A

Oracle Database 23 / SQL言語リファレンス / Oracleの組込みデータ型
https://docs.oracle.com/cd/F82042_01/sqlrf/Data-Types.html#GUID-7B72E154-677A-4342-A1EA-C74C1EA928E6

PostgreSQL / データ型 / 論理値データ型
https://www.postgresql.jp/document/13/html/datatype-boolean.html

マニュアルによると、PostgreSQLのBOOLEAN型もサイズは１バイト
PostgreSQL 13 / 8.6. 論理値データ型
https://www.postgresql.jp/document/13/html/datatype-boolean.html

MySQL その他のデータベースエンジンのデータ型の使用　 - BOOLEAN/BOOL
https://dev.mysql.com/doc/refman/8.0/ja/other-vendor-data-types.html

MySQL 数値型の記憶域要件 - TINYINT
https://dev.mysql.com/doc/refman/8.0/ja/storage-requirements.html#data-types-storage-reqs-numeric

MySQLのBOOLEANはTINYINT型で1バイトということですね。Boolean型のサイズはMySQL/Oracle/PostgreSQLどれも1バイト。
MySQL 8.0 / 11.1.6 Boolean Literals
https://dev.mysql.com/doc/refman/8.0/en/boolean-literals.html

長くなりそうなので、次回へ続くw

こういうことで、この手の　SQLの癖w　なかなか厳しいなw 　Enjoy SQL!

関連エントリー
・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)
・標準はあるにはあるが癖の多いSQL 全部俺　おまけ SQL de 湯婆婆やるにも癖がでるw
・帰ってきた！標準はあるにはあるが癖の多いSQL #1 SQL de ROT13 やるにも癖が出るw
・帰ってきた！標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #3 オプティマイザの結合順評価テーブル数上限にも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #4 Optimizer Traceの取得でも癖がでる
・帰ってきた！標準はあるにはあるが癖の多いSQL #5 - Optimizer Hint でも癖が多い
・帰ってきた！標準はあるにはあるが癖の多いSQL #6 - Hash Joinの結合ツリーにも癖がでる
・帰ってきた！標準はあるにはあるが癖の多いSQL #7 - Hash Joinの実行計画にも癖がでる
・帰ってきた！標準はあるにはあるが癖の多いSQL #8 - Hash Joinさせるにも癖が出る

投稿日時 2024年5月29日 (水) 17時00分 Oracle, FAQ, SQL, ダウンロード, MySQL, PostgreSQL, パフォーマンス, Oracle Database 23c Free Developer Release | 固定リンク | 0 | コメント (0)

2024年5月 4日 (土)

MySQL 8.0.36 , PostgreSQL 13.14, Oracle Database 21c, Oracle Database 23ai on VirtualBox for Apple Silicon Test Build 7.0.97_BETA r162957

Oracle Database 23c 改め、23ai となったのと、4/26日版 VirtualBox Test builds Development snapshotsがリリースされていた（だが、5/3版がすでに公開されていたw）
https://www.virtualbox.org/wiki/Testbuilds

M2 MBAでの確認情報だけで、M1はどうよ？とこともあるので、今回は、M1側で検証してみた。（本当はこちらでバシバシ使いたいわけですけども、まだまだ遅いので確認だけw）

*** mac info. *** ProductName: macOS ProductVersion: 14.4.1 BuildVersion: 23E224 *** maxOS ver. *** Model Name: Mac Studio Chip: Apple M1 Ultra Total Number of Cores: 20 (16 performance and 4 efficiency) Memory: 64 GB *** VirtualBox ver. *** 7.0.97r162957 (VirtualBox 4/26 Test-Builds Developer Snapshot)

公開されたばかりの、Oracle Database 23ai Free DeveloperのVirtualBox pre-Build VMでの確認。
https://www.oracle.com/database/technologies/databaseappdev-vm.html

Oracle Database 23ai Free Developer (VirtualBox pre-build VM) / Oracle Linux 8.9

相変わらずもっさり感は強いもののなんとか起動します！　

[oracle@localhost ~]$ cat /etc/*release Oracle Linux Server release 8.9 NAME="Oracle Linux Server" VERSION="8.9" ID="ol" ID_LIKE="fedora" VARIANT="Server" VARIANT_ID="server" VERSION_ID="8.9" PLATFORM_ID="platform:el8" PRETTY_NAME="Oracle Linux Server 8.9" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:oracle:linux:8:9:server" HOME_URL="https://linux.oracle.com/" BUG_REPORT_URL="https://github.com/oracle/oracle-linux" ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8" ORACLE_BUGZILLA_PRODUCT_VERSION=8.9 ORACLE_SUPPORT_PRODUCT="Oracle Linux" ORACLE_SUPPORT_PRODUCT_VERSION=8.9 Red Hat Enterprise Linux release 8.9 (Ootpa) Oracle Linux Server release 8.9

[oracle@localhost ~]$ sql hr/oracle@192.168.1.138:1521/freepdb1 SQLcl: 土 5月 04 01:14:44 2024のリリース24.1 Production Copyright (c) 1982, 2024, Oracle. All rights reserved. 接続先: Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free Version 23.4.0.24.05 SQL> select banner_full from V$version; BANNER_FULL　 _______________________________________________________________________________ Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free Version 23.4.0.24.05 SQL> exit Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free Version 23.4.0.24.05から切断されました [oracle@localhost ~]$ sudo service oracle status [sudo] oracle のパスワード: LSNRCTL for Linux: Version 23.0.0.0.0 - Production on 04-MAY-2024 01:26:55 Copyright (c) 1991, 2024, Oracle. All rights reserved. Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))) STATUS of the LISTENER ------------------------ Alias LISTENER Version TNSLSNR for Linux: Version 23.0.0.0.0 - Production Start Date 04-MAY-2024 00:49:21 Uptime 0 days 0 hr. 37 min. 34 sec Trace Level off Security ON: Local OS Authentication SNMP OFF Default Service FREE Listener Parameter File /opt/oracle/product/23ai/dbhomeFree/network/admin/listener.ora Listener Log File /opt/oracle/diag/tnslsnr/localhost/listener/alert/log.xml Listening Endpoints Summary... (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))) (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521))) Services Summary... Service "176858bcadf91ba6e0630100007f7de0" has 1 instance(s). Instance "FREE", status READY, has 1 handler(s) for this service... Service "FREE" has 2 instance(s). Instance "FREE", status UNKNOWN, has 1 handler(s) for this service... Instance "FREE", status READY, has 1 handler(s) for this service... Service "FREEXDB" has 1 instance(s). Instance "FREE", status READY, has 1 handler(s) for this service... Service "freepdb1" has 1 instance(s). Instance "FREE", status READY, has 1 handler(s) for this service... The command completed successfully [oracle@localhost ~]$ sudo service oracle stop Stopping oracle (via systemctl): [ OK ]

続いて、いつもの 21c。　こちらは、 Oracle Linux 8.4に載せています

Oracle Database 21c EE / Oracle Linux 8.4

Oracle Database 21c EE / Oracle Linux 8.4 [master@localhost ~]$ cat /etc/*release Oracle Linux Server release 8.4 NAME="Oracle Linux Server" VERSION="8.4" ID="ol" ID_LIKE="fedora" VARIANT="Server" VARIANT_ID="server" VERSION_ID="8.4" PLATFORM_ID="platform:el8" PRETTY_NAME="Oracle Linux Server 8.4" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:oracle:linux:8:4:server" HOME_URL="https://linux.oracle.com/" BUG_REPORT_URL="https://bugzilla.oracle.com/" ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8" ORACLE_BUGZILLA_PRODUCT_VERSION=8.4 ORACLE_SUPPORT_PRODUCT="Oracle Linux" ORACLE_SUPPORT_PRODUCT_VERSION=8.4 Red Hat Enterprise Linux release 8.4 (Ootpa) Oracle Linux Server release 8.4

[master@localhost ~]$ sudo su - oracle [oracle@localhost ~]$ lsnrctl start LSNRCTL for Linux: Version 21.0.0.0.0 - Production on 04-5月 -2024 08:54:58 Copyright (c) 1991, 2021, Oracle. All rights reserved. /opt/oracle/product/21c/dbhome_1/bin/tnslsnrを起動しています。お待ちください... TNSLSNR for Linux: Version 21.0.0.0.0 - Production システム・パラメータ・ファイルは/opt/oracle/homes/OraDBHome21cEE/network/admin/listener.oraです。ログ・メッセージを/opt/oracle/diag/tnslsnr/localhost/listener/alert/log.xmlに書き込みました。リスニングしています: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))) リスニングしています: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521))) (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521)))に接続中リスナーのステータス ------------------------ 別名 LISTENER バージョン TNSLSNR for Linux: Version 21.0.0.0.0 - Production 開始日 04-5月 -2024 08:55:00 稼働時間 0 日 0 時間 0 分 0 秒トレース・レベル off セキュリティ ON: Local OS Authentication SNMP OFF パラメータ・ファイル /opt/oracle/homes/OraDBHome21cEE/network/admin/listener.ora ログ・ファイル /opt/oracle/diag/tnslsnr/localhost/listener/alert/log.xml リスニング・エンドポイントのサマリー... (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))) (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521))) リスナーはサービスをサポートしていません。コマンドは正常に終了しました。 [oracle@localhost ~]$ [oracle@localhost ~]$ [oracle@localhost ~]$ sqlplus / as sysdba SQL*Plus: Release 21.0.0.0.0 - Production on 土 5月 4 08:55:08 2024 Version 21.3.0.0.0 Copyright (c) 1982, 2021, Oracle. All rights reserved. アイドル・インスタンスに接続しました。 08:55:10 SYS@ORCLCDB> startup ORACLEインスタンスが起動しました。 Total System Global Area 1073740720 bytes Fixed Size 9694128 bytes Variable Size 910163968 bytes Database Buffers 41943040 bytes Redo Buffers 7081984 bytes In-Memory Area 104857600 bytes データベースがマウントされました。データベースがオープンされました。 08:58:23 SYS@ORCLCDB> select banner_full from v$version; BANNER_FULL ---------------------------------------------------------------------- Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production Version 21.3.0.0.0 経過: 00:00:00.32 08:58:36 SYS@ORCLCDB> exit Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production Version 21.3.0.0.0との接続が切断されました。 [oracle@localhost ~]$ sqlplus / as sysdba SQL*Plus: Release 21.0.0.0.0 - Production on 土 5月 4 08:58:46 2024 Version 21.3.0.0.0 Copyright (c) 1982, 2021, Oracle. All rights reserved. 08:58:55 SYS@ORCLCDB> shutdown immediate データベースがクローズされました。データベースがディスマウントされました。 ORACLEインスタンスがシャットダウンされました。 09:00:51 SYS@ORCLCDB>

最後に、安定して起動しているMySQL/PostgreSQL
MySQL 8.0.36 and PostgreSQL 13.14 / Oracle Linux 8.5

[master@localhost ~]$ cat /etc/*release Oracle Linux Server release 8.5 NAME="Oracle Linux Server" VERSION="8.5" ID="ol" ID_LIKE="fedora" VARIANT="Server" VARIANT_ID="server" VERSION_ID="8.5" PLATFORM_ID="platform:el8" PRETTY_NAME="Oracle Linux Server 8.5" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:oracle:linux:8:5:server" HOME_URL="https://linux.oracle.com/" BUG_REPORT_URL="https://bugzilla.oracle.com/" ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8" ORACLE_BUGZILLA_PRODUCT_VERSION=8.5 ORACLE_SUPPORT_PRODUCT="Oracle Linux" ORACLE_SUPPORT_PRODUCT_VERSION=8.5 Red Hat Enterprise Linux release 8.5 (Ootpa) Oracle Linux Server release 8.5

MySQL 8.0.36

Redirecting to /bin/systemctl status mysqld.service ● mysqld.service - MySQL 8.0 database server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2024-05-03 05:34:51 EDT; 53min ago Main PID: 1119 (mysqld) Status: "Server is operational" Tasks: 38 (limit: 22947) Memory: 34.5M CGroup: /system.slice/mysqld.service └─1119 /usr/libexec/mysqld --basedir=/usr 5月 03 05:34:04 localhost.localdomain systemd[1]: Starting MySQL 8.0 database server... 5月 03 05:34:07 localhost.localdomain mysql-check-socket[1034]: Socket file /var/lib/mysql/mysql.sock exists. 5月 03 05:34:08 localhost.localdomain mysql-check-socket[1034]: No process is using /var/lib/mysql/mysql.sock, which means it is a garbage, so it will be removed automatically. 5月 03 05:34:51 localhost.localdomain systemd[1]: Started MySQL 8.0 database server. [master@localhost ~]$ [master@localhost ~]$ 5月 03 05:34:47 localhost.localdomain systemd[1]: Started PostgreSQL 13 database server. [master@localhost ~]$ mysql -u scott -D perftestdb -p -h 192.168.1.125 Enter password: Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 10 Server version: 8.0.36 Source distribution Copyright (c) 2000, 2024, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> select version(); +-----------+ | version() | +-----------+ | 8.0.36 | +-----------+ 1 row in set (0.02 sec) mysql> exit Bye [master@localhost ~]$ sudo service mysqld stop Redirecting to /bin/systemctl stop mysqld.service [master@localhost ~]$ sudo service mysqld status Redirecting to /bin/systemctl status mysqld.service ● mysqld.service - MySQL 8.0 database server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled) Active: inactive (dead) since Fri 2024-05-03 06:30:03 EDT; 8s ago Process: 7704 ExecStopPost=/usr/libexec/mysql-wait-stop (code=exited, status=0/SUCCESS) Process: 1119 ExecStart=/usr/libexec/mysqld --basedir=/usr (code=exited, status=0/SUCCESS) Main PID: 1119 (code=exited, status=0/SUCCESS) Status: "Server shutdown complete" 5月 03 05:34:04 localhost.localdomain systemd[1]: Starting MySQL 8.0 database server... 5月 03 05:34:07 localhost.localdomain mysql-check-socket[1034]: Socket file /var/lib/mysql/mysql.sock exists. 5月 03 05:34:08 localhost.localdomain mysql-check-socket[1034]: No process is using /var/lib/mysql/mysql.sock, which means it is a garbage, so it will be removed automatically. 5月 03 05:34:51 localhost.localdomain systemd[1]: Started MySQL 8.0 database server. 5月 03 06:29:56 localhost.localdomain systemd[1]: Stopping MySQL 8.0 database server... 5月 03 06:30:03 localhost.localdomain systemd[1]: mysqld.service: Succeeded. 5月 03 06:30:03 localhost.localdomain systemd[1]: Stopped MySQL 8.0 database server.

PostgreSQL 13.14

[master@localhost ~]$ sudo service postgresql-13 status Redirecting to /bin/systemctl status postgresql-13.service ● postgresql-13.service - PostgreSQL 13 database server Loaded: loaded (/usr/lib/systemd/system/postgresql-13.service; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/postgresql-13.service.d └─local.conf Active: active (running) since Fri 2024-05-03 05:34:47 EDT; 54min ago Docs: https://www.postgresql.org/docs/13/static/ Main PID: 1343 (postmaster) Tasks: 9 (limit: 22947) Memory: 19.7M CGroup: /system.slice/postgresql-13.service ├─1343 /usr/pgsql-13/bin/postmaster -D /pg/pgdata/data ├─1411 postgres: logger ├─1591 postgres: checkpointer ├─1592 postgres: background writer ├─1593 postgres: walwriter ├─1594 postgres: autovacuum launcher ├─1596 postgres: archiver ├─1597 postgres: stats collector └─1598 postgres: logical replication launcher 5月 03 05:34:25 localhost.localdomain systemd[1]: Starting PostgreSQL 13 database server... 5月 03 05:34:33 localhost.localdomain postmaster[1343]: 2024-05-03 05:34:33.304 EDT [1343] LOG: redirecting log output to logging collector process 5月 03 05:34:33 localhost.localdomain postmaster[1343]: 2024-05-03 05:34:33.304 EDT [1343] HINT: Future log output will appear in directory "log". [postgres@localhost ~]$ psql -d perftestdb -U discus -p 5432 -W -h localhost パスワード： psql (13.14) "help"でヘルプを表示します。 perftestdb=> select version(); version ---------------------------------------------------------------------------------------------------------- PostgreSQL 13.14 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-20), 64-bit (1 行) perftestdb=> exit [postgres@localhost ~]$ exit ログアウト [master@localhost ~]$ sudo service postgresql-13 stop Redirecting to /bin/systemctl stop postgresql-13.service [master@localhost ~]$ sudo service postgresql-13 status Redirecting to /bin/systemctl status postgresql-13.service ● postgresql-13.service - PostgreSQL 13 database server Loaded: loaded (/usr/lib/systemd/system/postgresql-13.service; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/postgresql-13.service.d └─local.conf Active: inactive (dead) since Fri 2024-05-03 06:31:04 EDT; 6s ago Docs: https://www.postgresql.org/docs/13/static/ Process: 1343 ExecStart=/usr/pgsql-13/bin/postmaster -D ${PGDATA} (code=exited, status=0/SUCCESS) Main PID: 1343 (code=exited, status=0/SUCCESS) 5月 03 05:34:25 localhost.localdomain systemd[1]: Starting PostgreSQL 13 database server... 5月 03 05:34:33 localhost.localdomain postmaster[1343]: 2024-05-03 05:34:33.304 EDT [1343] LOG: redirecting log output to logging collector process 5月 03 05:34:33 localhost.localdomain postmaster[1343]: 2024-05-03 05:34:33.304 EDT [1343] HINT: Future log output will appear in directory "log". 5月 03 05:34:47 localhost.localdomain systemd[1]: Started PostgreSQL 13 database server. 5月 03 06:31:03 localhost.localdomain systemd[1]: Stopping PostgreSQL 13 database server... 5月 03 06:31:04 localhost.localdomain systemd[1]: postgresql-13.service: Killing process 1411 (postmaster) with signal SIGKILL. 5月 03 06:31:04 localhost.localdomain systemd[1]: postgresql-13.service: Succeeded. 5月 03 06:31:04 localhost.localdomain systemd[1]: Stopped PostgreSQL 13 database server.

残る課題は処理速度改善だろうとは思うのですが、頑張って欲しいですね:)

そして、ゴールデンウィークなのに、真夏みたいな気温とか、異常すぎる。。。
体調管理に気を遣いつつも、こんな気候だと、まじで今年の夏はどうなることやら。。。。

ではまた。

・Oracle Linux 8 and MySQL 8.0.32 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA r160167
・MySQL 8.0.32 , PostgreSQL 13.4 and Oracle Database 21c on Oracle Linux 8 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA r160702
・MySQL 8.0.32 , PostgreSQL 13.6 and Oracle Database 21c on Oracle Linux 8.5 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA r161342
・MySQL 8.0.32 , PostgreSQL 13.6 and Oracle Database 21c on Oracle Linux 8.5 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA r161709

投稿日時 2024年5月 4日 (土) 11時30分 Oracle, VirtualBox, MySQL, PostgreSQL, Oracle Database 21c, M1 Mac, Oracle Database 23c Free Developer Release, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2024年1月27日 (土)

MySQL 8.0.32 , PostgreSQL 13.6 and Oracle Database 21c on Oracle Linux 8.5 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r161342

2024年最初のエントリーは、
VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r161342がアップされていたので、いつもの定点観測です。

結果から言うと、OS起動から、MySQL, PostgreSQLまでは起動する状態にはなっています。最近は、OS毎クラッシュしたかと思うと次のテストビルドでは起動するようになったり、なかなか状況は安定していません。また、Oracleですが、今の所一度も起動せずでした。

グラフィックコントローラーの3Dアクセラレーションを有効化は、OFFにしておいたほうが現状は良さそうです！

久々なので環境情報から
MBA M2とVirtualBox Test Buildは以下の通り

oracle@catfish ~ % sw_vers ProductName: macOS ProductVersion: 14.3 BuildVersion: 23D56 oracle@catfish ~ % /usr/sbin/system_profiler SPHardwareDataType | grep -E '(Processor|Cores|Memory|Chip|Model Name)' Model Name: MacBook Air Chip: Apple M2 Total Number of Cores: 8 (4 performance and 4 efficiency) Memory: 24 GB oracle@catfish ~ % VBoxManage -v 7.0.97_BETA5r161342

[master@localhost etc]$ cat *release* Oracle Linux Server release 8.5 NAME="Oracle Linux Server" VERSION="8.5" ID="ol" ID_LIKE="fedora" VARIANT="Server" VARIANT_ID="server" VERSION_ID="8.5" PLATFORM_ID="platform:el8" PRETTY_NAME="Oracle Linux Server 8.5" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:oracle:linux:8:5:server" HOME_URL="https://linux.oracle.com/" BUG_REPORT_URL="https://bugzilla.oracle.com/" ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8" ORACLE_BUGZILLA_PRODUCT_VERSION=8.5 ORACLE_SUPPORT_PRODUCT="Oracle Linux" ORACLE_SUPPORT_PRODUCT_VERSION=8.5 Red Hat Enterprise Linux release 8.5 (Ootpa) Oracle Linux Server release 8.5 cpe:/o:oracle:linux:8:5:server [master@localhost etc]$ uname -a Linux localhost.localdomain 5.4.17-2136.304.4.1.el8uek.x86_64 #2 SMP Tue Feb 8 11:54:24 PST 2022 x86_64 x86_64 x86_64 GNU/Linux

MySQLは以下の通り起動しました。

[master@localhost ~]$ sudo service mysqld status Redirecting to /bin/systemctl status mysqld.service ● mysqld.service - MySQL 8.0 database server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2024-01-26 21:25:04 EST; 8min ago Process: 1699 ExecStartPost=/usr/libexec/mysql-check-upgrade (code=exited, status=0/SUCCESS) Process: 1079 ExecStartPre=/usr/libexec/mysql-prepare-db-dir mysqld.service (code=exited, status=0/SUCCESS) Process: 1027 ExecStartPre=/usr/libexec/mysql-check-socket (code=exited, status=0/SUCCESS) Main PID: 1123 (mysqld) Status: "Server is operational" Tasks: 38 (limit: 22947) Memory: 402.6M CGroup: /system.slice/mysqld.service └─1123 /usr/libexec/mysqld --basedir=/usr ...略... [master@localhost ~]$ mysql -u scott -D perftestdb -p Enter password: Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 8 Server version: 8.0.32 Source distribution Copyright (c) 2000, 2023, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> select version(); +-----------+ | version() | +-----------+ | 8.0.32 | +-----------+ 1 row in set (0.00 sec) mysql> exit Bye [master@localhost ~]$ sudo service mysqld stop Redirecting to /bin/systemctl stop mysqld.service [master@localhost ~]$ sudo service mysqld status Redirecting to /bin/systemctl status mysqld.service ● mysqld.service - MySQL 8.0 database server Loaded: loaded (/usr/lib/systemd/system/mysqld.service; enabled; vendor preset: disabled) Active: inactive (dead) since Fri 2024-01-26 21:34:39 EST; 5s ago Process: 2914 ExecStopPost=/usr/libexec/mysql-wait-stop (code=exited, status=0/SUCCESS) Process: 1699 ExecStartPost=/usr/libexec/mysql-check-upgrade (code=exited, status=0/SUCCESS) Process: 1123 ExecStart=/usr/libexec/mysqld --basedir=/usr (code=exited, status=0/SUCCESS) Process: 1079 ExecStartPre=/usr/libexec/mysql-prepare-db-dir mysqld.service (code=exited, status=0/SUCCESS) Process: 1027 ExecStartPre=/usr/libexec/mysql-check-socket (code=exited, status=0/SUCCESS) Main PID: 1123 (code=exited, status=0/SUCCESS) Status: "Server shutdown complete" ...略...

PostgreSQLも以下の通り起動した

[master@localhost ~]$ sudo service postgresql-13 status Redirecting to /bin/systemctl status postgresql-13.service ● postgresql-13.service - PostgreSQL 13 database server Loaded: loaded (/usr/lib/systemd/system/postgresql-13.service; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/postgresql-13.service.d └─local.conf Active: active (running) since Fri 2024-01-26 21:24:01 EST; 12min ago Docs: https://www.postgresql.org/docs/13/static/ Process: 1033 ExecStartPre=/usr/pgsql-13/bin/postgresql-13-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS) Main PID: 1060 (postmaster) Tasks: 9 (limit: 22947) Memory: 23.3M CGroup: /system.slice/postgresql-13.service ├─1060 /usr/pgsql-13/bin/postmaster -D /pg/pgdata/data ├─1080 postgres: logger ├─1127 postgres: checkpointer ├─1128 postgres: background writer ├─1129 postgres: walwriter ├─1130 postgres: autovacuum launcher ├─1131 postgres: archiver ├─1132 postgres: stats collector └─1134 postgres: logical replication launcher ...略... [master@localhost ~]$ sudo su - postgres [postgres@localhost ~]$ psql -d perftestdb -U discus -p 5432 -W -h localhost パスワード： psql (13.6) "help"でヘルプを表示します。 perftestdb=> select version(); version -------------------------------------------------------------------------------------------------------- PostgreSQL 13.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4), 64-bit (1 行) perftestdb=> exit [postgres@localhost ~]$ exit ログアウト [master@localhost ~]$ sudo service postgresql-13 stop Redirecting to /bin/systemctl stop postgresql-13.service [master@localhost ~]$ sudo service postgresql-13 status Redirecting to /bin/systemctl status postgresql-13.service ● postgresql-13.service - PostgreSQL 13 database server Loaded: loaded (/usr/lib/systemd/system/postgresql-13.service; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/postgresql-13.service.d └─local.conf Active: inactive (dead) since Fri 2024-01-26 21:37:12 EST; 5s ago Docs: https://www.postgresql.org/docs/13/static/ Process: 1060 ExecStart=/usr/pgsql-13/bin/postmaster -D ${PGDATA} (code=exited, status=0/SUCCESS) Process: 1033 ExecStartPre=/usr/pgsql-13/bin/postgresql-13-check-db-dir ${PGDATA} (code=exited, status=0/SUCCESS) Main PID: 1060 (code=exited, status=0/SUCCESS) ...略...

残念ながら、今回のテストビルトでも、Oracleは起動せず。リスナーはいつも通り起動しますが。

[oracle@localhost ~]$ lsnrctl start LSNRCTL for Linux: Version 21.0.0.0.0 - Production on 27-1月 -2024 12:01:04 Copyright (c) 1991, 2021, Oracle. All rights reserved. /opt/oracle/product/21c/dbhome_1/bin/tnslsnrを起動しています。お待ちください... TNSLSNR for Linux: Version 21.0.0.0.0 - Production システム・パラメータ・ファイルは/opt/oracle/homes/OraDBHome21cEE/network/admin/listener.oraです。ログ・メッセージを/opt/oracle/diag/tnslsnr/localhost/listener/alert/log.xmlに書き込みました。リスニングしています: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))) リスニングしています: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521))) (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521)))に接続中リスナーのステータス ------------------------ 別名 LISTENER バージョン TNSLSNR for Linux: Version 21.0.0.0.0 - Production 開始日 27-1月 -2024 12:01:04 稼働時間 0 日 0 時間 0 分 1 秒トレース・レベル off セキュリティ ON: Local OS Authentication SNMP OFF パラメータ・ファイル /opt/oracle/homes/OraDBHome21cEE/network/admin/listener.ora ログ・ファイル /opt/oracle/diag/tnslsnr/localhost/listener/alert/log.xml リスニング・エンドポイントのサマリー... (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521))) (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521))) リスナーはサービスをサポートしていません。コマンドは正常に終了しました。 [oracle@localhost ~]$ sqlplus / as sysdba SQL*Plus: Release 21.0.0.0.0 - Production on 土 1月 27 12:01:09 2024 Version 21.3.0.0.0 Copyright (c) 1982, 2021, Oracle. All rights reserved. アイドル・インスタンスに接続しました。 SYS@ORCLCDB> startup ORA-03113: 通信チャネルでend-of-fileが検出されました

もう一息なのかどうかわかりませんが、Oracleも起動してくれることを、期待しつつ、定点観測は続く :)
今年中に起動するようになってくれると嬉しいですよね。

ではまた:)

・Oracle Linux 8 and MySQL 8.0.32 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r160167
・MySQL 8.0.32 , PostgreSQL 13.4 and Oracle Database 21c on Oracle Linux 8 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r160702

投稿日時 2024年1月27日 (土) 14時57分 Oracle, Mac, VirtualBox, MySQL, PostgreSQL, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2023年12月17日 (日)

帰ってきた！標準はあるにはあるが癖の多いSQL #8、Hash Joinさせるにも癖が出る

本エントリーは、
MySQL Advent Calendar 2023 シリーズ1
PostgreSQL Advent Calendar 2023 シリーズ1
JPOUG Advent Calendar 2023

の Day 17 向けエントリーです。

また、本エントリー向け予習エントリーを投稿していますので、一読していただくと私が何と戦っていたのかw 理解しやすいのではないかと思います

予習　その１は、以下。
帰ってきた！標準はあるにはあるが癖の多いSQL #5 - Optimizer Hint でも癖が多い

予習　その２は、以下。
帰ってきた！標準はあるにはあるが癖の多いSQL #6 - Hash Joinの結合ツリーにも癖がでる

予習　その３は、以下。
帰ってきた！標準はあるにはあるが癖の多いSQL #7 - Hash Joinの実行計画の見せ方にも癖がでる

ということで、これまでの予習で学んだことを利用して、もしも、こんなデータ（予習　その２　を参照のこと）で、以下のようなSQLがあった場合、Hash Joinの特性上いい感じの実行計画にさせるにはどうHintingするのが良いのか考えてみたいと思います。
（答えが見えている方は多いとは思いますけどもw）

以下のSQL文を使い、後述のような実行計画に制御することを目指してみます。

SELECT t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 , t0.m_id , t0.t0_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id INNER JOIN t0 ON t1.id = t0.id ;

いざというときに慌てずに、どうするかを判断、チューニングできるようになっておくと良いですよねー。
そう言う、いざ、という場面には付き合わされない人も、雑学的になんとなーーーく理解しているだけでも良いのではないかと思います。

Oracleの実行計画風ですが、こんな実行計画にオプティマイザーヒントだけで制御してみたいなぁ。というのがお題。右側にコメントしているBuild/Probeの関係を覚えておいてください。この形にするのが目的です。
（予習に目を通した方は、あ”〜っ。と何かに気づいちゃったと思いますけどもw）

ポイントになるのは、t0の結合です。　t1,t2,t3,t4と結合した結果が、t0の行数より多くなります。（そうなるようにデータを用意したので）Hash Joinを想定しているので、最後にt0を結合する場合には、t0をBuildにしたいですよね。。。
（Hash Joinの結合順で理想なのは、常にBuildの方が小さくなる結合順なので、以下の形が理想的だとのがわかりやすいようにJoin cardinarityも記載してあります）

HJ (join card = 2,500,000) -> t0 (rows = 1,000) -- Build -> HJ (join card = 250,000) -- Probe -> HJ (join card = 500) -- Build -> HJ (join card = 50) -- Build -> t1 (rows = 10) -- Build -> t2 (rows = 50) -- Probe -> t3 (rows = 100) -- Probe -> t4 (rows = 500) -- Probe

なお、これまでの予習で、MySQLは、Hash Join はできるけど、Build/Probeの制御ができない。 Left Deep Join Treeにしかならないのもどうしようもない。　
オプティマイザヒントでは無理だろうと想像はできるわけですがw 折角なので、できるところまで試して、挙動をみておきましょう:)

再掲
テーブル定義とデータ量は以下、予習　その２参照のこと。
帰ってきた！標準はあるにはあるが癖の多いSQL #6 - Hash Joinの結合ツリーにも癖がでる

まず、Oracleからですかねぇ。やはり。豊富なオプティマイザヒントと最適化が行えることが強みの一つだと思います。

Oracle Database 21c

ちょっと暴れてたのでw NO_SWAP_JOIN_INPUTSを使ってますが、実行計画としては狙ったところに持っていけますよね。Oraclerの方なら、ふむふむ。というところだと思います。
t1, t2, t3, t4, t0の順で結合しますが、最後の、t0の結合時は、Buildを t0　にしてね！　というHinging。実践でも結構使う場面はありますよね。
(実行計画の右側に確認しやすくするため、どちらが (Build) / (Probe) なのかをコメントしてあります）

SCOTT@ORCLCDB> select banner_full from v$version; BANNER_FULL ----------------------------------------------------------------------- Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production Version 21.3.0.0.0 SCOTT@orclpdb1> @advent_sql_ora 1 SELECT 2 /*+ 3 MONITOR 4 LEADING(t1 t2 t3 t4 t0) 5 USE_HASH(t1 t2 t3 t4 t0) 6 NO_SWAP_JOIN_INPUTS(t4) 7 SWAP_JOIN_INPUTS(t0) 8 */ 9 t1.id 10 , t1.t1_c1 11 , t2.s_id 12 , t2.t2_c1 13 , t3.b_id 14 , t3.t3_c1 15 , t4.a_id 16 , t4.c_id 17 , t4.t4_c1 18 , t0.m_id 19 , t0.t0_c1 20 FROM 21 t1 22 INNER JOIN t2 23 ON 24 t1.id = t2.id 25 INNER JOIN t3 26 ON 27 t1.id = t3.id 28 INNER JOIN t4 29 ON 30 t1.id = t4.id 31 INNER JOIN t0 32 ON 33* t1.id = t0.id ...略... SQL Plan Monitoring Details (Plan Hash Value=3728371915) ==================================================================================================================================================== | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Read | Read | Mem | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | Reqs | Bytes | (Max) | (%) | (# samples) | ==================================================================================================================================================== | 0 | SELECT STATEMENT | | | | 106 | +0 | 1 | 3M | | | . | | | | 1 | HASH JOIN | | 3M | 29 | 106 | +0 | 1 | 3M | | | 1MB | | | | 2 | TABLE ACCESS FULL | T0 | 1000 | 3 | 1 | +0 | 1 | 1000 | 2 | 49152 | . | | | (Build) | 3 | HASH JOIN | | 25000 | 12 | 106 | +0 | 1 | 25000 | | | 1MB | | | (Probe) | 4 | HASH JOIN | | 500 | 9 | 1 | +0 | 1 | 500 | | | 1MB | | | (Build) | 5 | HASH JOIN | | 50 | 6 | 1 | +0 | 1 | 50 | | | 1MB | | | (Build) | 6 | TABLE ACCESS FULL | T1 | 10 | 3 | 1 | +0 | 1 | 10 | 2 | 49152 | . | | | (Build) | 7 | TABLE ACCESS FULL | T2 | 50 | 3 | 1 | +0 | 1 | 50 | 2 | 49152 | . | | | (Probe) | 8 | TABLE ACCESS FULL | T3 | 100 | 3 | 1 | +0 | 1 | 100 | 2 | 49152 | . | | | (Probe) | 9 | TABLE ACCESS FULL | T4 | 500 | 3 | 106 | +0 | 1 | 500 | 3 | 81920 | . | | | (Probe) ====================================================================================================================================================

簡単に解説すると、t1からt4まではLeft Deep Join Tree、t0は、術式反転w で Right Deep Join Treeになるように、SWAP_JOIN_INPUTSしてます。

Id=5で、Id=6のt1（Build）と、Id=7のt2（Probe）をHash Join
Id=4で、Id=5の結果（Build）と、Id=8のt3（Probe）をHash Join
Id=3で、Id=4の結果（Build）と、Id=9のt4（Probe）をHash Join
Id=2で、SWAP_JOIN_INPUTSヒントで入れ替えた、Id=2のt0(Build)と、Id=3の結果（Probe）をHash Join

狙った実行計画に制御できました。ニッコリ。

参考）使ったSQLスクリプトは以下の通り。

SCOTT@ORCLCDB> !cat show_realtime_sqlplan.sql set linesize 1000 set long 1000000 set longchunksize 1000000 select dbms_sqltune.report_sql_monitor(sql_id=>'', type=>'text') from dual; SCOTT@ORCLCDB> !cat advent_sql_ora.sql SELECT /*+ MONITOR LEADING(t1 t2 t3 t4 t0) USE_HASH(t1 t2 t3 t4 t0) NO_SWAP_JOIN_INPUTS(t4) SWAP_JOIN_INPUTS(t0) */ t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 , t0.m_id , t0.t0_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id INNER JOIN t0 ON t1.id = t0.id . l set tab off set termout off / set termout on @show_realtime_sqlplan

PostgreSQL 13.4 with pg_hint_plan 1.3.9
なんで、最新のPostgreSQLじゃないのか？　単にアップデートサボってるだなので、気にししないでw

perftestdb=# select version(); version -------------------------------------------------------------------------------------------------------- PostgreSQL 13.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.4.1 20200928 (Red Hat 8.4.1-1), 64-bit perftestdb=# select * from pg_extension where extname='pg_hint_plan'; oid | extname | extowner | extnamespace | extrelocatable | extversion | extconfig | extcondition --------+--------------+----------+--------------+----------------+------------+-----------------+-------------- 131364 | pg_hint_plan | 10 | 131363 | f | 1.3.9 | {131367,131365} | {"",""} perftestdb=> show shared_preload_libraries; shared_preload_libraries ----------------------------------------------- pg_hint_plan

pg_hint_planのLeadingヒントの使い方慣れるまで結構迷子になってましたw。空気感でなんとなーく使い方を理解できたかなぁ。という感じ。
pg_hint_planのLeading(pair)の書き方と、順序の指定順って、Oraclerの感覚的には逆なんですよね。Hash Joinの時だけは。。。というところ気づきました？　みなさん。（主に、Oracle方面の）

perftestdb=> \! cat advent_sql_pg.sql explain (analyze) SELECT /*+ Leading(((t4 (t3 (t2 t1))) t0)) HashJoin(t0 t1 t2 t3 t4) SeqScan(t0) SeqScan(t1) SeqScan(t2) SeqScan(t3) SeqScan(t4) */ t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 , t0.m_id , t0.t0_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id INNER JOIN t0 ON t1.id = t0.id ; perftestdb=> \i advent_sql_pg.sql QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------- Id=1 Hash Join (cost=46.66..28524.66 rows=2500000 width=44) (actual time=0.875..574.957 rows=2500000 loops=1) Hash Cond: (t1.id = t0.id) Id=2 (Probe) -> Hash Join (cost=18.16..308.66 rows=25000 width=48) (actual time=0.429..11.123 rows=25000 loops=1) Hash Cond: (t4.id = t1.id) Id=3 (Probe) -> Seq Scan on t4 (cost=0.00..8.00 rows=500 width=16) (actual time=0.006..0.776 rows=500 loops=1) Id=4 (Build) -> Hash (cost=11.91..11.91 rows=500 width=32) (actual time=0.418..0.423 rows=500 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 40kB Id=5 -> Hash Join (cost=4.04..11.91 rows=500 width=32) (actual time=0.072..0.270 rows=500 loops=1) Hash Cond: (t3.id = t1.id) Id=6 (Probe) -> Seq Scan on t3 (cost=0.00..2.00 rows=100 width=12) (actual time=0.004..0.016 rows=100 loops=1) Id=7 (Build) -> Hash (cost=3.41..3.41 rows=50 width=20) (actual time=0.064..0.067 rows=50 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 11kB Id=8 -> Hash Join (cost=1.23..3.41 rows=50 width=20) (actual time=0.018..0.053 rows=50 loops=1) Hash Cond: (t2.id = t1.id) Id=9 (Probe) -> Seq Scan on t2 (cost=0.00..1.50 rows=50 width=12) (actual time=0.004..0.011 rows=50 loops=1) Id=10 (Build) -> Hash (cost=1.10..1.10 rows=10 width=8) (actual time=0.008..0.009 rows=10 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 9kB Id=11 -> Seq Scan on t1 (cost=0.00..1.10 rows=10 width=8) (actual time=0.003..0.005 rows=10 loops=1) Id=12 (Build) -> Hash (cost=16.00..16.00 rows=1000 width=12) (actual time=0.437..0.437 rows=1000 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 51kB Id=13 -> Seq Scan on t0 (cost=0.00..16.00 rows=1000 width=12) (actual time=0.022..0.219 rows=1000 loops=1)

解説のために、Id=noと、Build/Probeを見やすくするためにコメント (Build) / (Probe) を追加しています

Oracleと同じように制御できているか、確認しましょう。

Id=8で、Id=11のt1をSeq ScanしてId=10でハッシュ表作成（Build）と、Id=9のt2をSec Scan（Probe）をHash Join
Id=5で、Id=8の結果を元に、Id=7でハッシュ表作成（Build）と、Id=6のt3 Seq Scan（Probe）をHash Join
Id=2で、Id=5の結果を元に、Id=4でハッシュ表作成（Build）と、Id=3のt4 Seq Scan（Probe）をHash Join
Id=1で、Id=13のt0をSeq ScanしてId=12でハッシュ表作成（Build）と、Id=2の結果（Probe）をHash Join

狙い通りの実行計画になっています！、Yahooooo!!

今一度、Oracleの実行計画と比較してみると、Hash JoinのBuild/Probeの表現が逆になっていることがよくわかりますよね。（前回の予習の通りです）

======================================================================================================================= | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Read | Read | Mem | | | | | (Estim) | | Active(s) | Active | | (Actual) | Reqs | Bytes | (Max) | ======================================================================================================================= | 0 | SELECT STATEMENT | | | | 106 | +0 | 1 | 3M | | | . | | 1 | HASH JOIN | | 3M | 29 | 106 | +0 | 1 | 3M | | | 1MB | (Build) | 2 | TABLE ACCESS FULL | T0 | 1000 | 3 | 1 | +0 | 1 | 1000 | 2 | 49152 | . | (Probe) | 3 | HASH JOIN | | 25000 | 12 | 106 | +0 | 1 | 25000 | | | 1MB | (Build) | 4 | HASH JOIN | | 500 | 9 | 1 | +0 | 1 | 500 | | | 1MB | (Build) | 5 | HASH JOIN | | 50 | 6 | 1 | +0 | 1 | 50 | | | 1MB | (Build) | 6 | TABLE ACCESS FULL | T1 | 10 | 3 | 1 | +0 | 1 | 10 | 2 | 49152 | . | (Probe) | 7 | TABLE ACCESS FULL | T2 | 50 | 3 | 1 | +0 | 1 | 50 | 2 | 49152 | . | (Probe) | 8 | TABLE ACCESS FULL | T3 | 100 | 3 | 1 | +0 | 1 | 100 | 2 | 49152 | . | (Probe) | 9 | TABLE ACCESS FULL | T4 | 500 | 3 | 106 | +0 | 1 | 500 | 3 | 81920 | . | =======================================================================================================================

最後に、
MySQL 8.0.32
これも現時点のリリースよりちょっと前のですが、こちらの都合なので、気にしないでくださいw

mysql> select version(); +-----------+ | version() | +-----------+ | 8.0.32 | +-----------+ 1 row in set (0.01 sec) mysql>

無理やり、Hash Joinにはしていますが、PostgreSQLのpg_hint_planのように結合優先順位をペアで制御する方法も、Oracleのように、SWAP_JOIN_INPUTSヒントを使うこともできません。Left Deep Join Treeにしかならないということなので、それが理由ではありますが。とりあえず、こんな感じにしかなりません。JOIN_ORDERヒントの結合順は、OracleのLEADINGヒントに近い考え方で支えているのがわかります。要するに、Buhy Join Treeが可能であれば、これは解決できるわけですが、それは無理なので、t0をBuildにすることができず、これが限界といことになりますよね。（ちょっと思いついたことがあるので、このあと、もうひとあがきしてみますがw）

あと、ヒントで面白いのは、主キー索引を利用させないためのヒント。primaryって指定が必要なんので覚えておくと便利ですよね。
マニュアルにも記載されていますが、インデックスヒントが非推奨になる前に、オプティマイザヒントに慣れておいたほうがよさそうですし。

MySQL 8.0 / 8.9.4 インデックスヒント

”注記
MySQL 8.0.20 の時点で、サーバーは、インデックスオプティマイザヒント JOIN_INDEX, GROUP_INDEX, ORDER_INDEX、および INDEX(NO_JOIN_INDEX, NO_GROUP_INDEX, NO_ORDER_INDEX および FORCE INDEX オプティマイザヒントに相当およびを置き替える)、および NO_INDEX オプティマイザヒント (IGNORE INDEX インデックスヒントに相当し、それらを置き換える) をサポートします。したがって、USE INDEX、FORCE INDEX および IGNORE INDEX は、MySQL の将来のリリースで非推奨になり、後で完全に削除される予定です。詳細は、インデックスレベルのオプティマイザヒントを参照してください。”

mysql> \! cat advent_sql_my.sql explain analyze SELECT /*+ JOIN_ORDER(t1,t2,t3,t4,t0) NO_JOIN_INDEX(t1 primary) NO_JOIN_INDEX(t2 primary) NO_JOIN_INDEX(t3 primary) NO_JOIN_INDEX(t4 primary) NO_JOIN_INDEX(t0 primary) */ t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 , t0.m_id , t0.t0_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id INNER JOIN t0 ON t1.id = t0.id ; mysql> \. advent_sql_my.sql +---------------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +---------------------------------------------------------------------------------------------------------------------------+ Id=1 | -> Inner hash join (t0.id = t1.id) (cost=2525558.24 rows=2500000) (actual time=23.139..356.660 rows=2500000 loops=1) Id=2 (Probe) -> Table scan on t0 (cost=0.00 rows=1000) (actual time=0.083..0.512 rows=1000 loops=1) Id=3 (Build) -> Hash Id=4 -> Inner hash join (t4.id = t1.id) (cost=25552.55 rows=25000) (actual time=0.679..4.613 rows=25000 loops=1) Id=5 (Probe) -> Table scan on t4 (cost=0.01 rows=500) (actual time=0.057..0.330 rows=500 loops=1) Id=6 (Build) -> Hash Id=7 -> Inner hash join (t3.id = t1.id) (cost=551.75 rows=500) (actual time=0.223..0.412 rows=500 loops=1) Id=8 (Probe) -> Table scan on t3 (cost=0.03 rows=100) (actual time=0.041..0.069 rows=100 loops=1) Id=9 (Build) -> Hash Id=10 -> Inner hash join (t2.id = t1.id) (cost=51.50 rows=50) (actual time=0.106..0.146 rows=50 loops=1) Id=11 (Probe) -> Table scan on t2 (cost=0.08 rows=50) (actual time=0.025..0.040 rows=50 loops=1) Id=12 (Build) -> Hash Id=13 -> Table scan on t1 (cost=1.25 rows=10) (actual time=0.040..0.048 rows=10 loops=1) | +---------------------------------------------------------------------------------------------------------------------------+
（確認し訳するため、Id=nと(Build) / (Probe)を示すコメントを追記してあります）
Id=10で、Id=13のt1をTable Scanてから、Id=12でハッシュ表作成（Build）と、Id=11で、t2をTable Scan（Probe）をHash Join
Id=7で、Id=10の結果を元に、Id=9でハッシュ表作成（Build）と、Id=8のt3 Table Scan（Probe）をHash Join
Id=4で、Id=7の結果を元に、Id=6でハッシュ表作成（Build）と、Id=5のt4 Table Scan（Probe）をHash Join
Id=1で、Id=4の結果を元に、Id=3でハッシュ表作成（Build）と、Id=2のt0 Table Scan（Prove）をHash Hoin

最後のt0をBuildにしたいわけですけども、Build表制御することができないので。こんな感じですね。

と、一つだけ、思いついたので、SQL魔改造でなんとかならんか、試してみます。
（ヒントだけでなんとかするという趣旨からはズレるのですけどもw）

ダメ元で試してみますw

おおおおお、一瞬、できた！　か？　　と思いましたが、やはり無理です。CTEでサブクエリーとして先に一時表としてマテリアライズしたら行くかなぁ。
と思いましたが、MySQLは、一時表でも、自動的に内部的な主キーが作成されるという、... clustered indexなのか。。。一時表も。という気づき。
この方法では、CTEを使っていますが、インラインビューにして、NO_MERGEヒントにしても同様に、一時表としてマテリアライズされるようで、同様の結果でした。。。。

記載はしていませんが、マテリアライズされた一時表の　　という内部的な主キーですが、現状、 NO_JOIN_INDEXヒントで止められないので、t0の結合はNLJにしかできませんでした。。。

現時点のMySQLのオプティマイザの気持ちが、少しだけ、理解できるようになった気がします :)

mysql> \! cat advent_sql2_my.sql explain analyze WITH t1234 AS ( SELECT /*+ QB_NAME(ilv1) JOIN_ORDER(t1,t2,t3,t4) NO_JOIN_INDEX(t1 primary) NO_JOIN_INDEX(t2 primary) NO_JOIN_INDEX(t3 primary) NO_JOIN_INDEX(t4 primary) */ t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id ), t00 AS ( SELECT /*+ QB_NAME(ilv2) NO_INDEX(t0 primary) */ t0.id , t0.m_id , t0.t0_c1 FROM t0 ) SELECT /*+ JOIN_ORDER(@ilv2) NO_MERGE(t00) */ t1234.id , t1234.t1_c1 , t1234.s_id , t1234.t2_c1 , t1234.b_id , t1234.t3_c1 , t1234.a_id , t1234.c_id , t1234.t4_c1 , t00.m_id , t00.t0_c1 FROM t1234 INNER JOIN t00 ON t1234.id = t00.id ; mysql> \. advent_sql2_my.sql +---------------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +---------------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=2588052.66 rows=25000001) (actual time=2.449..1233.983 rows=2500000 loops=1) -> Inner hash join (t4.id = t1.id) (cost=25552.55 rows=25000) (actual time=0.626..11.339 rows=25000 loops=1) -> Table scan on t4 (cost=0.01 rows=500) (actual time=0.031..2.330 rows=500 loops=1) -> Hash -> Inner hash join (t3.id = t1.id) (cost=551.75 rows=500) (actual time=0.403..0.483 rows=500 loops=1) -> Table scan on t3 (cost=0.03 rows=100) (actual time=0.024..0.037 rows=100 loops=1) -> Hash -> Inner hash join (t2.id = t1.id) (cost=51.50 rows=50) (actual time=0.329..0.350 rows=50 loops=1) -> Table scan on t2 (cost=0.08 rows=50) (actual time=0.021..0.028 rows=50 loops=1) -> Hash -> Table scan on t1 (cost=1.25 rows=10) (actual time=0.190..0.199 rows=10 loops=1) -> Index lookup on t00 using (id=t1.id) (cost=201.25..203.50 rows=10) (actual time=0.002..0.036 rows=100 loops=25000) -> Materialize CTE t00 (cost=201.00..201.00 rows=1000) (actual time=1.803..1.803 rows=1000 loops=1) -> Table scan on t0 (cost=101.00 rows=1000) (actual time=0.024..0.514 rows=1000 loops=1) | +---------------------------------------------------------------------------------------------------------------------------+ 1 row in set (2.77 sec)

（Warningも出てないので、オプティマイザヒントの指定方法としては良さげだが、狙い通りにはなりませんw）

では、最後に、このポストへ至るまでの予習ポストも含め、リンクを再掲しておきます

予習その１

帰ってきた！標準はあるにはあるが癖の多いSQL #5 - Optimizer Hint でも癖が多い

予習その２

帰ってきた！標準はあるにはあるが癖の多いSQL #6 - Hash Joinの結合ツリーにも癖がでる

予習その３

帰ってきた！標準はあるにはあるが癖の多いSQL #7 - Hash Joinの実行計画にも癖がでる

皆様、メリークリスマス & 良いお年をお迎えください。 :)　/ Oracle database 23c with pipe line function / SQL de Christmas Tree 、4K対応で作り直しましたw
恒例？の、Oracle Pipelined Table Function で Christmas ASCII Art

関連エントリー

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)
・標準はあるにはあるが癖の多いSQL 全部俺　おまけ SQL de 湯婆婆やるにも癖がでるw
・帰ってきた！標準はあるにはあるが癖の多いSQL #1 SQL de ROT13 やるにも癖が出るw
・帰ってきた！標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #3 オプティマイザの結合順評価テーブル数上限にも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #4 Optimizer Traceの取得でも癖がでる
・帰ってきた！標準はあるにはあるが癖の多いSQL #5 - Optimizer Hint でも癖が多い
・帰ってきた！標準はあるにはあるが癖の多いSQL #6 - Hash Joinの結合ツリーにも癖がでる
・帰ってきた！標準はあるにはあるが癖の多いSQL #7 - Hash Joinの実行計画にも癖がでる

投稿日時 2023年12月17日 (日) 00時00分 Oracle, チューニング, SQL, MySQL, PostgreSQL, JPOUG, パフォーマンス, Advent Calendar | 固定リンク | 0 | コメント (0)

2023年12月13日 (水)

MySQL 8.0.32 , PostgreSQL 13.4 and Oracle Database 21c on Oracle Linux 8 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r160702

予定外ですが、Advent Calendarのシーズンついでなので、空いていた以下のアドベントカレンダー向けエントリーとなります。
Kernel/VM Advent Calendar 2023 / Day 13

macOS / ARM64 Beta development revision 160702
https://www.virtualbox.org/wiki/Testbuilds

以前、Oracle Linux 8 and MySQL 8.0.32 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r160167で、MySQL 8.0.32が起動した！と言うことを書きましたが、その後のBETAリリースではOS起動中にクラッシュしていました。
で、今回は、development revision 160702をダメもとで試してみました。

結果から書くと、色々もっさりしているのは仕方ないかないところですが、このrevisionでは、MySQLに加えて、PostgreSQLも起動しました！！！

VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r160702
GuestOS : Oracle Linux Server release 8.5
MySQL 8.0.32 - 起動した！
PostgreSQL 13.4 - 起動した！
Oracle database 21c - 起動せず！

試した内容は前回と同じですが、Oracleについては変えています。
1) Oracle Linux 8.5 に、PostgreSQL 13.4 と MySQL 8.0.32 を構成したVMをエクスポートして ova 作成
2) 1)のOracle Linux 8.5 に、Oracle Database 21cを構成したものを ova としてエクスポート。
それぞれをVirtualBoxへインポートして検証しました。

ちなみに、
Oracle Linux 7.6のPre-Built Developer VMs (for Oracle VM VirtualBox) および、Oracle Linux 8.6に構築したOracle 23c Freeは、OS起動にクラッシュしていたので、うまく起動した1)を利用して、OS起動後にOracleの挙動を確認する方法にしましたが、Oracleがコケたと言う結果となりました。

Test Buildは、結構進んできているようで、今後が楽しみです ;)

では、また。

関連エントリー
・Oracle Linux 8 and MySQL 8.0.32 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r160167

投稿日時 2023年12月13日 (水) 17時05分 Oracle, Linux, VirtualBox, MySQL, PostgreSQL, Advent Calendar, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2023年12月10日 (日)

帰ってきた！標準はあるにはあるが癖の多いSQL #7 - Hash Joinの実行計画の見せ方にも癖がでる

本エントリーは、MySQL Advent Calendar 2023 シリーズ2 / Day 10とPostgreSQL Advent Calendar 2023 シリーズ2 / Day 10へのクロスポスト、および、JPOUG Advent Calendar 2023 / Day 10 の裏番組　（ADVENTARはシリーズ増やせないので）　エントリーで、12/17日向けの　予習　その３　という位置付けのエントリーです。

予習　その１は、以下。
帰ってきた！標準はあるにはあるが癖の多いSQL #5 - Optimizer Hint でも癖が多い

予習　その２は、以下。
帰ってきた！標準はあるにはあるが癖の多いSQL #6 - Hash Joinの結合ツリーにも癖がでる

MySQLは、Left Deep Join Treeにしかならない、というところまで理解できたのが前回までの予習でした。

今日は、もう少し、理解を深めておこうと言うことで、MySQLでは無理だけど、 PostgreSQL と Oracle で結合ツリーの種別（Oracleのマニュアルに記載されている分類の範囲）で、Right Deep Join、Left Deep Join、Bushy Joinでは、どのような実行計画として見えるのかを確認しておきましょう。

まず初めに、MySQLはできない Right Deep Join Tree で Hash Join させると、どのような実行計画に見えるか？　の比較から。

Oracle Database 21c
Oraclerなら見慣れたSWAP_JOIN_INPUTSヒント利用の典型的な例です。Id=6でt1(build)がtable full scanされ、ID=7のt2(Probe)と結合されています。t3, t4はそれぞれ、Buildとなっていることが読み取れます。

Oracle Database 21c / Right Deep Join Tree / Hash Join
（実行計画の右端に (Build) なのか、　(Probe)　を確認しやすいようにコメントを付加しています）

SCOTT@orclpdb1> @ora_sql_rightdj.sql 1 SELECT 2 /*+ 3 MONITOR 4 LEADING(t1 t2 t3 t4) 5 USE_HASH(t1 t2 t3 t4) 6 SWAP_JOIN_INPUTS(t3) 7 SWAP_JOIN_INPUTS(t4) 8 */ 9 t1.id 10 , t1.t1_c1 11 , t2.s_id 12 , t2.t2_c1 13 , t3.b_id 14 , t3.t3_c1 15 , t4.a_id 16 , t4.c_id 17 , t4.t4_c1 18 FROM 19 t1 20 INNER JOIN t2 21 ON 22 t1.id = t2.id 23 INNER JOIN t3 24 ON 25 t1.id = t3.id 26 INNER JOIN t4 27 ON 28* t1.id = t4.id ...略... SQL Plan Monitoring Details (Plan Hash Value=3835853103) =================================================================================================================================================== | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Read | Read | Mem | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | Reqs | Bytes | (Max) | (%) | (# samples) | =================================================================================================================================================== | 0 | SELECT STATEMENT | | | | 2 | +0 | 1 | 25000 | | | . | | | | 1 | HASH JOIN | | 25000 | 12 | 2 | +0 | 1 | 25000 | | | 1MB | | | | 2 | TABLE ACCESS FULL | T4 | 500 | 3 | 1 | +0 | 1 | 500 | 2 | 49152 | . | | | (Build) | 3 | HASH JOIN | | 500 | 9 | 2 | +0 | 1 | 500 | | | 1MB | | | (Probe) | 4 | TABLE ACCESS FULL | T3 | 100 | 3 | 1 | +0 | 1 | 100 | 2 | 49152 | . | | | (Build) | 5 | HASH JOIN | | 50 | 6 | 2 | +0 | 1 | 50 | | | 1MB | | | (Probe) | 6 | TABLE ACCESS FULL | T1 | 10 | 3 | 1 | +0 | 1 | 10 | 2 | 49152 | . | | | (Build) | 7 | TABLE ACCESS FULL | T2 | 50 | 3 | 2 | +0 | 1 | 50 | 2 | 49152 | . | | | (Probe) ===================================================================================================================================================

PostgreSQL 13.4 / pg_hint_plan 1.3.9 / Right Deep Join Tree / Hash Join

OracleとはBuild表の位置が逆なので、OracleのLeft deep join treeの実行計画に読み間違えそうですがw PostgreSQLのRight Deep Join Treeだとこのような実行計画として表示されます。
Oracleでは、Id=6でT1がBuild表になり、Id=7のt2(Probe)と結合するように表現されますが、
PostgreSQLでは、 ★ で示した行で、t1が、Seq ScansされてHash表が作成されている。つまり、Build表になっており、t2(Probe)と結合されています。Oracleの感覚で読んでしまうと、あれ？　となるところだと思います。
t3, t4から、それぞれ、Hash表が作成されているので、Buildになっていることがわかります:)　
同じ実行計画になるようにしてみましたが、実行計画の見せ方では、Oracle/PostgreSQLでは差異がありますよね。ただ、MySQLのTree表示もPostgreSQLに類似しているので、PostgreSQLのに慣れてると、MySQLのTree formatの実行計画は読みやすいかもしれません）

Orableのように、SWAP_JOIN_INPUTSヒントでBuild/Probeを制御するヒントが存在しないので、代わりに、LeadingヒントのLeading()構文を利用して制御しています。OracleのLEADING + SWAP_JOIN_JOINPSと比べると可読性は劣化する（個人の感想です）の使い方が難しいく感じますね。慣れなのかなぁ。これ。

（実行計画の左端に (Build) なのか、　(Probe)　を確認しやすいようにコメントを付加しています）

perftestdb=> \! cat pg_sql_rightdj.sql explain (analyze) SELECT /*+ Leading((((t2 t1) t3) t4)) HashJoin(t1 t2 t3 t4) */ t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id ; perftestdb=> \i pg_sql_rightdj.sql QUERY PLAN ---------------------------------------------------------------------------------------------------------------------- Hash Join (cost=18.73..308.66 rows=25000 width=36) (actual time=3.352..8.740 rows=25000 loops=1) Hash Cond: (t1.id = t4.id) (Probe) -> Hash Join (cost=4.47..11.91 rows=500 width=32) (actual time=2.316..2.460 rows=500 loops=1) Hash Cond: (t1.id = t3.id) (Probe) -> Hash Join (cost=1.23..2.91 rows=50 width=20) (actual time=1.534..1.562 rows=50 loops=1) Hash Cond: (t2.id = t1.id) (Probe) -> Seq Scan on t2 (cost=0.00..1.50 rows=50 width=12) (actual time=0.744..0.750 rows=50 loops=1) (Build) -> Hash (cost=1.10..1.10 rows=10 width=8) (actual time=0.723..0.724 rows=10 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 9kB ★ -> Seq Scan on t1 (cost=0.00..1.10 rows=10 width=8) (actual time=0.705..0.707 rows=10 loops=1) (Build) -> Hash (cost=2.00..2.00 rows=100 width=12) (actual time=0.760..0.761 rows=100 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 13kB -> Seq Scan on t3 (cost=0.00..2.00 rows=100 width=12) (actual time=0.715..0.732 rows=100 loops=1) (Build) -> Hash (cost=8.00..8.00 rows=500 width=16) (actual time=1.012..1.013 rows=500 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 32kB -> Seq Scan on t4 (cost=0.00..8.00 rows=500 width=16) (actual time=0.792..0.905 rows=500 loops=1)

MySQL 8.0.32 / Right Deep Join Tree / Hash Join
できないので、なし。

次、みんさんが、見慣れている（？）、Left Deep Join Tree にすると Hash Join の実行計画は、それぞれどのように見えるのでしょうか？　比較してみましょう。

Oraclerには、わかりやすいですよね(慣れの問題かもしれませんけどもw) 。Id=4で、t1がBuild表となってt2(Probe)と結合。。。以下、t3, t4がそれぞれ、ProbeとしてHash Joinされています。
Oracle 21 / Left Deep Join Tree / Hash Join

Id=4でt1がtable full scan(Build)で、ID=5 のt2 (Probe) と結合されています。t3, t4はそれぞれのProbeとなっていることが読み取れます。;)

（実行計画の右端に (Build) なのか、　(Probe)　を確認しやすいようにコメントを付加しています）

SCOTT@orclpdb1> @ora_sql_leftdj.sql 1 SELECT 2 /*+ 3 MONITOR 4 LEADING(t1 t2 t3 t4) 5 USE_HASH(t1 t2 t3 t4) 6 NO_SWAP_JOIN_INPUTS(t4) 7 */ 8 t1.id 9 , t1.t1_c1 10 , t2.s_id 11 , t2.t2_c1 12 , t3.b_id 13 , t3.t3_c1 14 , t4.a_id 15 , t4.c_id 16 , t4.t4_c1 17 FROM 18 t1 19 INNER JOIN t2 20 ON 21 t1.id = t2.idv 22 INNER JOIN t3 23 ON 24 t1.id = t3.id 25 INNER JOIN t4 26 ON 27* t1.id = t4.id ...略... SQL Plan Monitoring Details (Plan Hash Value=894925296) ==================================================================================================================================== | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Mem | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | (Max) | (%) | (# samples) | ==================================================================================================================================== | 0 | SELECT STATEMENT | | | | 2 | +0 | 1 | 25000 | . | | | | 1 | HASH JOIN | | 25000 | 12 | 2 | +0 | 1 | 25000 | 1MB | | | | 2 | HASH JOIN | | 500 | 9 | 1 | +0 | 1 | 500 | 1MB | | | (Build) | 3 | HASH JOIN | | 50 | 6 | 1 | +0 | 1 | 50 | 1MB | | | (Build) | 4 | TABLE ACCESS FULL | T1 | 10 | 3 | 1 | +0 | 1 | 10 | . | | | (Build) | 5 | TABLE ACCESS FULL | T2 | 50 | 3 | 1 | +0 | 1 | 50 | . | | | (Probe) | 6 | TABLE ACCESS FULL | T3 | 100 | 3 | 1 | +0 | 1 | 100 | . | | | (Probe) | 7 | TABLE ACCESS FULL | T4 | 500 | 3 | 2 | +0 | 1 | 500 | . | | | (Probe) ====================================================================================================================================

PostgreSQL 13.4 / pg_hint_plan 1.3.9 / Left Deep Join Tree / Hash Join
★ のある行で、t1がSeq Scanされ、その上位の行で、Hashが作成されているので、Buildとなっていることがわかります。次に、同一階層で t2がSeq ScanされHash Joinされています。
t3, t4はそれぞれProbeになっていることが読み取れます。ぱっと見は、Oracleの ight Deep Join Tree で見られる実行計画の形に似てますが。。。(^^;;;;

（実行計画の左端に (Build) なのか、　(Probe)　を確認しやすいようにコメントを付加しています）

perftestdb=> \! cat pg_sql_leftdj.sql explain (analyze) SELECT /*+ Leading((t4 (t3 (t2 t1)))) HashJoin(t2 t1 t3 t4) */ t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id ; perftestdb=> perftestdb=> \i pg_sql_leftdj.sql QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------- Hash Join (cost=17.66..308.16 rows=25000 width=36) (actual time=0.522..8.362 rows=25000 loops=1) Hash Cond: (t4.id = t1.id) (Probe) -> Seq Scan on t4 (cost=0.00..8.00 rows=500 width=16) (actual time=0.012..0.101 rows=500 loops=1) (Build) -> Hash (cost=11.41..11.41 rows=500 width=32) (actual time=0.462..0.467 rows=500 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 40kB -> Hash Join (cost=3.54..11.41 rows=500 width=32) (actual time=0.122..0.328 rows=500 loops=1) Hash Cond: (t3.id = t1.id) (Probe) -> Seq Scan on t3 (cost=0.00..2.00 rows=100 width=12) (actual time=0.004..0.017 rows=100 loops=1) (Build) -> Hash (cost=2.91..2.91 rows=50 width=20) (actual time=0.098..0.102 rows=50 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 11kB -> Hash Join (cost=1.23..2.91 rows=50 width=20) (actual time=0.039..0.068 rows=50 loops=1) Hash Cond: (t2.id = t1.id) (Probe) -> Seq Scan on t2 (cost=0.00..1.50 rows=50 width=12) (actual time=0.005..0.011 rows=50 loops=1) (Build) -> Hash (cost=1.10..1.10 rows=10 width=8) (actual time=0.016..0.018 rows=10 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 9kB ★ -> Seq Scan on t1 (cost=0.00..1.10 rows=10 width=8) (actual time=0.003..0.004 rows=10 loops=1)

MySQL 8.0.32 / Left Deep Join Tree / Hash Join
これは、前回のエントリーでも紹介した無理やり Hash Join にした例なので、特に解説はしませんが、PostgreSQLに類似した実行計画になっていますよね。

現状、MySQLは、HASH JOIN を強制するヒント、Build/Probeを制御するヒント、PostgreSQLのように結合順の優先順位を細かく指定するヒントもないため、Nested Loop Join にならないようヒントで制御するしか Hash Join を強制する方法はなさそうです。
Left Deep Join Tree にしかならないのでこともあり、Hash Join で、 Bushy Join Treeや、Right Deep Join Treeのようなチューニングはできないですね。

実際、関わった案件で、Hash Join が選択されたのは良いと思うけど、Build/Probeを入れ替えられたら、もっとサクッと終わるはずなのに、と言う状況になって初めて、この事実を知りました。（なので、このエントリー書いているのですけどもw）
できないのかよ。。とw

以下実行計画の ★ を付与した行で、t1がTable Scanされ、その上位の行で、Hashが作成されているので、Buildとなっていることがわかります。次に、同一階層で t2がTable Scan後に、Hash Joinされています。
t3, t4は、Probeになっていることも読み取れます。PostgreSQLの実行計画の表示方法に類似してますよね。

（実行計画の左端に (Build) なのか、　(Probe)　を確認しやすいようにコメントを付加しています）

mysql> \! cat my_sql_leftdj.sql explain analyze SELECT /*+ JOIN_ORDER(t1,t2,t3,t4) NO_JOIN_INDEX(t2 primary) NO_JOIN_INDEX(t3 primary) NO_JOIN_INDEX(t4 primary) */ t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id ; mysql> \. my_sql_leftdj.sql +-----------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +-----------------------------------------------------------------------------------------------------------------------+ | -> Inner hash join (t4.id = t1.id) (cost=25552.55 rows=25000) (actual time=0.643..5.045 rows=25000 loops=1) (Probe) -> Table scan on t4 (cost=0.01 rows=500) (actual time=0.052..0.346 rows=500 loops=1) (Build) -> Hash -> Inner hash join (t3.id = t1.id) (cost=551.75 rows=500) (actual time=0.216..0.380 rows=500 loops=1) (Probe) -> Table scan on t3 (cost=0.03 rows=100) (actual time=0.041..0.069 rows=100 loops=1) (Build) -> Hash -> Inner hash join (t2.id = t1.id) (cost=51.50 rows=50) (actual time=0.100..0.141 rows=50 loops=1) (Probe) -> Table scan on t2 (cost=0.08 rows=50) (actual time=0.026..0.041 rows=50 loops=1) (Build) -> Hash ★ -> Table scan on t1 (cost=1.25 rows=10) (actual time=0.039..0.047 rows=10 loops=1) | +-----------------------------------------------------------------------------------------------------------------------+

Bushy Joinのも書こうと思ってましたが、前回ので十分そうなので、省略。（Left/Right Join Treeのミックスですし）MySQLは、Right Deep Join Treeにはならないので、結果なしです。

と言うことで、
Advent Calendar 2023 / Day 17向けの準備運動的な予習（その３）はここまで。

では、また。

関連エントリー

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)
・標準はあるにはあるが癖の多いSQL 全部俺　おまけ SQL de 湯婆婆やるにも癖がでるw
・帰ってきた！標準はあるにはあるが癖の多いSQL #1 SQL de ROT13 やるにも癖が出るw
・帰ってきた！標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #3 オプティマイザの結合順評価テーブル数上限にも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #4 Optimizer Traceの取得でも癖がでる
・帰ってきた！標準はあるにはあるが癖の多いSQL #5 - Optimizer Hint でも癖が多い
・帰ってきた！標準はあるにはあるが癖の多いSQL #6 - Hash Joinの結合ツリーにも癖がでる

投稿日時 2023年12月10日 (日) 11時25分 Oracle, チューニング, SQL, MySQL, PostgreSQL, パフォーマンス, Advent Calendar | 固定リンク | 0 | コメント (0)

2023年12月 9日 (土)

帰ってきた！標準はあるにはあるが癖の多いSQL #6 - Hash Joinの結合ツリーにも癖がでる

本エントリーは、MySQL Advent Calendar 2023 シリーズ2 / Day 9とPostgreSQL Advent Calendar 2023 シリーズ2 / Day 9へのクロスポスト、および、JPOUG Advent Calendar 2023 / Day 9 の裏番組　（ADVENTARはシリーズ増やせないので）　エントリーで、12/17日向けの　予習　その２　という位置付けのエントリーです。

予習　その１は、以下。
帰ってきた！標準はあるにはあるが癖の多いSQL #5 - Optimizer Hint でも癖が多い

少し前に、MySQLでもHash Joinになるんだね。といいうエントリーを書きました。覚えてますか？　
MySQL 8.0.32では NLJに使えるINDEXが存在していても、Hash Joinをヒントで強制することができる！（オプティマイザが選択することもある！）

その時点では、

MySQLのHash Joinを強制するオプティマイザーヒントも廃止されているようだし、Build/Probeの制御もできないよね？ヒントないし。
とか、
オプティマイザーヒントで強制できないけど、オプティマイザーが勝手に選んじゃうこともあるのか〜、NLJに利用できる索引あっても。。
勝手に選ばれることはあってもヒントではもろもろ制御できない。最初に戻る。

という状況ループ状態でしたw

そこで、閃いたのが、MySQLで、Hash Joinが自動発動する条件。その条件に合う状況にすればいいじゃん。と！
Hash Joinを強制するヒントはなくても、Nested Loop Joinに使ってる主索引（MySQLの場合は主キーはクラスター索引）を、オプティマイザーヒントで無効化してしまえば、勝手に、Hash Joinするよね！？　

という確認ばかりに目が行ってしまって、気づきませんでした！！！！

MySQLのHash Joinの実行計画ツリーを見て、Oracle/PostgreSQLと違う点、何か気づきませんか？　
みなさん！　これ試験に出ますよw（嘘
答え合わせは後半でw

それでは、環境づくりから（少々長めですw）
それぞれの DB（ Oracle Database 21c / PostgreSQL 13.4 with pg_hint_plan 1.3.9 / MySQL 8.0.32 ）で、そのまま実行できるDDLにしてあります。
表と索引作成（各DB共通）、データ登録、そして、統計取得まで行っています。

Oracle/PostgreSQL/MySQL共通DDL

cre_advent_tabs.sql -- 10 rows CREATE TABLE t1 ( id INT NOT NULL , t1_c1 INT NOT NULL , CONSTRAINT t1_pk PRIMARY KEY (id) ); -- 50 rows CREATE TABLE t2 ( id INT NOT NULL , s_id INT NOT NULL , t2_c1 INT NOT NULL , CONSTRAINT t2_pk PRIMARY KEY (id, s_id) ); -- 100 rows CREATE TABLE t3 ( id INT NOT NULL , b_id INT NOT NULL , t3_c1 INT NOT NULL , CONSTRAINT t3_pk PRIMARY KEY (id, b_id) ); -- 500 rows CREATE TABLE t4 ( id INT NOT NULL , a_id INT NOT NULL , c_id INT NOT NULL , t4_c1 INT NOT NULL , CONSTRAINT t4_pk PRIMARY KEY (id, a_id, c_id) ); -- 1000 rows CREATE TABLE t0 ( id INT NOT NULL , m_id INT NOT NULL , t0_c1 INT NOT NULL , CONSTRAINT t0_pk PRIMARY KEY (id, m_id) );

Oracle 21c向けデータ登録と統計取得からデータ件数確認までのスクリプトと実行例

make_data4oracle.sql -- for t1 BEGIN FOR i IN 1..10 LOOP INSERT INTO t1 VALUES(i,i); END LOOP; COMMIT; DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'T1', cascade=>true, no_invalidate=>false); END; / SELECT COUNT(1) FROM t1; -- for t2 BEGIN FOR i IN 1..10 LOOP FOR j IN 1..5 LOOP INSERT INTO t2 VALUES(i,j,i+j); END LOOP; END LOOP; COMMIT;v DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'T2', cascade=>true, no_invalidate=>false); END; / SELECT COUNT(1) FROM t2; -- for t3 BEGINv FOR i IN 1..10 LOOP FOR j IN 1..10 LOOP INSERT INTO t3 VALUES(i,j,i+j); END LOOP; END LOOP; COMMIT; DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'T3', cascade=>true, no_invalidate=>false); END; / SELECT COUNT(1) FROM t3; -- for t4 BEGIN FOR i IN 1..10 LOOP FOR j IN 1..10 LOOP FOR k IN 1..5 LOOP INSERT INTO t4 VALUES(i,j,k,i+j); END LOOP; END LOOP; COMMIT; END LOOP; DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'T4', cascade=>true, no_invalidate=>false); END; / SELECT COUNT(1) FROM t4; -- for t0 BEGIN FOR i IN 1..10 LOOP FOR j IN 1..100 LOOP INSERT INTO t0 VALUES(i,j,i+j); END LOOP; COMMIT; END LOOP; DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCOTT', tabname=>'T0', cascade=>true, no_invalidate=>false); END; / SELECT COUNT(1) FROM t0;

SCOTT@orclpdb1> @make_data4oracle PL/SQLプロシージャが正常に完了しました。 COUNT(1) ---------- 10 PL/SQLプロシージャが正常に完了しました。 COUNT(1) ---------- 50 PL/SQLプロシージャが正常に完了しました。 COUNT(1) ---------- 100 PL/SQLプロシージャが正常に完了しました。 COUNT(1) ---------- 500 PL/SQLプロシージャが正常に完了しました。 COUNT(1) ---------- 1000

PostgreSQL 13.4向けデータ登録と統計取得からデータ件数確認までのスクリプトと実行例

perftestdb=> \i cre_advent_tabs.sql CREATE TABLE CREATE TABLE CREATE TABLE CREATE TABLE CREATE TABLE perftestdb=>

PostgreSQL向けデータ登録と統計取得からデータ件数確認までのスクリプトと実行例

make_data4postgresql.sql -- for t1 DO $$ BEGIN FOR i IN 1..10 LOOP INSERT INTO t1 VALUES(i,i); END LOOP; COMMIT; END $$ ; VACUUM VERBOSE ANALYZE t1; SELECT COUNT(1) FROM t1; -- for t2 DO $$ BEGIN FOR i IN 1..10 LOOP FOR j IN 1..5 LOOP INSERT INTO t2 VALUES(i,j,i+1); END LOOP; END LOOP; COMMIT; END $$ ; VACUUM VERBOSE ANALYZE t2; SELECT COUNT(1) FROM t2; -- for t3 DO $$ BEGIN FOR i IN 1..10 LOOP FOR j IN 1..10 LOOP INSERT INTO t3 VALUES(i,j,i+1); END LOOP; END LOOP; COMMIT; END $$ ; VACUUM VERBOSE ANALYZE t3; SELECT COUNT(1) FROM t3; -- for t4 DO $$ BEGIN FOR i IN 1..10 LOOP FOR j IN 1..10 LOOP FOR k IN 1..5 LOOP INSERT INTO t4 VALUES(i,j,k,i+j); END LOOP; END LOOP; COMMIT; END LOOP; END $$ ; VACUUM VERBOSE ANALYZE t4; SELECT COUNT(1) FROM t4; -- for t0 DO $$ BEGIN FOR i IN 1..10 LOOP FOR j IN 1..100 LOOP INSERT INTO t0 VALUES(i,j,i+j); END LOOP; COMMIT; END LOOP; END $$ ; VACUUM VERBOSE ANALYZE t0; SELECT COUNT(1) FROM t0;

perftestdb=> \i make_data4postgresql.sql DO psql:make_data4postgresql.sql:12: INFO: vacuuming "public.t1" psql:make_data4postgresql.sql:12: INFO: "t1": found 0 removable, 10 nonremovable row versions in 1 out of 1 pages DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 530026 There were 0 unused item identifiers. Skipped 0 pages due to buffer pins, 0 frozen pages. 0 pages are entirely empty. CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. psql:make_data4postgresql.sql:12: INFO: analyzing "public.t1" psql:make_data4postgresql.sql:12: INFO: "t1": scanned 1 of 1 pages, containing 10 live rows and 0 dead rows; 10 rows in sample, 10 estimated total rows VACUUM count ------- 10 (1 行) DO psql:make_data4postgresql.sql:30: INFO: vacuuming "public.t2" psql:make_data4postgresql.sql:30: INFO: "t2": found 0 removable, 50 nonremovable row versions in 1 out of 1 pages DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 530028 There were 0 unused item identifiers. Skipped 0 pages due to buffer pins, 0 frozen pages. 0 pages are entirely empty. CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. psql:make_data4postgresql.sql:30: INFO: analyzing "public.t2" psql:make_data4postgresql.sql:30: INFO: "t2": scanned 1 of 1 pages, containing 50 live rows and 0 dead rows; 50 rows in sample, 50 estimated total rows VACUUM count ------- 50 (1 行) DO psql:make_data4postgresql.sql:48: INFO: vacuuming "public.t3" psql:make_data4postgresql.sql:48: INFO: "t3": found 0 removable, 100 nonremovable row versions in 1 out of 1 pages DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 530030 There were 0 unused item identifiers. Skipped 0 pages due to buffer pins, 0 frozen pages. 0 pages are entirely empty. CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. psql:make_data4postgresql.sql:48: INFO: analyzing "public.t3" psql:make_data4postgresql.sql:48: INFO: "t3": scanned 1 of 1 pages, containing 100 live rows and 0 dead rows; 100 rows in sample, 100 estimated total rows VACUUM count ------- 100 (1 行) DO psql:make_data4postgresql.sql:67: INFO: vacuuming "public.t4" psql:make_data4postgresql.sql:67: INFO: "t4": found 0 removable, 500 nonremovable row versions in 3 out of 3 pages DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 530041 There were 0 unused item identifiers. Skipped 0 pages due to buffer pins, 0 frozen pages. 0 pages are entirely empty. CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. psql:make_data4postgresql.sql:67: INFO: analyzing "public.t4" psql:make_data4postgresql.sql:67: INFO: "t4": scanned 3 of 3 pages, containing 500 live rows and 0 dead rows; 500 rows in sample, 500 estimated total rows VACUUM count ------- 500 (1 行) DO psql:make_data4postgresql.sql:85: INFO: vacuuming "public.t0" psql:make_data4postgresql.sql:85: INFO: "t0": found 0 removable, 1000 nonremovable row versions in 6 out of 6 pages DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 530052 There were 0 unused item identifiers. Skipped 0 pages due to buffer pins, 0 frozen pages. 0 pages are entirely empty. CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s. psql:make_data4postgresql.sql:85: INFO: analyzing "public.t0" psql:make_data4postgresql.sql:85: INFO: "t0": scanned 6 of 6 pages, containing 1000 live rows and 0 dead rows; 1000 rows in sample, 1000 estimated total rows VACUUM count ------- 1000 (1 行)

MySQL 8.0.32向けデータ登録と統計取得からデータ件数確認までのスクリプトと実行例

mysql> \. cre_advent_tabs.sql Query OK, 0 rows affected (0.06 sec) Query OK, 0 rows affected (0.05 sec) Query OK, 0 rows affected (0.05 sec) Query OK, 0 rows affected (0.04 sec) Query OK, 0 rows affected (0.07 sec) mysql>

MySQL向けデータ登録と統計取得からデータ件数確認までのスクリプトと実行例

make_data4mysql.sql DELIMITER // CREATE PROCEDURE make_data4mysql() BEGIN DECLARE i, j, k INT; -- for t1 SET i = 1; WHILE i <= 10 DO INSERT INTO t1 VALUES(i,i); SET i = i + 1; END WHILE; COMMIT; -- for t2 SET i = 1; WHILE i <= 10 DO SET j = 1; WHILE j <= 5 DO INSERT INTO t2 VALUES(i,j,i+1); SET j = j + 1; END WHILE; SET i = i + 1; END WHILE; COMMIT; -- for t3 SET i = 1; WHILE i <= 10 DO SET j = 1; WHILE j <= 10 DO INSERT INTO t3 VALUES(i,j,i+1); SET j = j + 1; END WHILE; SET i = i + 1; END WHILE; COMMIT; -- for t4 SET i = 1; WHILE i <= 10 DO SET j = 1; WHILE j <= 10 DO SET k = 1; WHILE k <= 5 DO INSERT INTO t4 VALUES(i,j,k,i+j); SET k = k + 1; END WHILE; SET j = j + 1; END WHILE; SET i = i + 1; COMMIT; END WHILE; -- for t0 SET i = 1; WHILE i <= 10 DO SET j = 1; WHILE j <= 100 DO INSERT INTO t0 VALUES(i,j,i+j); SET j = j + 1; END WHILE; SET i = i + 1; COMMIT; END WHILE; END // DELIMITER ; CALL make_data4mysql(); ANALYZE TABLE t1, t2, t3, t4, t0; SELECT COUNT(1) FROM t1; SELECT COUNT(1) FROM t2; SELECT COUNT(1) FROM t3; SELECT COUNT(1) FROM t4; SELECT COUNT(1) FROM t0; DROP PROCEDURE make_data4mysql;

mysql> \. make_data4mysql.sql Query OK, 0 rows affected (0.03 sec) Query OK, 0 rows affected (11.20 sec) +---------------+---------+----------+----------+ | Table | Op | Msg_type | Msg_text | +---------------+---------+----------+----------+ | perftestdb.t1 | analyze | status | OK | | perftestdb.t2 | analyze | status | OK | | perftestdb.t3 | analyze | status | OK | | perftestdb.t4 | analyze | status | OK | | perftestdb.t0 | analyze | status | OK | +---------------+---------+----------+----------+ 5 rows in set (0.07 sec) +----------+ | COUNT(1) | +----------+ | 10 | +----------+ 1 row in set (0.01 sec) +----------+ | COUNT(1) | +----------+ | 50 | +----------+ 1 row in set (0.00 sec) +----------+ | COUNT(1) | +----------+ | 100 | +----------+ 1 row in set (0.02 sec) +----------+ | COUNT(1) |v+----------+ | 500 | +----------+ 1 row in set (0.01 sec) +----------+ | COUNT(1) | +----------+ | 1000 | +----------+ 1 row in set (0.02 sec) Query OK, 0 rows affected (0.01 sec) mysql>
準備できた！

実行計画を理解するための参考
（Oracleのマニュアルで解説されているBushy Join Treeは、Zigzag Join Treeと言われている結合ツリーに見えますよね。Oracleは、Bushy/Zigzagは区別してなさそう）

参考）
Hash JoinのBuild/Probeって何？　という方は、以下も読んでおくと良いです

Oracle Database Release 23 / SQL Tuning Guide - 9.2.2.2.2 Hash Join: Basic Steps

https://docs.oracle.com/en/database/oracle/oracle-database/23/tgsql/joins.html#GUID-9EE5CD4C-B90C-4E61-83DC-BD585D79635C

結合ツリーついて

Oracle Database Release 23 / SQL Tuning Guide - 9.1.1 Join Trees

https://docs.oracle.com/en/database/oracle/oracle-database/23/tgsql/joins.html#GUID-31B0F249-A5AA-41E9-AE98-A484FC5C487C

では最初に、Oracle Database 21cから。
それっぽいの形にしたHash Joinの実行計画をお見せします。
これは、Oracleのマニュアルで言うと、Bushy Join Tree です。

SCOTT@orclpdb1> @ora_sql_hj.sql 1 SELECT 2 /*+ 3 MONITOR 4 USE_HASH(t1 t2 t3 t4) 5 */ 6 t1.id 7 , t1.t1_c1 8 , t2.s_id 9 , t2.t2_c1 10 , t3.b_id 11 , t3.t3_c1 12 , t4.a_id 13 , t4.c_id 14 , t4.t4_c1 15 FROM 16 t1 17 INNER JOIN t2 18 ON 19 t1.id = t2.id 20 INNER JOIN t3 21 ON 22 t1.id = t3.id 23 INNER JOIN t4 24 ON 25* t1.id = t4.id ...略... SQL Plan Monitoring Details (Plan Hash Value=122725940) =================================================================================================================================================== | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Read | Read | Mem | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | Reqs | Bytes | (Max) | (%) | (# samples) | =================================================================================================================================================== | 0 | SELECT STATEMENT | | | | 1 | +0 | 1 | 25000 | | | . | | | | 1 | HASH JOIN | | 25000 | 12 | 1 | +0 | 1 | 25000 | | | 1MB | | | | 2 | TABLE ACCESS FULL | T4 | 500 | 3 | 1 | +0 | 1 | 500 | 2 | 49152 | . | | | | 3 | HASH JOIN | | 500 | 9 | 1 | +0 | 1 | 500 | | | 1MB | | | | 4 | HASH JOIN | | 50 | 6 | 1 | +0 | 1 | 50 | | | 1MB | | | | 5 | TABLE ACCESS FULL | T1 | 10 | 3 | 1 | +0 | 1 | 10 | 2 | 49152 | . | | | | 6 | TABLE ACCESS FULL | T2 | 50 | 3 | 1 | +0 | 1 | 50 | 2 | 49152 | . | | | | 7 | TABLE ACCESS FULL | T3 | 100 | 3 | 1 | +0 | 1 | 100 | 2 | 49152 | . | | | ===================================================================================================================================================

上記の解説

Id=5 T1をTable Full Scan (Build表)
Id=6 T2をTable Full Scan (Probe表).
Id=4 T1とT2をHash Join (on memoryでHash Join完了）

Id=4 Id=5,6のHash Joinの結果(Build表)
Id=7 T3をTable Full Scan (Probe表)
Id=3 Id=4の結合結果とT3をHash Join (on memoryでHash Join完了）

Id=2 T4をTable Full Scan (Build表)
Id=3 Id=4の結合結果とT3の結合結果 (Probe表)
Id=2 T4とId=3の結合結果をHash Join (On memoryでHash Join完了）

という順序なので、
引用したOracleのマニュアルで言う、Bushy Join Tree になっています。
Oracleのマニュアルでは、Bushy Join Treeとなっていますが、他では、Zigzag Join Treeとして分類されていたりするツリーです。。LeftとRight Deep Join TreeがMixされた形ですよね、これ。

これを結合ツリーで書くと、以下のようになります。

次は、PostgreSQL 13.4 with pg_hint_plan 1.3.9で同じくHash Joinになるようにヒントで強制した実行計画です。

この結合ツリーは、Bushy Join Treeですね。

perftestdb=> \! cat pg_sql_hj.sql explain (analyze) SELECT /*+ HashJoin(t1 t2 t3 t4) */ t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id ; perftestdb=> \i pg_sql_hj.sql QUERY PLAN ----------------------------------------------------------------------------------------------------------------------- Id=1 Hash Join (cost=17.48..309.84 rows=25000 width=36) (actual time=3.405..10.466 rows=25000 loops=1) Hash Cond: (t1.id = t2.id) Id=2 -> Hash Join (cost=1.23..11.09 rows=500 width=24) (actual time=1.696..1.989 rows=500 loops=1) Hash Cond: (t4.id = t1.id) Id=3 -> Seq Scan on t4 (cost=0.00..8.00 rows=500 width=16) (actual time=0.907..0.993 rows=500 loops=1) Id=4 -> Hash (cost=1.10..1.10 rows=10 width=8) (actual time=0.721..0.722 rows=10 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 9kB Id=5 -> Seq Scan on t1 (cost=0.00..1.10 rows=10 width=8) (actual time=0.705..0.707 rows=10 loops=1) Id=6 -> Hash (cost=10.00..10.00 rows=500 width=24) (actual time=1.687..1.687 rows=500 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 36kB Id=7 -> Hash Join (cost=2.12..10.00 rows=500 width=24) (actual time=1.400..1.554 rows=500 loops=1) Hash Cond: (t3.id = t2.id) Id=8 -> Seq Scan on t3 (cost=0.00..2.00 rows=100 width=12) (actual time=0.701..0.712 rows=100 loops=1) Id=9 -> Hash (cost=1.50..1.50 rows=50 width=12) (actual time=0.679..0.680 rows=50 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 11kB Id=10 -> Seq Scan on t2 (cost=0.00..1.50 rows=50 width=12) (actual time=0.648..0.656 rows=50 loops=1)

解説しやすいように実行計画のノードにIdを振っています:)

Oracleの実行計画と大きく違うのは、Build表とProbe表の順序です。Oracleの場合、同一階層の上位が、Build表で、その下にProbe表がリストされますが、
PostgreSQL(MySQLも同様）では、同一階層上で、Probe表が上位に、その下に Hash（ハッシュ表を作成している操作。Oracleでは実行計画上この操作は現れません）、さらにその下位階層にBuild表のTable Full scanという形で表現されています。
階層の一番深い部分から実行されるので、上記例だと、Id=16のt2（Build表）のSeq Scan (Oracleで言うTable Full Scanが最初に実行され、次に、Id=15のHashが行われていることがわかります。

Id=10 t2 Seq Scan (Oracleで言うTable Full Scan)
Id=9 Id=10の結果を元にHash表作成　（つまり、t2がBuild)
Id=8 t3 Seq Scan (Probe)
Id=7 t2, t3をHash Join

Id=6 Id=7(t2, t3のHash Join)の結果を元にHash表作成（Build)

Id=5 t1 Seq Scan
Id=4 Id=5の結果を元にHash表作成（Build）
Id=3 t4 Seq Scan (Probe)
Id=2 t1, t4をHash Join

Id=1 Id=6の結果(Build), Id=2の結果（Probe)としてHash Join

こうやって1Step毎に追っていくと、OracleとPostgreSQLの実行計画のTree listで、Hash JoinのBuildとProbeの位置が異なっていることに気づきやすいですよね。（ちなみに、MySQLのTree formatも同様です）

これを結合ツリーで書くと、以下のようになります。

最後に、MySQL 8.0.32です。
Hash Joinを強制する直接的なヒントも、Budling/Probe表を制御するヒントも方法存在しませんが、Hash Joinになるよう結合順を指定した上で、Nested Loop Joinになってしまうのを抑止するために、Nested Loop Joindで利用する主キー索引の利用を抑止しました。
（MySQLの主キーはクラスター索引なので、主キーがNested Loop Joinに利用される場合、索引の利用を抑止するには、NO_JOIN_INDEXヒントで primary を指定する必要があります）

なお、JOIN_ORDERヒントで結合順を指定した理由は、結合順を指定することでNested Loop Joinに利用される主キー(primary)を、NO_JOIN_INDEXヒントで確実抑止したかったためです。

ちなみに、この結合ツリーは、Left Deep Join Treeですね。

mysql> \! cat my_sql_leftdj.sql explain analyze SELECT /*+ JOIN_ORDER(t1,t2,t3,t4) NO_JOIN_INDEX(t2 primary) NO_JOIN_INDEX(t3 primary) NO_JOIN_INDEX(t4 primary) */ t1.id , t1.t1_c1 , t2.s_id , t2.t2_c1 , t3.b_id , t3.t3_c1 , t4.a_id , t4.c_id , t4.t4_c1 FROM t1 INNER JOIN t2 ON t1.id = t2.id INNER JOIN t3 ON t1.id = t3.id INNER JOIN t4 ON t1.id = t4.id ; mysql> \. my_sql_leftdj.sql +-----------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +-----------------------------------------------------------------------------------------------------------------------+ Id=1 | -> Inner hash join (t4.id = t1.id) (cost=25552.55 rows=25000) (actual time=0.643..5.045 rows=25000 loops=1) Id=2 -> Table scan on t4 (cost=0.01 rows=500) (actual time=0.052..0.346 rows=500 loops=1) Id=3 -> Hash Id=4 -> Inner hash join (t3.id = t1.id) (cost=551.75 rows=500) (actual time=0.216..0.380 rows=500 loops=1) Id=5 -> Table scan on t3 (cost=0.03 rows=100) (actual time=0.041..0.069 rows=100 loops=1) Id=6 -> Hash Id=7 -> Inner hash join (t2.id = t1.id) (cost=51.50 rows=50) (actual time=0.100..0.141 rows=50 loops=1) Id=8 -> Table scan on t2 (cost=0.08 rows=50) (actual time=0.026..0.041 rows=50 loops=1) Id=9 -> Hash Id=10 -> Table scan on t1 (cost=1.25 rows=10) (actual time=0.039..0.047 rows=10 loops=1) | +-----------------------------------------------------------------------------------------------------------------------+

既にお分かりだと思いますが、答え合わせです。:)

OracleのRight Deep Joinに見慣れている皆さん（私も含むw）が、Right Deep Joinと勘違いしちゃうケースはありますが、Build表とProbe表の現れる位置が、Oracleの実行計画と逆なんですよね。
（何度見ても、OracleでRight Deep Join Treeにした実行計画の形とダブってしまって、慣れないw）
このような形になっているHash Joinの実行計画って、PostgreSQLも含め、Left Deep Join Treeなんですよね。

参考）MySQLが、Left Deep Join Treeにしかならない理由はこれ。
Chapter 4. Query Performance Optimization The execution plan
https://www.oreilly.com/library/view/high-performance-mysql/9780596101718/ch04.html#how_mysql_joins_multiple_table
"MySQL always begins with one table and finds matching rows in the next table. Thus, MySQL’s query execution plans always take the form of a left-deep tree"とあります。

Nested Loop Joinって、Left Deep Join Treeになるから、MySQLだとHash Joinでも、 Left Deep Join Treeなのかなぁ。と。ただ、一時期、クラウド方面にあるMySQL互換で、HASH_JOIN_BUILDINGとかいうヒントが加えられていたこともありました。NewSQL系でも拡張されているケースもあるようです。

前述のMySQLの実行計画を追っかけてみると、、、

Id=10 t1 Table Scan
Id=11 Id=10で読み込んだ結果からHash表を作成（つまり、t1がBuild）
Id=7,8 T2 Table Scan (Probe）してId=11とHash Join
Id=6 Id=7のHash Joinの結果からHash表作成 (Build）
Id=4,5 T3 Table Scan (Probe)してId=6とHash Join
Id=3 Id=4のHash Joinの結果からHash表作成（Build）
Id=1,2 T4 Table Scan (Probe)しId=3とHash Join

これを結合ツリーで書くと、以下のように Left Deep Treeになりまよね。
（表示されているExlplainの実行計画を見ていると、OracleのHash JoinでRight Deep Join Treeに錯覚してしまうのなんとかならんかねぇ。と思いつつ、慣れるしかないな。と言う答えしか出てこなかった。PostgreSQLも同じ表示方法だし。慣れろ→自分w）

ということで、
MySQLのHash Joinの実行計画ツリーを見て、何か気づきませんか？　
みなさん！　これ試験に出ますよw（嘘

の答えは、

MySQLは、Left Deep Join Tree　しか、しない。でした！

ざっくりとしたまとめ的なやつ
Oracle/PostgreSQL/MySQLそれぞれ、Hash Joinだけを強制して結合順はオプティマイザー任せにした場合。

Oracle/PostgreSQLは、Bushy Join Tree
データ次第では、Left/Right Deep Join Treeの可能性もあるでしょうけども。今回のケースでは、Bushy Join Tree, 細かめに分類すると、Oracleの結合ツリーは、Zigzagですね。ちなみに、Oracleには、BUSHY_JOINというヒントがあったりします（使ったことないけどw）。

MySQLは、Left Deep Join Tree にしかならんよ。と。

以下の方針が変更されない限り、変わることはなさそう。

再掲

https://www.oreilly.com/library/view/high-performance-mysql/9780596101718/ch04.html#how_mysql_joins_multiple_table
"MySQL always begins with one table and finds matching rows in the next table. Thus, MySQL’s query execution plans always take the form of a left-deep tree"

予習、その３へ続く。

では、また。:)

関連エントリー

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)
・標準はあるにはあるが癖の多いSQL 全部俺　おまけ SQL de 湯婆婆やるにも癖がでるw
・帰ってきた！標準はあるにはあるが癖の多いSQL #1 SQL de ROT13 やるにも癖が出るw
・帰ってきた！標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #3 オプティマイザの結合順評価テーブル数上限にも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #4 Optimizer Traceの取得でも癖がでる
・帰ってきた！標準はあるにはあるが癖の多いSQL #5 - Optimizer Hint でも癖が多い

投稿日時 2023年12月 9日 (土) 00時00分 Oracle, チューニング, SQL, MySQL, PostgreSQL, パフォーマンス, Advent Calendar | 固定リンク | 0 | コメント (0)

2023年11月22日 (水)

帰ってきた！標準はあるにはあるが癖の多いSQL #5 - Optimizer Hint でも癖が多い

癖の多いSQLシリーズネタは沢山あるわけですが、今回は、Oracle/PostgreSQL/MySQLで利用可能なオプティマイザヒントのざっくりしたまとめ。

というか、Advent Calendar向けの準備運動的ななエントリーその１. 意味の同じオプティマイザーヒントを使った何かをネタにしようとしてまーすw（その２は、どうするか検討中w）

各DBの Optimizer Hint　(PostgreSQLは、pg_hint_plan拡張機能を利用）の数（特定の最適化の有効化、無効化ヒントはそれぞれ1ヒントとしてカウント。e.g. INDEX, NO_INDEXで2つとカウントする）

Oracle Database 21c : 388

（圧倒的に多いヒント。まあ、Oracle Database 8.1ぐらいからありますからねぇw 様々な最適化を制御できるようになっているということでもあるわけですけども。それにしても多いですね）

PostgreSQL with pg_hint_plan : 26

（pg_hint_planのドキュメントから拾って数得ました。これぐらいなんですね。）

MySQL 8.0.x : 37

（MySQL 8.0の Optimizer Hint には、HASH_JOIN/NO_HASH_JOINのように特定のリリースでしか使えないものなども含まれる）

MySQL系のAurora MySQL compatible, TiDBなどは、独自のヒントをいくつか追加しているものもある。e.g. HASH JOINのBUILD/PROBE表を制御するものなど。。ただし、Aurora MySQLの場合は、Vanila MySQLでHASH_JOINヒントが廃止された影響で、HASH_JOIN_BUILDINGなどの関連ヒントが廃止されるなど、各DB毎に多少温度差のある対応があり、Vanila以外のMySQLを利用する場合には利用可能な Optimizer Hint は個別に調査動作確認しておくことをお勧めする。

参考 Aurora MySQL hints（独自拡張あり）

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.Hints.html

TiDB(独自拡張あり)

https://docs.pingcap.com/ja/tidb/stable/optimizer-hints

YagabyteDB (pg_hint_planを使うようなので、Vanila PostgreSQLと同じ！)

https://docs.yugabyte.com/preview/explore/query-1-performance/pg-hint-plan/

Oracleのマニュアルでは、全量が解説されているわけではないので、v$sql_hintビューを問い合わせた結果も載せておきます。(ドキュメントのリンク貼っても、OracleさんのドキュメントURLって簡単にリンク切れになるのですが、取り敢えず貼っときますw)
YOracle Database 21c SQL Language Reference / Table 2-23 Hints by Functional Category

https://docs.oracle.com/en/database/oracle/oracle-database/21/sqlrf/Comments.html#GUID-D316D545-89E2-4D54-977F-FC97815CD62E__BABEAFGF

中には、黒魔術すぎた影響でw 指定しても無視(ヒントレポートでは、常に Error 扱い)されるヒントもあります( 参考: https://blogs.oracle.com/otnjp/post/tsushima-hakushi-11 )

（10gぐらいまでのSQLチューニング経験者なら一度ぐらいは聞いたことがあるかもしれねい、BYPASS_UJVC ヒントが有名ですね. ちなみに、このヒント単体で使うと単純に無視されヒントレーポートにも現れません。なお、v$sql_hintには残されていますw）

DISCUS@ORCLCDB> select * from v$sql_hint order by name; NAME SQL_FEATURE CLASS INVERSE TARGET_LEVEL PROPERTY VERSION VERSION_OU ---------------------------------------- ------------------------------ ------------------------------ ------------------------------ ------------ ---------- ---------- ---------- ADAPTIVE_PLAN QKSFM_ADAPTIVE_PLAN ADAPTIVE_PLAN NO_ADAPTIVE_PLAN 1 16 12.1.0.2 12.1.0.2 ALL_ROWS QKSFM_ALL_ROWS MODE 1 16 8.1.0 10.2.0.1 ANALYTIC_VIEW_SQL QKSFM_COMPILATION ANALYTIC_VIEW_SQL 2 0 20.1.0 AND_EQUAL QKSFM_AND_EQUAL ACCESS 4 304 8.1.0 8.1.7 ANSI_REARCH QKSFM_ANSI_REARCH ANSI_REARCH NO_ANSI_REARCH 2 16 12.1.0.2 12.1.0.2 ANSWER_QUERY_USING_STATS QKSFM_ANSWER_QUERY_USING_STATS ANSWER_QUERY_USING_STATS NO_ANSWER_QUERY_USING_STATS 2 16 18.1.0 18.1.0 ANTIJOIN QKSFM_TRANSFORMATION ANTIJOIN 2 16 9.0.0 APPEND QKSFM_CBO APPEND NOAPPEND 1 0 8.1.0 APPEND_VALUES QKSFM_CBO APPEND_VALUES NOAPPEND 1 0 11.2.0.1 AUTO_REOPTIMIZE QKSFM_AUTO_REOPT AUTO_REOPTIMIZE NO_AUTO_REOPTIMIZE 1 0 12.1.0.1 AV_CACHE QKSFM_EXECUTION AV_CACHE 2 0 18.1.0 BATCH_TABLE_ACCESS_BY_ROWID QKSFM_EXECUTION BATCH_TABLE_ACCESS_BY_ROWID NO_BATCH_TABLE_ACCESS_BY_ROWID 4 272 12.1.0.1 12.1.0.1 BIND_AWARE QKSFM_CURSOR_SHARING BIND_AWARE NO_BIND_AWARE 1 0 11.1.0.7 BITMAP QKSFM_CBO BITMAP 2 256 8.1.0 8.1.5 BITMAP_AND QKSFM_BITMAP_TREE BITMAP_AND 4 48 12.1.0.1 12.1.0.1 BITMAP_TREE QKSFM_BITMAP_TREE ACCESS 4 304 10.2.0.1 10.2.0.1 BUFFER QKSFM_CBO BUFFER NO_BUFFER 2 0 8.1.5 BUSHY_JOIN QKSFM_BUSHY_JOIN BUSHY_JOIN NO_BUSHY_JOIN 2 16 12.2.0.1 12.2.0.1 BYPASS_RECURSIVE_CHECK QKSFM_ALL BYPASS_RECURSIVE_CHECK 2 0 9.0.0 BYPASS_UJVC QKSFM_CBO BYPASS_UJVC 2 0 8.1.5 CACHE QKSFM_EXECUTION CACHE NOCACHE 4 256 8.1.0 CACHE_CB QKSFM_CBO CACHE_CB NOCACHE 4 256 8.1.5 CARDINALITY QKSFM_STATS CARDINALITY 14 272 9.0.0 CHANGE_DUPKEY_ERROR_INDEX QKSFM_DML CHANGE_DUPKEY_ERROR_INDEX 4 288 11.1.0.7 CHECK_ACL_REWRITE QKSFM_CHECK_ACL_REWRITE CHECK_ACL_REWRITE NO_CHECK_ACL_REWRITE 1 0 11.1.0.6 CHOOSE QKSFM_CHOOSE MODE 1 16 8.1.0 CLUSTER QKSFM_CBO ACCESS 4 272 8.0.0 8.1.7 CLUSTERING QKSFM_CLUSTERING CLUSTERING NO_CLUSTERING 1 0 12.1.0.1 12.1.0.1 CLUSTER_BY_ROWID QKSFM_CBO CLUSTER_BY_ROWID NO_CLUSTER_BY_ROWID 4 272 12.1.0.1 12.1.0.1 COALESCE_SQ QKSFM_COALESCE_SQ COALESCE_SQ NO_COALESCE_SQ 2 16 11.2.0.1 11.2.0.1 COLUMN_STATS QKSFM_STATS TABLE_STATS 1 272 10.1.0.3 CONNECT_BY_CB_WHR_ONLY QKSFM_TRANSFORMATION CONNECT_BY_CB_WHR_ONLY NO_CONNECT_BY_CB_WHR_ONLY 2 16 10.2.0.5 10.2.0.5 CONNECT_BY_COMBINE_SW QKSFM_ALL CONNECT_BY_COMBINE_SW NO_CONNECT_BY_COMBINE_SW 2 16 10.2.0.4 10.2.0.4 CONNECT_BY_COST_BASED QKSFM_TRANSFORMATION CONNECT_BY_COST_BASED NO_CONNECT_BY_COST_BASED 2 16 10.2.0.2 10.2.0.2 CONNECT_BY_ELIM_DUPS QKSFM_ALL CONNECT_BY_ELIM_DUPS NO_CONNECT_BY_ELIM_DUPS 2 16 11.2.0.1 11.2.0.1 CONNECT_BY_FILTERING QKSFM_ALL CONNECT_BY_FILTERING NO_CONNECT_BY_FILTERING 2 16 10.2.0.2 10.2.0.2 CONTAINERS QKSFM_ALL CONTAINERS 1 0 12.2.0.1 12.2.0.1 COST_XML_QUERY_REWRITE QKSFM_COST_XML_QUERY_REWRITE COST_XML_QUERY_REWRITE NO_COST_XML_QUERY_REWRITE 1 0 11.1.0.6 11.1.0.6 CPU_COSTING QKSFM_CPU_COSTING CPU_COSTING NO_CPU_COSTING 2 16 9.0.0 CUBE_AJ QKSFM_JOIN_METHOD ANTIJOIN 2 16 12.1.0.1 12.1.0.1 CUBE_GB QKSFM_CBO CUBE_GB 2 0 8.1.5 CUBE_SJ QKSFM_JOIN_METHOD SEMIJOIN 2 16 12.1.0.1 12.1.0.1 CURRENT_INSTANCE QKSFM_ALL CURRENT_INSTANCE 1 0 18.1.0 CURSOR_SHARING_EXACT QKSFM_CBO CURSOR_SHARING_EXACT 2 0 9.0.0 DAGG_OPTIM_GSETS QKSFM_GROUPING_SET_XFORM DAGG_OPTIM_GSETS NO_DAGG_OPTIM_GSETS 2 0 21.1.0 21.1.0 DATA_SECURITY_REWRITE_LIMIT QKSFM_DATA_SECURITY_REWRITE DATA_SECURITY_REWRITE_LIMIT NO_DATA_SECURITY_REWRITE 1 0 12.1.0.1 12.1.0.1 DATA_VALIDATE QKSFM_EXECUTION DATA_VALIDATE 1 0 12.2.0.1 DBMS_STATS QKSFM_DBMS_STATS DBMS_STATS 1 0 10.2.0.1 DB_VERSION QKSFM_ALL DB_VERSION 1 272 11.1.0.6 11.1.0.6 DECORRELATE QKSFM_DECORRELATE DECORRELATE NO_DECORRELATE 2 16 12.1.0.1 12.1.0.1 DENORM_AV QKSFM_COMPILATION DENORM_AV 2 0 20.1.0 DEREF_NO_REWRITE QKSFM_ALL DEREF_NO_REWRITE 1 0 8.1.0 DISABLE_PARALLEL_DML QKSFM_DML ENABLE_PARALLEL_DML ENABLE_PARALLEL_DML 1 0 11.2.0.4 DIST_AGG_PROLLUP_PUSHDOWN QKSFM_PQ DIST_AGG_PROLLUP_PUSHDOWN NO_DIST_AGG_PROLLUP_PUSHDOWN 2 16 12.2.0.1 12.2.0.1 DML_UPDATE QKSFM_CBO DML_UPDATE 1 0 9.0.0 DOMAIN_INDEX_FILTER QKSFM_CBO DOMAIN_INDEX_FILTER NO_DOMAIN_INDEX_FILTER 4 304 11.1.0.6 11.1.0.6 DOMAIN_INDEX_NO_SORT QKSFM_CBO DOMAIN_INDEX_SORT DOMAIN_INDEX_SORT 2 0 8.1.5 10.2.0.1 DOMAIN_INDEX_SORT QKSFM_CBO DOMAIN_INDEX_SORT DOMAIN_INDEX_NO_SORT 2 0 8.1.5 10.2.0.1 DRIVING_SITE QKSFM_ALL DRIVING_SITE 4 256 8.1.0 8.1.7 DST_UPGRADE_INSERT_CONV QKSFM_ALL DST_UPGRADE_INSERT_CONV NO_DST_UPGRADE_INSERT_CONV 1 0 11.2.0.1 DYNAMIC_SAMPLING QKSFM_DYNAMIC_SAMPLING DYNAMIC_SAMPLING 6 272 9.2.0 DYNAMIC_SAMPLING_EST_CDN QKSFM_DYNAMIC_SAMPLING_EST_CDN DYNAMIC_SAMPLING_EST_CDN 4 272 9.2.0 ELIMINATE_JOIN QKSFM_TABLE_ELIM ELIMINATE_JOIN NO_ELIMINATE_JOIN 4 16 10.2.0.1 10.2.0.1 ELIMINATE_OBY QKSFM_OBYE ELIMINATE_OBY NO_ELIMINATE_OBY 2 16 10.2.0.1 10.2.0.1 ELIMINATE_SQ QKSFM_ELIMINATE_SQ ELIMINATE_SQ NO_ELIMINATE_SQ 2 16 12.2.0.1 12.2.0.1 ELIM_GROUPBY QKSFM_TRANSFORMATION ELIM_GROUPBY NO_ELIM_GROUPBY 2 16 12.1.0.2 12.1.0.2 ENABLE_PARALLEL_DML QKSFM_DML ENABLE_PARALLEL_DML DISABLE_PARALLEL_DML 1 0 11.2.0.4 EXPAND_GSET_TO_UNION QKSFM_TRANSFORMATION EXPAND_GSET_TO_UNION NO_EXPAND_GSET_TO_UNION 2 0 9.2.0 10.1.0 EXPAND_TABLE QKSFM_TABLE_EXPANSION EXPAND_TABLE NO_EXPAND_TABLE 4 16 11.2.0.1 11.2.0.1 EXPR_CORR_CHECK QKSFM_CBO EXPR_CORR_CHECK 1 0 8.0.0 FACT QKSFM_STAR_TRANS FACT NO_FACT 4 272 8.1.0 8.1.7 FACTORIZE_JOIN QKSFM_JOINFAC FACTORIZE_JOIN NO_FACTORIZE_JOIN 2 16 11.2.0.1 11.2.0.1 FBTSCAN QKSFM_CBO FBTSCAN 1 0 10.1.0.3 FIRST_ROWS QKSFM_FIRST_ROWS MODE 1 16 8.1.0 10.2.0.1 FORCE_JSON_TABLE_TRANSFORM QKSFM_JSON_REWRITE FORCE_JSON_TABLE_TRANSFORM NO_JSON_TABLE_TRANSFORM 1 0 20.1.0 20.1.0 FORCE_XML_QUERY_REWRITE QKSFM_XML_REWRITE FORCE_XML_QUERY_REWRITE NO_XML_QUERY_REWRITE 1 0 9.2.0 11.1.0.6 FRESH_MV QKSFM_MVIEWS FRESH_MV 1 0 12.2.0.1 FULL QKSFM_FULL ACCESS 4 272 8.1.0 8.1.7 FULL_OUTER_JOIN_TO_OUTER QKSFM_CBO FULL_OUTER_JOIN_TO_OUTER NO_FULL_OUTER_JOIN_TO_OUTER 4 272 11.2.0.3 11.2.0.3 GATHER_OPTIMIZER_STATISTICS QKSFM_DBMS_STATS GATHER_OPTIMIZER_STATISTICS NO_GATHER_OPTIMIZER_STATISTICS 1 0 12.1.0.1 GATHER_PLAN_STATISTICS QKSFM_GATHER_PLAN_STATISTICS GATHER_PLAN_STATISTICS 1 0 10.1.0.3 GBY_CONC_ROLLUP QKSFM_TRANSFORMATION GBY_CONC_ROLLUP 2 0 9.0.0 GBY_PUSHDOWN QKSFM_ALL GBY_PUSHDOWN NO_GBY_PUSHDOWN 2 16 10.2.0.5 10.2.0.5 HASH QKSFM_ALL ACCESS 4 272 8.1.0 8.1.7 HASHSET_BUILD QKSFM_EXECUTION HASHSET_BUILD 2 16 21.1.0 21.1.0 HASH_AJ QKSFM_JOIN_METHOD ANTIJOIN 2 16 8.1.0 8.1.7 HASH_SJ QKSFM_JOIN_METHOD SEMIJOIN 2 16 8.1.0 8.1.7 HWM_BROKERED QKSFM_CBO HWM_BROKERED 2 0 9.0.0 IGNORE_OPTIM_EMBEDDED_HINTS QKSFM_ALL IGNORE_OPTIM_EMBEDDED_HINTS 1 0 10.1.0.3 10.2.0.1 IGNORE_ROW_ON_DUPKEY_INDEX QKSFM_DML IGNORE_ROW_ON_DUPKEY_INDEX 4 288 11.1.0.7 IGNORE_WHERE_CLAUSE QKSFM_ALL IGNORE_WHERE_CLAUSE 1 0 9.2.0 INCLUDE_VERSION QKSFM_ALL INCLUDE_VERSION 1 0 10.1.0.3 INDEX QKSFM_INDEX ACCESS NO_INDEX 4 304 8.0.0 8.1.7 INDEX_ASC QKSFM_INDEX_ASC ACCESS NO_INDEX 4 304 8.1.0 INDEX_COMBINE QKSFM_INDEX_COMBINE ACCESS 4 432 8.1.0 8.1.7 INDEX_DESC QKSFM_INDEX_DESC ACCESS NO_INDEX 4 304 8.1.0 8.1.7 INDEX_FFS QKSFM_INDEX_FFS ACCESS 4 304 8.1.0 8.1.7 INDEX_JOIN QKSFM_INDEX_JOIN ACCESS 4 304 8.1.5 10.1.0.3 INDEX_RRS QKSFM_CBO ACCESS 4 304 9.0.0 INDEX_RS_ASC QKSFM_INDEX_RS_ASC ACCESS 4 304 11.1.0.6 11.1.0.6 INDEX_RS_DESC QKSFM_INDEX_RS_DESC ACCESS 4 304 11.1.0.6 11.1.0.6 INDEX_SS QKSFM_INDEX_SS ACCESS NO_INDEX_SS 4 304 9.0.0 10.2.0.1 INDEX_SS_ASC QKSFM_INDEX_SS_ASC ACCESS NO_INDEX_SS 4 304 9.0.0 INDEX_SS_DESC QKSFM_INDEX_SS_DESC ACCESS NO_INDEX_SS 4 304 9.0.0 10.2.0.1 INDEX_STATS QKSFM_STATS TABLE_STATS 1 272 10.1.0.3 INLINE QKSFM_TRANSFORMATION INLINE MATERIALIZE 2 16 9.0.0 18.1.0 INLINE_XMLTYPE_NT QKSFM_ALL INLINE_XMLTYPE_NT 1 0 10.2.0.1 INMEMORY QKSFM_EXECUTION INMEMORY NO_INMEMORY 6 64 12.1.0.2 12.1.0.2 INMEMORY_PRUNING QKSFM_EXECUTION INMEMORY_PRUNING NO_INMEMORY_PRUNING 6 64 12.1.0.2 12.1.0.2 JSON_LENGTH QKSFM_EXECUTION JSON_LENGTH 1 0 19.1.0 LEADING QKSFM_JOIN_ORDER LEADING 8 272 8.1.6 10.1.0.3 LOCAL_INDEXES QKSFM_CBO LOCAL_INDEXES 2 0 9.0.0 MATERIALIZE QKSFM_TRANSFORMATION INLINE INLINE 2 16 9.0.0 18.1.0 MEMOPTIMIZE_WRITE QKSFM_EXECUTION MEMOPTIMIZE_WRITE 1 0 18.1.0 MERGE QKSFM_CVM MERGE NO_MERGE 6 16 8.1.0 10.1.0 MERGE_AJ QKSFM_JOIN_METHOD ANTIJOIN 2 16 8.1.0 8.1.7 MERGE_CONST_ON QKSFM_CBO MERGE_CONST_ON 1 0 8.0.0 MERGE_SJ QKSFM_JOIN_METHOD SEMIJOIN 2 16 8.1.0 8.1.7 MODEL_COMPILE_SUBQUERY QKSFM_TRANSFORMATION MODEL_COMPILE_SUBQUERY 2 0 10.2.0.1 MODEL_DONTVERIFY_UNIQUENESS QKSFM_TRANSFORMATION MODEL_DONTVERIFY_UNIQUENESS 2 0 10.1.0.3 MODEL_DYNAMIC_SUBQUERY QKSFM_TRANSFORMATION MODEL_DYNAMIC_SUBQUERY 2 0 10.2.0.1 MODEL_MIN_ANALYSIS QKSFM_TRANSFORMATION MODEL_MIN_ANALYSIS 2 0 10.1.0.3 MODEL_NO_ANALYSIS QKSFM_ALL MODEL_MIN_ANALYSIS 2 0 10.1.0.3 MODEL_PUSH_REF QKSFM_TRANSFORMATION MODEL_PUSH_REF NO_MODEL_PUSH_REF 2 0 10.1.0.3 MONITOR QKSFM_ALL MONITOR NO_MONITOR 1 0 11.1.0.6 MV_MERGE QKSFM_TRANSFORMATION MV_MERGE 2 0 9.0.0 NATIVE_FULL_OUTER_JOIN QKSFM_ALL NATIVE_FULL_OUTER_JOIN NO_NATIVE_FULL_OUTER_JOIN 2 16 10.2.0.3 10.2.0.3 NESTED_TABLE_FAST_INSERT QKSFM_ALL NESTED_TABLE_FAST_INSERT 1 0 10.1.0.3 NESTED_TABLE_GET_REFS QKSFM_ALL NESTED_TABLE_GET_REFS 1 0 8.1.0 NESTED_TABLE_SET_SETID QKSFM_ALL NESTED_TABLE_SET_SETID 1 0 8.1.5 NLJ_BATCHING QKSFM_EXECUTION ACCESS NO_NLJ_BATCHING 4 272 11.1.0.6 11.1.0.6 NLJ_PREFETCH QKSFM_EXECUTION NLJ_PREFETCH NO_NLJ_PREFETCH 4 272 11.1.0.6 11.1.0.6 NL_AJ QKSFM_JOIN_METHOD ANTIJOIN 2 16 8.0.0 NL_SJ QKSFM_JOIN_METHOD SEMIJOIN 2 16 8.0.0 NOAPPEND QKSFM_CBO APPEND APPEND 1 0 8.1.0 NOCACHE QKSFM_EXECUTION CACHE CACHE 4 256 8.1.0 NOPARALLEL QKSFM_PARALLEL SHARED SHARED 5 256 8.1.0 NO_ACCESS QKSFM_ALL NO_ACCESS 4 256 8.1.5 8.1.7 NO_ADAPTIVE_PLAN QKSFM_ADAPTIVE_PLAN ADAPTIVE_PLAN ADAPTIVE_PLAN 1 16 12.1.0.2 12.1.0.2 NO_ANSI_REARCH QKSFM_ANSI_REARCH ANSI_REARCH ANSI_REARCH 2 16 12.1.0.2 12.1.0.2 NO_ANSWER_QUERY_USING_STATS QKSFM_ANSWER_QUERY_USING_STATS ANSWER_QUERY_USING_STATS ANSWER_QUERY_USING_STATS 2 16 18.1.0 18.1.0 NO_AUTO_REOPTIMIZE QKSFM_AUTO_REOPT AUTO_REOPTIMIZE AUTO_REOPTIMIZE 1 0 12.1.0.1 NO_BASETABLE_MULTIMV_REWRITE QKSFM_ALL REWRITE REWRITE 2 16 10.1.0.3 10.1.0.3 NO_BATCH_TABLE_ACCESS_BY_ROWID QKSFM_EXECUTION BATCH_TABLE_ACCESS_BY_ROWID BATCH_TABLE_ACCESS_BY_ROWID 4 272 12.1.0.1 12.1.0.1 NO_BIND_AWARE QKSFM_CURSOR_SHARING BIND_AWARE BIND_AWARE 1 0 11.1.0.7 NO_BUFFER QKSFM_CBO BUFFER BUFFER 2 0 8.1.5 NO_BUSHY_JOIN QKSFM_BUSHY_JOIN BUSHY_JOIN BUSHY_JOIN 2 16 12.2.0.1 12.2.0.1 NO_CARTESIAN QKSFM_ALL NO_CARTESIAN 4 336 10.2.0.1 NO_CHECK_ACL_REWRITE QKSFM_CHECK_ACL_REWRITE NO_CHECK_ACL_REWRITE CHECK_ACL_REWRITE 1 0 11.1.0.6 NO_CLUSTERING QKSFM_CLUSTERING CLUSTERING CLUSTERING 1 0 12.1.0.1 12.1.0.1 NO_CLUSTER_BY_ROWID QKSFM_CBO CLUSTER_BY_ROWID CLUSTER_BY_ROWID 4 272 12.1.0.1 12.1.0.1 NO_COALESCE_SQ QKSFM_COALESCE_SQ COALESCE_SQ COALESCE_SQ 2 16 11.2.0.1 11.2.0.1 NO_CONNECT_BY_CB_WHR_ONLY QKSFM_TRANSFORMATION CONNECT_BY_CB_WHR_ONLY CONNECT_BY_CB_WHR_ONLY 2 16 10.2.0.5 10.2.0.5 NO_CONNECT_BY_COMBINE_SW QKSFM_ALL CONNECT_BY_COMBINE_SW CONNECT_BY_COMBINE_SW 2 16 10.2.0.4 10.2.0.4 NO_CONNECT_BY_COST_BASED QKSFM_TRANSFORMATION CONNECT_BY_COST_BASED CONNECT_BY_COST_BASED 2 16 10.2.0.2 10.2.0.2 NO_CONNECT_BY_ELIM_DUPS QKSFM_ALL CONNECT_BY_ELIM_DUPS CONNECT_BY_ELIM_DUPS 2 16 11.2.0.1 11.2.0.1 NO_CONNECT_BY_FILTERING QKSFM_ALL CONNECT_BY_FILTERING CONNECT_BY_FILTERING 2 16 10.2.0.2 10.2.0.2 NO_COST_XML_QUERY_REWRITE QKSFM_COST_XML_QUERY_REWRITE NO_COST_XML_QUERY_REWRITE COST_XML_QUERY_REWRITE 1 0 11.1.0.6 11.1.0.6 NO_CPU_COSTING QKSFM_CPU_COSTING CPU_COSTING CPU_COSTING 2 16 9.0.0 NO_DAGG_OPTIM_GSETS QKSFM_GROUPING_SET_XFORM DAGG_OPTIM_GSETS DAGG_OPTIM_GSETS 2 0 21.1.0 21.1.0 NO_DATA_SECURITY_REWRITE QKSFM_DATA_SECURITY_REWRITE DATA_SECURITY_REWRITE_LIMIT DATA_SECURITY_REWRITE_LIMIT 1 0 12.1.0.1 12.1.0.1 NO_DECORRELATE QKSFM_DECORRELATE DECORRELATE DECORRELATE 2 16 12.1.0.1 12.1.0.1 NO_DIST_AGG_PROLLUP_PUSHDOWN QKSFM_PQ DIST_AGG_PROLLUP_PUSHDOWN DIST_AGG_PROLLUP_PUSHDOWN 2 16 12.2.0.1 12.2.0.1 NO_DOMAIN_INDEX_FILTER QKSFM_CBO NO_DOMAIN_INDEX_FILTER DOMAIN_INDEX_FILTER 4 304 11.1.0.6 11.1.0.6 NO_DST_UPGRADE_INSERT_CONV QKSFM_ALL DST_UPGRADE_INSERT_CONV DST_UPGRADE_INSERT_CONV 1 0 11.2.0.1 21.1.0.1 NO_ELIMINATE_JOIN QKSFM_TABLE_ELIM ELIMINATE_JOIN ELIMINATE_JOIN 4 16 10.2.0.1 10.2.0.1 NO_ELIMINATE_OBY QKSFM_OBYE ELIMINATE_OBY ELIMINATE_OBY 2 16 10.2.0.1 10.2.0.1 NO_ELIMINATE_SQ QKSFM_ELIMINATE_SQ ELIMINATE_SQ ELIMINATE_SQ 2 16 12.2.0.1 12.2.0.1 NO_ELIM_GROUPBY QKSFM_TRANSFORMATION ELIM_GROUPBY ELIM_GROUPBY 2 16 12.1.0.2 12.1.0.2 NO_EXPAND QKSFM_USE_CONCAT OR_EXPAND USE_CONCAT 2 16 8.1.0 8.1.7 NO_EXPAND_GSET_TO_UNION QKSFM_TRANSFORMATION EXPAND_GSET_TO_UNION EXPAND_GSET_TO_UNION 2 0 9.2.0 10.1.0 NO_EXPAND_TABLE QKSFM_TABLE_EXPANSION EXPAND_TABLE EXPAND_TABLE 4 16 11.2.0.1 11.2.0.1 NO_FACT QKSFM_STAR_TRANS FACT FACT 4 272 8.1.0 8.1.7 NO_FACTORIZE_JOIN QKSFM_JOINFAC FACTORIZE_JOIN FACTORIZE_JOIN 2 16 11.2.0.1 11.2.0.1 NO_FULL_OUTER_JOIN_TO_OUTER QKSFM_CBO FULL_OUTER_JOIN_TO_OUTER FULL_OUTER_JOIN_TO_OUTER 4 272 11.2.0.3 11.2.0.3 NO_GATHER_OPTIMIZER_STATISTICS QKSFM_DBMS_STATS GATHER_OPTIMIZER_STATISTICS GATHER_OPTIMIZER_STATISTICS 1 0 12.1.0.1 NO_GBY_PUSHDOWN QKSFM_ALL GBY_PUSHDOWN GBY_PUSHDOWN 2 16 10.2.0.5 10.2.0.5 NO_INDEX QKSFM_INDEX NO_INDEX INDEX 4 304 8.1.5 8.1.7 NO_INDEX_FFS QKSFM_INDEX_FFS NO_INDEX_FFS INDEX_FFS 4 304 10.1.0.3 10.1.0.3 NO_INDEX_SS QKSFM_INDEX_SS NO_INDEX_SS INDEX_SS 4 304 10.1.0.3 10.1.0.3 NO_INMEMORY QKSFM_EXECUTION INMEMORY INMEMORY 6 64 12.1.0.2 12.1.0.2 NO_INMEMORY_PRUNING QKSFM_EXECUTION INMEMORY_PRUNING INMEMORY_PRUNING 6 64 12.1.0.2 12.1.0.2 NO_JSON_TABLE_TRANSFORM QKSFM_JSON_REWRITE FORCE_JSON_TABLE_TRANSFORM FORCE_JSON_TABLE_TRANSFORM 1 0 20.1.0 20.1.0 NO_LOAD QKSFM_EXECUTION NO_LOAD 1 0 11.1.0.6 NO_MERGE QKSFM_CVM MERGE MERGE 6 16 8.0.0 10.1.0 NO_MODEL_PUSH_REF QKSFM_ALL MODEL_PUSH_REF MODEL_PUSH_REF 2 0 10.1.0.3 NO_MONITOR QKSFM_ALL MONITOR MONITOR 1 0 11.1.0.6 NO_MONITORING QKSFM_ALL NO_MONITORING 1 0 8.0.0 NO_MULTIMV_REWRITE QKSFM_ALL REWRITE REWRITE 2 16 10.1.0.3 10.1.0.3 NO_NATIVE_FULL_OUTER_JOIN QKSFM_ALL NATIVE_FULL_OUTER_JOIN NATIVE_FULL_OUTER_JOIN 2 16 10.2.0.3 10.2.0.3 NO_NLJ_BATCHING QKSFM_EXECUTION ACCESS NLJ_BATCHING 4 272 11.1.0.6 11.1.0.6 NO_NLJ_PREFETCH QKSFM_EXECUTION NLJ_PREFETCH NLJ_PREFETCH 4 272 11.1.0.6 11.1.0.6 NO_OBY_GBYPD_SEPARATE QKSFM_PQ OBY_GBYPD_SEPARATE OBY_GBYPD_SEPARATE 2 16 21.1.0 21.1.0 NO_ORDER_ROLLUPS QKSFM_TRANSFORMATION NO_ORDER_ROLLUPS 2 0 8.0.0 NO_OR_EXPAND QKSFM_CBQT_OR_EXPANSION OR_EXPAND OR_EXPAND 2 16 12.2.0.1 12.2.0.1 NO_OUTER_JOIN_TO_ANTI QKSFM_CBO OUTER_JOIN_TO_ANTI OUTER_JOIN_TO_ANTI 4 272 11.2.0.3 11.2.0.3 NO_OUTER_JOIN_TO_INNER QKSFM_OUTER_JOIN_TO_INNER OUTER_JOIN_TO_INNER OUTER_JOIN_TO_INNER 6 16 11.1.0.6 11.1.0.6 NO_PARALLEL QKSFM_CBO SHARED SHARED 5 256 10.1.0.3 NO_PARALLEL_INDEX QKSFM_PQ PARALLEL_INDEX PARALLEL_INDEX 4 288 8.1.0 NO_PARTIAL_COMMIT QKSFM_CBO NO_PARTIAL_COMMIT 1 0 10.1.0.3 NO_PARTIAL_JOIN QKSFM_PARTIAL_JOIN PARTIAL_JOIN PARTIAL_JOIN 4 272 12.1.0.1 12.1.0.1 NO_PARTIAL_ROLLUP_PUSHDOWN QKSFM_PQ PARTIAL_ROLLUP_PUSHDOWN PARTIAL_ROLLUP_PUSHDOWN 2 16 12.1.0.1 12.1.0.1 NO_PLACE_DISTINCT QKSFM_DIST_PLCMT PLACE_DISTINCT PLACE_DISTINCT 2 16 11.2.0.1 11.2.0.1 NO_PLACE_GROUP_BY QKSFM_PLACE_GROUP_BY PLACE_GROUP_BY PLACE_GROUP_BY 2 16 11.1.0.6 11.1.0.6 NO_PQ_CONCURRENT_UNION QKSFM_PQ PQ_CONCURRENT_UNION PQ_CONCURRENT_UNION 3 0 12.1.0.1 12.1.0.1 NO_PQ_EXPAND_TABLE QKSFM_TABLE_EXPANSION PQ_EXPAND_TABLE PQ_EXPAND_TABLE 4 16 19.1.0 19.1.0 NO_PQ_NONLEAF_SKEW QKSFM_PQ PQ_NONLEAF_SKEW PQ_NONLEAF_SKEW 4 272 21.1.0 21.1.0 NO_PQ_REPLICATE QKSFM_PQ_REPLICATE PQ_REPLICATE PQ_REPLICATE 4 272 12.1.0.1 12.1.0.1 NO_PQ_SKEW QKSFM_PQ PQ_SKEW PQ_SKEW 4 272 12.1.0.1 12.1.0.1 NO_PRUNE_GSETS QKSFM_TRANSFORMATION NO_PRUNE_GSETS 2 0 9.0.0 NO_PULL_PRED QKSFM_PULL_PRED PULL_PRED PULL_PRED 4 16 10.2.0.1 10.2.0.1 NO_PUSH_HAVING_TO_GBY QKSFM_EXECUTION PUSH_HAVING_TO_GBY PUSH_HAVING_TO_GBY 2 0 18.1.0 18.1.0 NO_PUSH_PRED QKSFM_FILTER_PUSH_PRED PUSH_PRED PUSH_PRED 6 16 8.1.0 8.1.5 NO_PUSH_SUBQ QKSFM_TRANSFORMATION PUSH_SUBQ PUSH_SUBQ 2 16 9.2.0 10.2.0.5 NO_PX_FAULT_TOLERANCE QKSFM_PQ PX_FAULT_TOLERANCE PX_FAULT_TOLERANCE 1 0 12.1.0.1 12.1.0.1 NO_PX_JOIN_FILTER QKSFM_PX_JOIN_FILTER PX_JOIN_FILTER PX_JOIN_FILTER 4 336 10.2.0.1 11.1.0.6 NO_QKN_BUFF QKSFM_CBO NO_QKN_BUFF 2 0 9.2.0 NO_QUERY_TRANSFORMATION QKSFM_TRANSFORMATION NO_QUERY_TRANSFORMATION 1 16 10.1.0.3 NO_REF_CASCADE QKSFM_CBO REF_CASCADE_CURSOR REF_CASCADE_CURSOR 1 0 9.2.0 NO_REORDER_WIF QKSFM_PARTITION REORDER_WIF REORDER_WIF 2 0 18.1.0 18.1.0 NO_RESULT_CACHE QKSFM_EXECUTION RESULT_CACHE RESULT_CACHE 2 0 11.1.0.6 NO_REWRITE QKSFM_TRANSFORMATION REWRITE REWRITE 2 16 8.1.5 8.1.7 NO_SEMIJOIN QKSFM_TRANSFORMATION SEMIJOIN SEMIJOIN 2 16 9.0.0 NO_SEMI_TO_INNER QKSFM_CBO NO_SEMI_TO_INNER SEMI_TO_INNER 4 272 11.2.0.3 11.2.0.3 NO_SET_GBY_PUSHDOWN QKSFM_ALL SET_GBY_PUSHDOWN SET_GBY_PUSHDOWN 2 16 20.1.0 20.1.0 NO_SET_TO_JOIN QKSFM_SET_TO_JOIN SET_TO_JOIN SET_TO_JOIN 2 16 10.1.0.3 10.1.0.3 NO_SQL_TUNE QKSFM_ALL NO_SQL_TUNE 1 0 10.2.0.1 NO_STAR_TRANSFORMATION QKSFM_STAR_TRANS STAR_TRANSFORMATION STAR_TRANSFORMATION 6 16 10.1.0.3 10.1.0.3 NO_STATEMENT_QUEUING QKSFM_PARALLEL STATEMENT_QUEUING STATEMENT_QUEUING 1 0 11.2.0.1 NO_STATS_GSETS QKSFM_ALL NO_STATS_GSETS 2 0 8.0.0 NO_SUBQUERY_PRUNING QKSFM_CBO SUBQUERY_PRUNING SUBQUERY_PRUNING 4 272 11.1.0.6 11.1.0.6 NO_SUBSTRB_PAD QKSFM_EXECUTION NO_SUBSTRB_PAD 1 0 11.2.0.1 NO_SWAP_JOIN_INPUTS QKSFM_CBO SWAP_JOIN_INPUTS SWAP_JOIN_INPUTS 4 272 10.1.0.3 10.1.0.3 NO_TABLE_LOOKUP_BY_NL QKSFM_TABLE_LOOKUP_BY_NL TABLE_LOOKUP_BY_NL TABLE_LOOKUP_BY_NL 4 16 11.2.0.2 11.2.0.2 NO_TRANSFORM_DISTINCT_AGG QKSFM_TRANSFORMATION TRANSFORM_DISTINCT_AGG TRANSFORM_DISTINCT_AGG 2 0 11.2.0.1 11.2.0.1 NO_UNNEST QKSFM_UNNEST UNNEST UNNEST 2 16 8.1.6 10.1.0 NO_USE_CUBE QKSFM_USE_CUBE JOIN USE_CUBE 4 336 12.1.0.1 12.1.0.1 NO_USE_DAGG_UNION_ALL_GSETS QKSFM_GROUPING_SET_XFORM DAGG_OPTIM_GSETS USE_DAGG_UNION_ALL_GSETS 2 0 12.2.0.1 12.2.0.1 NO_USE_HASH QKSFM_USE_HASH NO_USE_HASH USE_HASH 4 336 10.1.0.3 10.1.0.3 NO_USE_HASH_AGGREGATION QKSFM_ALL USE_HASH_AGGREGATION USE_HASH_AGGREGATION 2 0 10.2.0.1 10.2.0.5 NO_USE_HASH_GBY_FOR_DAGGPSHD QKSFM_ALL USE_HASH_GBY_FOR_DAGGPSHD USE_HASH_GBY_FOR_DAGGPSHD 2 0 12.2.0.1 12.2.0.1 NO_USE_HASH_GBY_FOR_PUSHDOWN QKSFM_ALL USE_HASH_GBY_FOR_PUSHDOWN USE_HASH_GBY_FOR_PUSHDOWN 2 0 11.2.0.2 11.2.0.2 NO_USE_INVISIBLE_INDEXES QKSFM_INDEX USE_INVISIBLE_INDEXES USE_INVISIBLE_INDEXES 1 0 11.1.0.6 11.1.0.6 NO_USE_MERGE QKSFM_USE_MERGE NO_USE_MERGE USE_MERGE 4 336 10.1.0.3 10.1.0.3 NO_USE_NL QKSFM_USE_NL NO_USE_NL USE_NL 4 336 10.1.0.3 10.1.0.3 NO_USE_PARTITION_WISE_DISTINCT QKSFM_PARTITION USE_PARTITION_WISE_DISTINCT USE_PARTITION_WISE_DISTINCT 2 0 12.2.0.1 12.2.0.1 NO_USE_PARTITION_WISE_GBY QKSFM_PARTITION USE_PARTITION_WISE_GBY USE_PARTITION_WISE_GBY 2 0 12.2.0.1 12.2.0.1 NO_USE_PARTITION_WISE_WIF QKSFM_PARTITION USE_PARTITION_WISE_WIF USE_PARTITION_WISE_WIF 2 0 18.1.0 18.1.0 NO_USE_SCALABLE_GBY_INVDIST QKSFM_PQ USE_SCALABLE_GBY_INVDIST USE_SCALABLE_GBY_INVDIST 2 0 19.1.0 19.1.0 NO_USE_VECTOR_AGGREGATION QKSFM_VECTOR_AGG USE_VECTOR_AGGREGATION USE_VECTOR_AGGREGATION 2 16 12.1.0.2 12.1.0.2 NO_VECTOR_TRANSFORM QKSFM_VECTOR_AGG VECTOR_TRANSFORM VECTOR_TRANSFORM 2 16 12.1.0.2 12.1.0.2 NO_VECTOR_TRANSFORM_DIMS QKSFM_VECTOR_AGG VECTOR_TRANSFORM_DIMS VECTOR_TRANSFORM_DIMS 4 80 12.1.0.2 12.1.0.2 NO_VECTOR_TRANSFORM_FACT QKSFM_VECTOR_AGG VECTOR_TRANSFORM_FACT VECTOR_TRANSFORM_FACT 4 80 12.1.0.2 12.1.0.2 NO_XDB_FASTPATH_INSERT QKSFM_ALL XDB_FASTPATH_INSERT XDB_FASTPATH_INSERT 1 0 11.2.0.2 NO_XMLINDEX_REWRITE QKSFM_XMLINDEX_REWRITE XMLINDEX_REWRITE XMLINDEX_REWRITE 1 0 11.1.0.6 11.1.0.6 NO_XMLINDEX_REWRITE_IN_SELECT QKSFM_XMLINDEX_REWRITE XMLINDEX_REWRITE XMLINDEX_REWRITE_IN_SELECT 1 0 11.1.0.6 11.1.0.6 NO_XML_DML_REWRITE QKSFM_XML_REWRITE NO_XML_DML_REWRITE 1 0 10.2.0.1 11.1.0.6 NO_XML_QUERY_REWRITE QKSFM_XML_REWRITE FORCE_XML_QUERY_REWRITE FORCE_XML_QUERY_REWRITE 1 0 9.2.0 11.1.0.6 NO_ZONEMAP QKSFM_ZONEMAP ZONEMAP ZONEMAP 4 256 12.1.0.1 12.1.0.1 NUM_INDEX_KEYS QKSFM_CBO ACCESS 4 304 10.2.0.3 10.2.0.3 OBY_GBYPD_SEPARATE QKSFM_PQ OBY_GBYPD_SEPARATE NO_OBY_GBYPD_SEPARATE 2 16 21.1.0 21.1.0 OLD_PUSH_PRED QKSFM_OLD_PUSH_PRED OLD_PUSH_PRED 6 16 10.2.0.1 10.2.0.1 OPAQUE_TRANSFORM QKSFM_TRANSFORMATION OPAQUE_TRANSFORM 1 0 10.1.0.3 OPAQUE_XCANONICAL QKSFM_TRANSFORMATION OPAQUE_XCANONICAL 1 0 10.1.0.3 OPTIMIZER_FEATURES_ENABLE QKSFM_ALL OPTIMIZER_FEATURES_ENABLE 1 272 10.1.0.3 10.2.0.1 OPT_ESTIMATE QKSFM_OPT_ESTIMATE OPT_ESTIMATE 14 272 10.1.0.3 OPT_PARAM QKSFM_ALL OPT_PARAM 1 272 10.2.0.1 10.2.0.1 ORDERED QKSFM_CBO ORDERED 2 16 8.1.0 8.1.7 ORDERED_PREDICATES QKSFM_CBO ORDERED_PREDICATES 2 16 8.0.0 ORDER_KEY_VECTOR_USE QKSFM_VECTOR_AGG ORDER_KEY_VECTOR_USE 2 272 21.1.0 21.1.0 ORDER_SUBQ QKSFM_TRANSFORMATION ORDER_SUBQ 2 16 12.2.0.1 12.2.0.1 OR_EXPAND QKSFM_CBQT_OR_EXPANSION OR_EXPAND NO_OR_EXPAND 2 16 12.2.0.1 12.2.0.1 OSON_GET_CONTENT QKSFM_JSON OSON_GET_CONTENT 1 0 21.1.0 21.1.0 OUTER_JOIN_TO_ANTI QKSFM_CBO OUTER_JOIN_TO_ANTI NO_OUTER_JOIN_TO_ANTI 4 272 11.2.0.3 11.2.0.3 OUTER_JOIN_TO_INNER QKSFM_OUTER_JOIN_TO_INNER OUTER_JOIN_TO_INNER NO_OUTER_JOIN_TO_INNER 6 16 11.1.0.6 11.1.0.6 OUTLINE QKSFM_ALL OUTLINE 2 0 10.2.0.1 10.2.0.1 OUTLINE_LEAF QKSFM_ALL OUTLINE_LEAF 2 0 10.2.0.1 10.2.0.1 OVERFLOW_NOMOVE QKSFM_CBO OVERFLOW_NOMOVE 2 0 9.0.0 PARALLEL_INDEX QKSFM_PQ PARALLEL_INDEX NO_PARALLEL_INDEX 4 288 8.1.0 PARTIAL_JOIN QKSFM_PARTIAL_JOIN PARTIAL_JOIN NO_PARTIAL_JOIN 4 272 12.1.0.1 12.1.0.1 PARTIAL_ROLLUP_PUSHDOWN QKSFM_PQ PARTIAL_ROLLUP_PUSHDOWN NO_PARTIAL_ROLLUP_PUSHDOWN 2 16 12.1.0.1 12.1.0.1 PDB_LOCAL_ONLY QKSFM_DML PDB_LOCAL_ONLY 1 0 18.1.0 PIV_GB QKSFM_ALL PIV_GB 2 0 8.1.0 PIV_SSF QKSFM_ALL PIV_SSF 2 0 8.1.0 PLACE_DISTINCT QKSFM_DIST_PLCMT PLACE_DISTINCT NO_PLACE_DISTINCT 2 16 11.2.0.1 11.2.0.1 PLACE_GROUP_BY QKSFM_PLACE_GROUP_BY PLACE_GROUP_BY NO_PLACE_GROUP_BY 2 16 11.1.0.6 11.1.0.6 PQ_CONCURRENT_UNION QKSFM_PQ PQ_CONCURRENT_UNION NO_PQ_CONCURRENT_UNION 3 0 12.1.0.1 12.1.0.1 PQ_DISTRIBUTE QKSFM_PQ_DISTRIBUTE PQ_DISTRIBUTE 4 272 8.1.5 8.1.7 PQ_DISTRIBUTE_WINDOW QKSFM_PQ PQ_DISTRIBUTE_WINDOW 2 16 12.1.0.1 12.1.0.1 PQ_EXPAND_TABLE QKSFM_TABLE_EXPANSION PQ_EXPAND_TABLE NO_PQ_EXPAND_TABLE 4 16 19.1.0 19.1.0 PQ_FILTER QKSFM_PQ PQ_FILTER 2 0 12.1.0.1 12.1.0.1 PQ_MAP QKSFM_PQ_MAP PQ_MAP PQ_NOMAP 4 272 9.0.0 10.2.0.1 PQ_NOMAP QKSFM_PQ_MAP PQ_MAP PQ_MAP 4 272 9.0.0 10.2.0.1 PQ_NONLEAF_SKEW QKSFM_PQ PQ_NONLEAF_SKEW NO_PQ_NONLEAF_SKEW 4 272 21.1.0 21.1.0 PQ_REPLICATE QKSFM_PQ_REPLICATE PQ_REPLICATE NO_PQ_REPLICATE 4 272 12.1.0.1 12.1.0.1 PQ_SKEW QKSFM_PQ PQ_SKEW NO_PQ_SKEW 4 272 12.1.0.1 12.1.0.1 PRECOMPUTE_SUBQUERY QKSFM_TRANSFORMATION PRECOMPUTE_SUBQUERY 2 0 10.2.0.1 PRESERVE_OID QKSFM_ALL PRESERVE_OID 1 0 10.2.0.1 PULL_PRED QKSFM_PULL_PRED PULL_PRED NO_PULL_PRED 4 16 10.2.0.1 10.2.0.1 PUSH_HAVING_TO_GBY QKSFM_EXECUTION PUSH_HAVING_TO_GBY NO_PUSH_HAVING_TO_GBY 2 0 18.1.0 18.1.0 PUSH_PRED QKSFM_FILTER_PUSH_PRED PUSH_PRED NO_PUSH_PRED 6 16 8.1.0 8.1.5 PUSH_SUBQ QKSFM_TRANSFORMATION PUSH_SUBQ NO_PUSH_SUBQ 2 16 8.1.0 10.2.0.5 PX_FAULT_TOLERANCE QKSFM_PQ PX_FAULT_TOLERANCE NO_PX_FAULT_TOLERANCE 1 0 12.1.0.1 12.1.0.1 PX_JOIN_FILTER QKSFM_PX_JOIN_FILTER PX_JOIN_FILTER NO_PX_JOIN_FILTER 4 336 10.2.0.1 11.1.0.6 QB_NAME QKSFM_ALL QB_NAME 2 256 10.1.0.3 QUARANTINE QKSFM_EXECUTION QUARANTINE 1 0 19.1.0 QUEUE_CURR QKSFM_CBO ACCESS 4 256 8.0.0 QUEUE_ROWP QKSFM_CBO ACCESS 4 256 8.0.0 RBO_OUTLINE QKSFM_RBO RBO_OUTLINE 1 0 10.2.0.1 10.2.0.1 REF_CASCADE_CURSOR QKSFM_CBO REF_CASCADE_CURSOR NO_REF_CASCADE 1 0 9.2.0 REMOTE_MAPPED QKSFM_ALL REMOTE_MAPPED 2 272 8.1.0 REORDER_WIF QKSFM_PARTITION REORDER_WIF NO_REORDER_WIF 2 0 18.1.0 18.1.0 RESERVOIR_SAMPLING QKSFM_EXECUTION RESERVOIR_SAMPLING 1 0 12.1.0.2 RESTORE_AS_INTERVALS QKSFM_CBO RESTORE_AS_INTERVALS 2 0 8.1.5 RESTRICT_ALL_REF_CONS QKSFM_ALL RESTRICT_ALL_REF_CONS 1 0 10.1.0.3 RESULT_CACHE QKSFM_EXECUTION RESULT_CACHE NO_RESULT_CACHE 2 0 11.1.0.6 RETRY_ON_ROW_CHANGE QKSFM_DML RETRY_ON_ROW_CHANGE 1 0 11.1.0.7 REWRITE QKSFM_TRANSFORMATION REWRITE NO_REWRITE 2 16 8.1.5 8.1.7 REWRITE_OR_ERROR QKSFM_TRANSFORMATION REWRITE 2 0 10.1.0.3 ROWID QKSFM_CBO ACCESS 4 272 8.0.0 8.1.7 RULE QKSFM_RBO MODE 1 16 8.1.0 8.1.5 SAVE_AS_INTERVALS QKSFM_CBO SAVE_AS_INTERVALS 2 0 8.1.5 SCN_ASCENDING QKSFM_ALL SCN_ASCENDING 1 0 8.1.5 SEMIJOIN QKSFM_TRANSFORMATION SEMIJOIN NO_SEMIJOIN 2 16 9.0.0 SEMIJOIN_DRIVER QKSFM_CBO SEMIJOIN_DRIVER 2 16 8.1.0 8.1.7 SEMI_TO_INNER QKSFM_CBO SEMI_TO_INNER NO_SEMI_TO_INNER 4 272 11.2.0.3 11.2.0.3 SET_GBY_PUSHDOWN QKSFM_ALL SET_GBY_PUSHDOWN NO_SET_GBY_PUSHDOWN 2 16 20.1.0 20.1.0 SET_TO_JOIN QKSFM_SET_TO_JOIN SET_TO_JOIN NO_SET_TO_JOIN 2 16 10.1.0.3 10.1.0.3 SHARED QKSFM_PARALLEL SHARED NO_PARALLEL 5 256 8.1.0 SKIP_EXT_OPTIMIZER QKSFM_CBO SKIP_EXT_OPTIMIZER 2 16 9.0.0 SKIP_PROXY QKSFM_ALL SKIP_PROXY 1 0 18.1.0 SKIP_UNQ_UNUSABLE_IDX QKSFM_CBO SKIP_UNQ_UNUSABLE_IDX 1 0 10.1.0.3 SQLLDR QKSFM_CBO SQLLDR 1 0 9.0.0 SQL_SCOPE QKSFM_COMPILATION SQL_SCOPE 1 0 12.2.0.1 STAR QKSFM_STAR_TRANS STAR 2 16 8.1.0 STAR_TRANSFORMATION QKSFM_STAR_TRANS STAR_TRANSFORMATION NO_STAR_TRANSFORMATION 6 16 8.1.0 8.1.7 STATEMENT_QUEUING QKSFM_PARALLEL STATEMENT_QUEUING NO_STATEMENT_QUEUING 1 0 11.2.0.1 STREAMS QKSFM_CBO STREAMS 1 0 10.1.0.3 SUBQUERY_PRUNING QKSFM_CBO SUBQUERY_PRUNING NO_SUBQUERY_PRUNING 4 272 11.1.0.6 11.1.0.6 SUPPRESS_LOAD QKSFM_DDL SUPPRESS_LOAD 1 0 18.1.0 SWAP_JOIN_INPUTS QKSFM_CBO SWAP_JOIN_INPUTS NO_SWAP_JOIN_INPUTS 4 272 8.1.0 8.1.7 SYSTEM_STATS QKSFM_ALL SYSTEM_STATS 1 272 18.1.0 SYS_DL_CURSOR QKSFM_CBO SYS_DL_CURSOR 1 0 9.2.0 SYS_PARALLEL_TXN QKSFM_CBO SYS_PARALLEL_TXN 2 0 8.1.6 SYS_RID_ORDER QKSFM_ALL SYS_RID_ORDER 2 0 9.2.0 TABLE_LOOKUP_BY_NL QKSFM_TABLE_LOOKUP_BY_NL TABLE_LOOKUP_BY_NL NO_TABLE_LOOKUP_BY_NL 4 16 11.2.0.2 11.2.0.2 TABLE_STATS QKSFM_STATS TABLE_STATS 1 272 10.1.0.3 TIV_GB QKSFM_ALL PIV_GB 2 0 8.1.0 TIV_SSF QKSFM_ALL PIV_SSF 2 0 8.1.0 TRACING QKSFM_EXECUTION TRACING 1 0 10.1.0.3 TRANSFORM_DISTINCT_AGG QKSFM_TRANSFORMATION TRANSFORM_DISTINCT_AGG NO_TRANSFORM_DISTINCT_AGG 2 0 11.2.0.1 11.2.0.1 UNNEST QKSFM_UNNEST UNNEST NO_UNNEST 2 16 8.1.6 10.1.0 USE_ANTI QKSFM_CBO USE_ANTI 4 272 8.1.0 USE_CONCAT QKSFM_USE_CONCAT OR_EXPAND NO_EXPAND 2 16 8.1.0 8.1.7 USE_CUBE QKSFM_USE_CUBE JOIN NO_USE_CUBE 4 336 12.1.0.1 12.1.0.1 USE_DAGG_UNION_ALL_GSETS QKSFM_GROUPING_SET_XFORM DAGG_OPTIM_GSETS NO_USE_DAGG_UNION_ALL_GSETS 2 0 12.2.0.1 12.2.0.1 USE_HASH QKSFM_USE_HASH JOIN NO_USE_HASH 4 464 8.1.0 8.1.7 USE_HASH_AGGREGATION QKSFM_ALL USE_HASH_AGGREGATION NO_USE_HASH_AGGREGATION 2 0 10.2.0.1 10.2.0.5 USE_HASH_GBY_FOR_DAGGPSHD QKSFM_ALL USE_HASH_GBY_FOR_DAGGPSHD NO_USE_HASH_GBY_FOR_DAGGPSHD 2 0 12.2.0.1 12.2.0.1 USE_HASH_GBY_FOR_PUSHDOWN QKSFM_ALL USE_HASH_GBY_FOR_PUSHDOWN NO_USE_HASH_GBY_FOR_PUSHDOWN 2 0 11.2.0.2 11.2.0.2 USE_HIDDEN_PARTITIONS QKSFM_PARTITION USE_HIDDEN_PARTITIONS 2 0 12.1.0.1 USE_INVISIBLE_INDEXES QKSFM_INDEX USE_INVISIBLE_INDEXES NO_USE_INVISIBLE_INDEXES 1 0 11.1.0.6 11.1.0.6 USE_MERGE QKSFM_USE_MERGE JOIN NO_USE_MERGE 4 336 8.1.0 8.1.7 USE_MERGE_CARTESIAN QKSFM_USE_MERGE_CARTESIAN JOIN 4 336 11.1.0.6 11.1.0.6 USE_NL QKSFM_USE_NL JOIN NO_USE_NL 4 336 8.1.0 8.1.7 USE_NL_WITH_INDEX QKSFM_USE_NL_WITH_INDEX USE_NL_WITH_INDEX NO_USE_NL 4 304 10.1.0.3 USE_PARTITION_WISE_DISTINCT QKSFM_PARTITION USE_PARTITION_WISE_DISTINCT NO_USE_PARTITION_WISE_DISTINCT 2 0 12.2.0.1 12.2.0.1 USE_PARTITION_WISE_GBY QKSFM_PARTITION USE_PARTITION_WISE_GBY NO_USE_PARTITION_WISE_GBY 2 0 12.2.0.1 12.2.0.1 USE_PARTITION_WISE_WIF QKSFM_PARTITION USE_PARTITION_WISE_WIF NO_USE_PARTITION_WISE_WIF 2 0 18.1.0 18.1.0 USE_SCALABLE_GBY_INVDIST QKSFM_PQ USE_SCALABLE_GBY_INVDIST NO_USE_SCALABLE_GBY_INVDIST 2 0 19.1.0 19.1.0 USE_SEMI QKSFM_CBO USE_SEMI 4 272 8.1.0 USE_TTT_FOR_GSETS QKSFM_TRANSFORMATION USE_TTT_FOR_GSETS 2 0 9.0.0 USE_VECTOR_AGGREGATION QKSFM_VECTOR_AGG USE_VECTOR_AGGREGATION NO_USE_VECTOR_AGGREGATION 2 16 12.1.0.2 12.1.0.2 USE_WEAK_NAME_RESL QKSFM_ALL USE_WEAK_NAME_RESL 1 0 10.1.0.3 VECTOR_READ QKSFM_CBO VECTOR_READ 1 0 10.1.0.3 VECTOR_READ_TRACE QKSFM_CBO VECTOR_READ_TRACE 1 0 10.1.0.3 VECTOR_TRANSFORM QKSFM_VECTOR_AGG VECTOR_TRANSFORM NO_VECTOR_TRANSFORM 2 16 12.1.0.2 12.1.0.2 VECTOR_TRANSFORM_DIMS QKSFM_VECTOR_AGG VECTOR_TRANSFORM_DIMS NO_VECTOR_TRANSFORM_DIMS 4 80 12.1.0.2 12.1.0.2 VECTOR_TRANSFORM_FACT QKSFM_VECTOR_AGG VECTOR_TRANSFORM_FACT NO_VECTOR_TRANSFORM_FACT 4 80 12.1.0.2 12.1.0.2 WITH_PLSQL QKSFM_ALL WITH_PLSQL 1 0 12.1.0.1 XDB_FASTPATH_INSERT QKSFM_ALL XDB_FASTPATH_INSERT NO_XDB_FASTPATH_INSERT 1 0 11.2.0.2 XMLINDEX_REWRITE QKSFM_XMLINDEX_REWRITE XMLINDEX_REWRITE NO_XMLINDEX_REWRITE 1 0 11.1.0.6 11.1.0.6 XMLINDEX_REWRITE_IN_SELECT QKSFM_XMLINDEX_REWRITE XMLINDEX_REWRITE NO_XMLINDEX_REWRITE_IN_SELECT 1 0 11.1.0.6 11.1.0.6 XMLINDEX_SEL_IDX_TBL QKSFM_ALL XMLINDEX_SEL_IDX_TBL 1 0 11.2.0.1 XMLTSET_DML_ENABLE QKSFM_ALL XMLTSET_DML_ENABLE 1 0 12.2.0.1 XML_DML_RWT_STMT QKSFM_XML_REWRITE XML_DML_RWT_STMT 1 0 11.1.0.6 11.1.0.6 X_DYN_PRUNE QKSFM_CBO X_DYN_PRUNE 2 0 10.1.0.3 ZONEMAP QKSFM_ZONEMAP ZONEMAP NO_ZONEMAP 4 256 12.1.0.1 12.1.0.1 388行が選択されました。

PostgreSQL / pg_hint_plan (22-Nov-2023時点）

pg_hint_planのヒントもOracleの影響を受けているところもあるけども、PostgreSQL独特の言い回しを使う傾向はありますよね。面白いのは、LEADINGヒントで（a b）みたいなペアで優先度を記述する部分。これかなり慣れが必要な気がします。

https://github.com/ossc-db/pg_hint_plan

https://github.com/ossc-db/pg_hint_plan/blob/master/docs/hint_list.md

Hint list

Format Description

Scan method SeqScan(table) Forces sequential scan on the table.

TidScan(table) Forces TID scan on the table.

IndexScan(table[ index...]) Forces index scan on the table. Restricts to specified indexes if any.

IndexOnlyScan(table[ index...]) Forces index-only scan on the table. Restricts to specified indexes if any. Index scan may be used if index-only scan is not available.

BitmapScan(table[ index...]) Forces bitmap scan on the table. Restricts to specified indexes if any.

IndexScanRegexp(table[ POSIX Regexp...])
IndexOnlyScanRegexp(table[ POSIX Regexp...])
BitmapScanRegexp(table[ POSIX Regexp...]) Forces index scan, index-only scan (For PostgreSQL 9.2 and later) or bitmap scan on the table. Restricts to indexes that matches the specified POSIX regular expression pattern.

NoSeqScan(table) Forces to not do sequential scan on the table.

NoTidScan(table) Forces to not do TID scan on the table.

NoIndexScan(table) Forces to not do index scan and index-only scan on the table.

NoIndexOnlyScan(table) Forces to not do index only scan on the table.

NoBitmapScan(table) Forces to not do bitmap scan on the table.

Join method NestLoop(table table[ table...]) Forces nested loop for the joins on the tables specified.

HashJoin(table table[ table...]) Forces hash join for the joins on the tables specified.

MergeJoin(table table[ table...]) Forces merge join for the joins on the tables specified.

NoNestLoop(table table[ table...]) Forces to not do nested loop for the joins on the tables specified.

NoHashJoin(table table[ table...]) Forces to not do hash join for the joins on the tables specified.

NoMergeJoin(table table[ table...]) Forces to not do merge join for the joins on the tables specified.

Join order Leading(table table[ table...]) Forces join order as specified.

Leading(<join pair>) Forces join order and directions as specified. A join pair is a pair of tables and/or other join pairs enclosed by parentheses, which can make a nested structure.

Behavior control on Join Memoize(table table[ table...]) Allows the topmost join of a join among the specified tables to Memoize the inner result. Not enforced.

NoMemoize(table table[ table...]) Inhibits the topmost join of a join among the specified tables from Memoizing the inner result.

Row number correction Rows(table table[ table...] correction) Corrects row number of a result of the joins on the tables specified. The available correction methods are absolute (#), addition (+), subtract (-) and multiplication (*). should be a string that strtod() can understand.

Parallel query configuration Parallel(table <# of workers> [soft|hard]) Enforces or inhibits parallel execution of the specified table. <# of workers> is the desired number of parallel workers, where zero means inhibiting parallel execution. If the third parameter is soft (default), it just changes max_parallel_workers_per_gather and leaves everything else to the planner. Hard enforces the specified number of workers.

GUC Set(GUC-param value) Sets GUC parameter to the value defined while planner is running.

MySQL 8.0

https://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html

Table 8.2 Optimizer Hints Available

MySQLのOptimizer HintsはOracleにもある同一用途のヒントもちらほら。ヒント名も同一で:)

Hint Name Description Applicable Scopes

BKA, NO_BKA Affects Batched Key Access join processing Query block, table

BNL, NO_BNL Prior to MySQL 8.0.20: affects Block Nested-Loop join processing; MySQL 8.0.18 and later: also affects hash join optimization; MySQL 8.0.20 and later: affects hash join optimization only Query block, table

DERIVED_CONDITION_PUSHDOWN, NO_DERIVED_CONDITION_PUSHDOWN Use or ignore the derived condition pushdown optimization for materialized derived tables (Added in MySQL 8.0.22) Query block, table

GROUP_INDEX, NO_GROUP_INDEX Use or ignore the specified index or indexes for index scans in GROUP BY operations (Added in MySQL 8.0.20) Index

HASH_JOIN, NO_HASH_JOIN Affects Hash Join optimization (MySQL 8.0.18 only Query block, table

INDEX, NO_INDEX Acts as the combination of JOIN_INDEX, GROUP_INDEX, and ORDER_INDEX, or as the combination of NO_JOIN_INDEX, NO_GROUP_INDEX, and NO_ORDER_INDEX (Added in MySQL 8.0.20) Index

INDEX_MERGE, NO_INDEX_MERGE Affects Index Merge optimization Table, index

JOIN_FIXED_ORDER Use table order specified in FROM clause for join order Query block

JOIN_INDEX, NO_JOIN_INDEX Use or ignore the specified index or indexes for any access method (Added in MySQL 8.0.20) Index

JOIN_ORDER Use table order specified in hint for join order Query block

JOIN_PREFIX Use table order specified in hint for first tables of join order Query block

JOIN_SUFFIX Use table order specified in hint for last tables of join order Query block

MAX_EXECUTION_TIME Limits statement execution time Global

MERGE, NO_MERGE Affects derived table/view merging into outer query block Table

MRR, NO_MRR Affects Multi-Range Read optimization Table, index

NO_ICP Affects Index Condition Pushdown optimization Table, index

NO_RANGE_OPTIMIZATION Affects range optimization Table, index

ORDER_INDEX, NO_ORDER_INDEX Use or ignore the specified index or indexes for sorting rows (Added in MySQL 8.0.20) Index

QB_NAME Assigns name to query block Query block

RESOURCE_GROUP Set resource group during statement execution Global

SEMIJOIN, NO_SEMIJOIN Affects semijoin strategies; beginning with MySQL 8.0.17, this also applies to antijoins Query block

SKIP_SCAN, NO_SKIP_SCAN Affects Skip Scan optimization Table, index

SET_VAR Set variable during statement execution Global

SUBQUERY Affects materialization, IN-to-EXISTS subquery strategies Query block

いよいよ、Advent Calendar 2023の季節が近くなってきました。今年は、全部俺シリーズは、やらずに、Oracle/PostgreSQL/MySQLのカレンダーへクロスポストすることだけは決めてます〜 :)
全部俺では無いけど、いくつかエントリーは書く予定ではいます。このエントリーもAdvent Calendarネタへ繋がるネタなのですけどね。w

では、また。

関連エントリー

・Oracle Database 20c 20.1.0以降〜21c 21.1.0で v$sql_hintに追加されたヒント/ FAQ

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)
・標準はあるにはあるが癖の多いSQL 全部俺　おまけ SQL de 湯婆婆やるにも癖がでるw
・帰ってきた！標準はあるにはあるが癖の多いSQL #1 SQL de ROT13 やるにも癖が出るw
・帰ってきた！標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #3 オプティマイザの結合順評価テーブル数上限にも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #4 Optimizer Traceの取得でも癖がでる

投稿日時 2023年11月22日 (水) 20時00分 Oracle, チューニング, FAQ, SQL, MySQL, PostgreSQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2023年11月17日 (金)

Oracle Linux 8 and MySQL 8.0.32 on VirtualBox for Apple Silicon Test Build 7.0.97_BETA5r160167

ということで、ちょっと一休み的なネタです。

Apple Silicon対応はほぼ諦めていたVirtualBoxが 7.0でBETA版をリリースして大喜びしてたわけですが、
7.0.12でも正常に起動してくれないですよね。まだ。
ただ、表には出てこないですが、Test Buildでは結構進んでいるようで、嬉しいお知らせです。:)

まだ、Oracle Databaseとかは起動しないようですが、最新のTest Buildをダメ元で試してみたら、Oracle Linux 8とMySQL 8.0.32の組み合わせならDBのお遊びに使えそうな状況（次のBuild ではどうなるかわかりませんが）であることに気づきました。確実に進捗してそうで一安心。

新規VM作成ではなく、以下の手順で簡易に確認してみました。

macOS/Intel MBAのVirtualBoxにて、以下、2つのovaを作成し、M2 MBAのTest Build最新版のVirtualBoxへインポートして動作するかどうかを確認

1) Oracle Linux 8 に、PostgreSQL 13.4 と MySQL 8.0.32 を構成したVMをエクスポートして ova 作成
2) Oracle Linux 8 に、Oracle 23c Free Developer Editionを構成していたVMをエクスポートして ova 作成

結果は、
1)のMySQLは起動成功、
1)のMySQLは起動成功、
PostgreSQLは起動できず。
2)はOSは起動したがOracle起動中にエラーでVM停止

という状況。

でも、MySQL 8.0.32が、M2 MBAのVirtualBoxで使えるようになっているのはかなりの進捗なのではないかと思います。そもそもApple SiliconでVirtualBoxインストールできなくなったりしていた悲しい時期から比べれば。
いずれ、Oracleが起動するようになってくれることを期待しつつ。。Advent Calendarの記事を考えよう :)

以下、軽めの確認ログとスクリーンショットなど。

VirtualBox Test Build 7.0.97 BETA5

OVAインポート成功後、OSは正常に起動したものの、PostgreSQL 13.4 は起動失敗。 MySQL 8.0.32は起動成功！。

Oracle Database 23c Free Developer Editionを構成したovaインポート後、Database起動中にfatal errorでVM停止。惜しいね。

MySQL 8.0.32 on Oracle Linux 8.5 on VirtualBox Test Build 7.0.97 BETA5 for macOS/M1/M2でMySQLへ接続！

VirtualBoxホストの情報 M2 MBAです。

leaffish ~ % /usr/sbin/system_profiler SPHardwareDataType | grep -E '(Processor|Cores|Memory|Chip|Model Name)' Model Name: MacBook Air Chip: Apple M2 Total Number of Cores: 8 (4 performance and 4 efficiency) Memory: 24 GB

VirtualBoxは、Text Build最新(17-Nov-2023)

VirtualBox test builds
https://www.virtualbox.org/wiki/Testbuilds より、macOS/ARM64 BETAとExtension Packを利用

leaffish ~ % VBoxManage -v 7.0.97_BETA5r160167

M2 MBAのTerminalからsshでローカルのVMへ。 M2 MBAのVirtualBox Guest OSは、Oracle Linux 8.5 です。起動してますね！

leaffish ~ % ssh master@192.168.1.117 master@192.168.1.117's password: Activate the web console with: systemctl enable --now cockpit.socket [master@localhost ~]$ [master@localhost ~]$ cat /etc/oracle-release Oracle Linux Server release 8.5 [master@localhost ~]$ cat /etc/redhat-release Red Hat Enterprise Linux release 8.5 (Ootpa) [master@localhost ~]$

起動しているのは確認できましたが、MySQLへ接続してSQLを実行するまでが確認！
おおおおおおおおーーーーーーっ！。

MySQL 8.0.32 on Oracle Linux 8.5 on M2 MacBook Air VirtualBox　。Oracle Databaseではないけど、うれしくて涙が。。。出ますね。これ。

[master@localhost ~]$ mysql -u scott -D perftestdb -p Enter password: Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 8 Server version: 8.0.32 Source distribution Copyright (c) 2000, 2023, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | performance_schema | | perftestdb | +--------------------+ 3 rows in set (0.02 sec) mysql> show tables; +----------------------+ | Tables_in_perftestdb | +----------------------+ | detail | | hoge | | master | | t0 | | t1 | | t1017 | | t1017_2 | | t2 | | t3 | | t4 | +----------------------+ 10 rows in set (0.07 sec) mysql> select version(); +-----------+ | version() | +-----------+ | 8.0.32 | +-----------+ 1 row in set (0.00 sec) mysql> select * from t1; +----+-------+ | id | t1_c1 | +----+-------+ | 1 | 1 | | 2 | 2 | | 3 | 3 | | 4 | 4 | | 5 | 5 | | 6 | 6 | | 7 | 7 | | 8 | 8 | | 9 | 9 | | 10 | 10 | +----+-------+ 10 rows in set (0.04 sec) mysql> exit Bye

ついでなので、停止も試しておきましょう:)

[master@localhost ~]$ sudo service mysqld stop [[sudo] master のパスワード: Redirecting to /bin/systemctl stop mysqld.service [master@localhost ~]$ sudo shutdown -h now Connection to 192.168.1.117 closed by remote host. Connection to 192.168.1.117 closed. leaffish ~ %

週末天気悪そうで、Walkingできないかもしれない。。..

では、また。

投稿日時 2023年11月17日 (金) 12時00分 Oracle, Mac, Linux, VirtualBox, MySQL, PostgreSQL, Apple Silicon ARM64 | 固定リンク | 0 | コメント (0)

2023年9月23日 (土)

帰ってきた！標準はあるにはあるが癖の多いSQL #4 Optimizer Traceの取得でも癖がでる

Previously on Mac De Oracle
前回は、MySQLのHash Join を取り上げました。MySQL 8.0.32では NLJに使えるINDEXが存在していても、Hash Joinをヒントで強制することができる！（オプティマイザが選択することがある！）
（MySQLの生い立ちを考えると、Hash Joinとか言われると、MySQLもHash Joinが必要な時代になったのか〜。と遠くを見る自分がいるw）

ということで、今回は、前々回とりあげた、
悩ませ過ぎは及ばざるがごとし（MySQL 8.0.32編）で思い出したネタで、オプティマイザがパースに悩むというか、考えすぎている姿を、時間ではなく、オプティマイザトレースのサイズから見える化して比較！！！　してみたいと思います。

実は、
10億年以上前に、Oracle Databaseで同じことやってましたw

MySQLへ話を戻すと、
MySQLのオプティマイザトレースは、Oracle Databaseのそれとは少々ことなり、パラメータで指定されたメモリー上にJSON形式で記録され、INFORMATION_SCHEMA経由で問い合わせて確認します。
パラメータで指定されたメモリーサイズを超えるトレースは切り捨てられてしまいます。Oracle Databaseのオプティマイザトレースとは異なる注意点ですね。

また、面白い特徴もあります。
オプティマイザトレースの出力サイズを事前に予測することはできないわけですが、メモリー内に記録しきれず切り捨てたバイト数をレポートしてくれます。
その機能を利用し、切り捨てたれたトレースのバイト数とトレースを記録するために指定したメモリーのバイト数の合計からトレースのサイズを確認することはできます！　面白い仕組みを提供してくれてますよね。

余談
Oracle/MySQLは、オプティマイザトレースを明示的に取得できますが、PostgreSQLって、オプティマイザトレースだけを取得するOracleの10053トレースやMySQLのoptimizer_trace=onに類似する方法はなかったはず。
（DB側の機能の一部としてはないという認識なので、もし勘違いしていたら、ツッコミ🙇よろしくお願いします）

細けーことはこれぐらいにして、比較してみましょう。

まず、前回もネタにした、パース時間のながーーーーーーい、クエリー。
explainだけで、29秒　です！！　　11!　の組み合わせをみているわけですから、デフォルト設定のMySQL、ものすごーく考えてますよね。
OracleとかPostgreSQLならとっくに諦めている数です。

参考）
検証で利用しているMySQLの表及び索引定義とSQLスクリプトは以下ブログ参照のこと。
帰ってきた！標準はあるにはあるが癖の多いSQL #3 オプティマイザの結合順評価テーブル数上限にも癖が出る

mysql> select version(); +-----------+ | version() | +-----------+ | 8.0.32 | +-----------+ 1 row in set (0.00 sec)

mysql> \. test1.sql Database changed +----------------------------------------------------------------------------------------------------------------------+ | PLAIN | +----------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=7163.00 rows=10240) -> Nested loop inner join (cost=3579.00 rows=5120) -> Nested loop inner join (cost=1787.00 rows=2560) -> Nested loop inner join (cost=891.00 rows=1280) -> Nested loop inner join (cost=443.00 rows=640) -> Nested loop inner join (cost=219.00 rows=320) -> Nested loop inner join (cost=107.00 rows=160) -> Nested loop inner join (cost=51.00 rows=80) -> Nested loop inner join (cost=23.00 rows=40) -> Nested loop inner join (cost=9.00 rows=20) -> Index scan on master using ix_master (cost=2.00 rows=10) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.52 rows=2) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) | +----------------------------------------------------------------------------------------------------------------------+ 1 row in set (29.05 sec)

MySQLでオプティマイザトレースを取得するには、optimizer_trace を on 、optimizer_trace_max_mem_size　にオプティマイザトレース記録に必要なメモリーサイズを指定します。
その後、explain文でオプティマイザトレースを取得します。なお、今回は、explainでパース部分だけをトレースして比較します。
https://dev.mysql.com/doc/refman/8.0/en/information-schema-optimizer-trace-table.html

optimizer_trace_max_mem_size を 100 bytesにして、確実に切り捨てが起きるように設定します。

mysql> show variables like 'optimizer_trace'; +-----------------+--------------------------+ | Variable_name | Value | +-----------------+--------------------------+ | optimizer_trace | enabled=off,one_line=off | +-----------------+--------------------------+ 1 row in set (0.18 sec) mysql> SET optimizer_trace="enabled=on"; Query OK, 0 rows affected (0.01 sec) mysql> show variables like 'optimizer_trace'; +-----------------+-------------------------+ | Variable_name | Value | +-----------------+-------------------------+ | optimizer_trace | enabled=on,one_line=off | +-----------------+-------------------------+ 1 row in set (0.00 sec) mysql> show variables like 'optimizer_trace_max_mem_size'; +------------------------------+---------+ | Variable_name | Value | +------------------------------+---------+ | optimizer_trace_max_mem_size | 1048576 | +------------------------------+---------+ 1 row in set (0.00 sec) mysql> SET optimizer_trace_max_mem_size = 100; Query OK, 0 rows affected (0.00 sec) mysql> show variables like 'optimizer_trace_max_mem_size'; +------------------------------+-------+ | Variable_name | Value | +------------------------------+-------+ | optimizer_trace_max_mem_size | 100 | +------------------------------+-------+ 1 row in set (0.00 sec)

オプティマイザトレースの準備ができたので、explainしてみましょう！

mysql> \. test1.sql Database changed +----------------------------------------------------------------------------------------------------------------------+ | PLAIN | +----------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=7163.00 rows=10240) -> Nested loop inner join (cost=3579.00 rows=5120) -> Nested loop inner join (cost=1787.00 rows=2560) -> Nested loop inner join (cost=891.00 rows=1280) -> Nested loop inner join (cost=443.00 rows=640) -> Nested loop inner join (cost=219.00 rows=320) -> Nested loop inner join (cost=107.00 rows=160) -> Nested loop inner join (cost=51.00 rows=80) -> Nested loop inner join (cost=23.00 rows=40) -> Nested loop inner join (cost=9.00 rows=20) -> Index scan on master using ix_master (cost=2.00 rows=10) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.52 rows=2) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) | +----------------------------------------------------------------------------------------------------------------------+ 1 row in set (7 min 3.67 sec)

次に、INFORMATION_SCHEMA.OPTIMIZER_TRACEからオプティマイザトレースを取得してみます。

2147483647 bytes （切り捨てられたトレースのサイズ）+ 100 bytes （optimizer_trace_max_mem_sizeパラメータに指定したサイズ）= 2,147,483,747 bytes およそ 2GB です

mysql> SELECT * FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE\G *************************** 1. row *************************** QUERY: explain format=tree select * from master inner join detail on master.id = detail.id inner join detail t2 on t2.id = detail.id inner join detail t3 on t3.id = t2.id inner join detail t4 on t4.id = t3.id inner join detail t5 on t5.id = t4.id inner join detail t6 on t6.id = t5.id inner join detail t7 on t7.id = t6.id inner join detail t8 on t8.id = t7.id inner join detail t9 on t9.id = t8.id inner join detail t10 on t10.id = t9.id TRACE: { "steps": [ { "join_preparation": { "select#": 1, "steps": [ { "expanded_query": "/* select#1 */ select `master`.`id` AS `id`,`master`.`dummya` AS `dummya`,`detail`.`id` AS `id`,`detail`.`subid` AS `subid`,`detail`.`dummya` AS `dummya`,`t2`.`id` AS `id`, `t2`.`subid` AS `subid`,`t2`.`dummya` AS `dummya`,`t3`.`id` AS `id`,`t3`.`subid` AS `subid`,`t3`.`dummya` AS `dummya`,`t4`.`id` AS `id`,`t4`.`subid` AS `subid`,`t4`.`dummya` AS `dummya`, `t5`.`id` AS `id`,`t5`.`subid` AS `subid`,`t5`.`dummya` AS `dummya`,`t6`.`id` AS `id`,`t6`.`subid` AS `subid`,`t6`.`dummya` AS `dummya`,`t7`.`id` AS `id`,`t7`.`subid` AS `subid`, `t7`.`dummya` AS `dummya`,`t8`.`id` AS `id`,`t8`.`subid` AS `subid`,`t8`.`dummya` AS `dummya`,`t9`.`id` AS `id`,`t9`.`subid` AS `subid`,`t9`.`dummya` AS `dummya`,`t10`.`id` AS `id`, `t10`.`subid` AS `subid`,`t10`.`dummya` AS `dummya` from ((((((((((`master` join `detail` on((`master`.`id` = `detail`.`id`))) join `detail` `t2` on((`t2`.`id` = `detail`.`id`))) join `detail` `t3` on((`t3`.`id` = `t2`.`id`))) join `detail` `t4` on((`t4`.`id` = `t3`.`id`))) join `detail` `t5` on((`t5`.`id` = `t4`.`id`))) join `detail` `t6` on((`t6`.`id` = `t5`.`id`))) join `detail` `t7` on((`t7`.`id` = `t6`.`id`))) join `detail` `t8` on((`t8`.`id` = `t7`.`id`))) join `detail` `t9` on((`t9`.`id` = `t8`.`id`))) join `detail` `t10` on((`t10`.`id` = `t9`.`id`)))" }, { "transformations_to_nested_joins": { "transformations": [ "JOIN_condition_to_WHERE", "parenthesis_removal" ], "expanded_query": "/* select#1 */ select `master`.`id` AS `id`,`master`.`dummya` AS `dummya`,`detail`.`id` AS `id`,`detail`.`subid` AS `subid`,`detail`.`dummya` AS `dummya`, `t2`.`id` AS `id`,`t2`.`subid` AS `subid`,`t2`.`dummya` AS `dummya`,`t3`.`id` AS `id`,`t3`.`subid` AS `subid`,`t3`.`dummya` AS `dummya`,`t4`.`id` AS `id`,`t4`.`subid` AS `subid`, `t4`.`dummya` AS `dummya`,`t5`.`id` AS `id`,`t5`.`subid` AS `subid`,`t5`.`dummya` AS `dummya`,`t6`.`id` AS `id`,`t6`.`subid` AS `subid`,`t6`.`dummya` AS `dummya`,`t7`.`id` AS `id`, `t7`.`subid` AS `subid`,`t7`.`dummya` AS `dummya`,`t8`.`id` AS `id`,`t8`.`subid` AS `subid`,`t8`.`dummya` AS `dummya`,`t9`.`id` AS `id`,`t9`.`subid` AS `subid`, `t9`.`dummya` AS `dummya`,`t10`.`id` AS `id`,`t10`.`subid` AS `subid`,`t10`.`dummya` AS `dummya` from `master` join `detail` join `detail` `t2` join `detail` `t3` join `detail` `t4` join `detail` `t5` join `detail` `t6` join `detail` `t7` join `detail` `t8` join `detail` `t9` join `detail` `t10` where ((`t10`.`id` = `t9`.`id`) and (`t9`.`id` = `t8`.`id`) and (`t8`.`id` = `t7`.`id`) and (`t7`.`id` = `t6`.`id`) and (`t6`.`id` = `t5`.`id`) and (`t5`.`id` = `t4`.`id`) and (`t4`.`id` = `t3`.`id`) and (`t3`.`id` = `t2`.`id`) and (`t2`.`id` = `detail`.`id`) and (`master`.`id` = `detail`.`id`))" } } ] } }, ....中略.... }, "condition_filtering_pct": 100, "rows_for_plan": 10240, "cost_for_plan": 7163, "pruned_by_cost": true } MISSING_BYTES_BEYOND_MAX_MEM_SIZE: 2147483647 INSUFFICIENT_PRIVILEGES: 0 1 row in set (0.26 sec) mysql>

次に、考え過ぎているオプティマイザに、
JOIN_ORDERヒントを利用し、結合順を　考えるな！　感じろ！　作戦でオプティマイザに考えさせないように。。。パースも速いし、オプティマイザトレースのJSONのサイズも小さい!

mysql> \. test1.sql Database changed +----------------------------------------------------------------------------------------------------------------------+ | PLAIN | +----------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=7163.00 rows=10240) -> Nested loop inner join (cost=3579.00 rows=5120) -> Nested loop inner join (cost=1787.00 rows=2560) -> Nested loop inner join (cost=891.00 rows=1280) -> Nested loop inner join (cost=443.00 rows=640) -> Nested loop inner join (cost=219.00 rows=320) -> Nested loop inner join (cost=107.00 rows=160) -> Nested loop inner join (cost=51.00 rows=80) -> Nested loop inner join (cost=23.00 rows=40) -> Nested loop inner join (cost=9.00 rows=20) -> Index scan on master using ix_master (cost=2.00 rows=10) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.52 rows=2) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) | +----------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec)

オプティマイザトレース結果のJSONサイズは、

57379 bytes (切り捨てられたトレースのバイト数) + 100 bytes（optimizer_trace_max_mem_sizeパラメータに指定したサイズ） = 57,479 bytes 、約　56 KBとなりました。

2GB vs 56KB

オプティマイザトレースのJSONサイズからオプティマイザの仕事量を覗いてみるのも面白いですよね。（俺だけか喜んでるのw）

mysql> SELECT * FROM INFORMATION_SCHEMA.OPTIMIZER_TRACE\G *************************** 1. row *************************** QUERY: explain format=tree select /*+ JOIN_ORDER(master,detail,t2,t3,t4,t5,t6,t7,t8,t9,t10) */ * from master inner join detail on master.id = detail.id inner join detail t2 on t2.id = detail.id inner join detail t3 on t3.id = t2.id inner join detail t4 on t4.id = t3.id inner join detail t5 on t5.id = t4.id inner join detail t6 on t6.id = t5.id inner join detail t7 on t7.id = t6.id inner join detail t8 on t8.id = t7.id inner join detail t9 on t9.id = t8.id inner join detail t10 on t10.id = t9.id TRACE: MISSING_BYTES_BEYOND_MAX_MEM_SIZE: 57379 INSUFFICIENT_PRIVILEGES: 0 1 row in set (0.00 sec)

ということで、　MySQLのオプティマイザトレースはメモリー中に記録され、メモリーに記録できないトレースは切り捨てられる。
また、切り捨てられたサイズ＋オプティマイザトレース向けメモリーサイズからトレースを完全に取得するためのメモリーサイズを確認できる。
ただし、必要がメモリーの空き次第ではありそうですね。ということで、Oracle Databaseの 10053トレースとはちょっと違う注意点もあるな。

という知見を得た :)

Oracle Database の 10053トレースでのトレースによる考えている仕事量の見える化同様に、MySQLのオプティマイザトレースでも、オプティマイザが考えすぎていると様子をトレースサイズで見える化してみるという検証はここまで。
MySQLのオプティマイザトレースをなんとなく眺めて、なぜ、その判断をしたのだなどを追うのはまた別の機会に;)

10月も近いのに、muggy　な気候の続く、東京より。

ではまた。

関連エントリー
・悩ませ過ぎは及ばざるがごとし（MySQL 8.0.32編）
・悩ませ過ぎは及ばざるがごとし #7 - おまけ

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)
・標準はあるにはあるが癖の多いSQL 全部俺　おまけ SQL de 湯婆婆やるにも癖がでるw
・帰ってきた！標準はあるにはあるが癖の多いSQL #1 SQL de ROT13 やるにも癖が出るw
・帰ってきた！標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出る
・帰ってきた！標準はあるにはあるが癖の多いSQL #3 オプティマイザの結合順評価テーブル数上限にも癖が出る

投稿日時 2023年9月23日 (土) 08時25分 Oracle, チューニング, FAQ, SQL, MySQL, PostgreSQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2023年9月 7日 (木)

MySQL 8.0.32では NLJに使えるINDEXが存在していても、Hash Joinをヒントで強制することができる！（オプティマイザが選択することがある！）

Previously on Mac De Oracle
前回は悩ませ過ぎは及ばざるがごとし（MySQL 8.0.32編）で、パース時間が長い場合、ヒントを使うことでパース時間を短縮させることが可能なケースもあるというという話でした。Oracleでも同様のケースがあることもお話ししました。が、その中で、MySQL 8.0.32 ではオプティマイザが、NLJで利用するINDEXが存在していても、HJを選択することがあることに気づいた！（どうやら、該当表がバッファープールに乗っているとNLJを選択しやすくなる傾向もありそう）という、予告編までw

ということで、今日は、MySQL 8.0.32　では、NLJに利用するINDEXが存在していても、オプティマイザは、HJを選択することもあるし、ヒントによってHJを矯正できるのか？　ということを確認してみました。

これまでの、MySQL 8.0.x台のHash Joinの適用範囲および挙動は以下のブログで取り上げられています。（非常に参考になりました。ありがたいですね。本当に ;)

MySQL 8.0.18のHASH JOINを試した（tom__bo’s Blog）
https://tombo2.hatenablog.com/entry/2019/10/14/212100

MySQL 8.0.20 のハッシュジョイン（Hash Join）を INDEX があるテーブルで試してみる（Qiita @hmatsu47）
https://qiita.com/hmatsu47/items/e473a3e566b910d61f5b

MySQL 8.0.20 でHASH JOINが効くケースが拡大した (mita2 database life)
https://mita2db.hateblo.jp/entry/2020/05/03/174101

と、NLJ可能な索引があるとなぜか、HJにならなかった。ついでに、HASH_JOINというヒントは、8.0.18でしか効果がない！
https://dev.mysql.com/doc/refman/8.0/ja/optimizer-hints.html#optimizer-hints-table-level

MySQL 8.0 Manual
https://dev.mysql.com/doc/refman/8.0/en/hash-joins.html

"8.2.1.4 Hash Join Optimization By default, MySQL (8.0.18 and later) employs hash joins whenever possible. It is possible to control whether hash joins are employed using one of the BNL and NO_BNL optimizer hints, or by setting block_nested_loop=on or block_nested_loop=off as part of the setting for the optimizer_switch server system variable.
Note
MySQL 8.0.18 supported setting a hash_join flag in optimizer_switch, as well as the optimizer hints HASH_JOIN and NO_HASH_JOIN. In MySQL 8.0.19 and later, none of these have any effect any longer.

Beginning with MySQL 8.0.18, MySQL employs a hash join for any query for which each join has an equi-join condition, and in which there are no indexes that can be applied to any join conditions, such as this one:"

ななな、なーーーん、だってーーーーーーっ！。

だが、しかし、8.0.32 になるとマニュアルの記載では特に見かけなかったが、NLJに使える索引がある場合でも等価結合でHash Joinになるではありませんか。みなさん！

まじでーーーというか、実際、そうなるもん！

以下、前回のブログ参照のこと。
悩ませ過ぎは及ばざるがごとし（MySQL 8.0.32編） (Mac De Oracle)
https://discus-hamburg.cocolog-nifty.com/mac_de_oracle/2023/09/post-bee50f.html

ただし、 HASH_JOINヒントは使えないので、どのようにヒントを書けば Hash Joinを強制できるのだろう？　8.0.32編　ということで、試してみた！

結論から言ってしまうと

MySQL 8.0.32　では NLJに使えるINDEXが存在していても、Hash Joinを強制することができる！　（いつから変わったかは不明だが、8.0.32では可能！）
MySQL 8.0.32　では NLJに使えるINDEXが存在していても、Hash Joinを強制することができる！　（いつから変わったかは不明だが、8.0.32では可能！）

詳細は、以下の検証を。比較的気楽にヒントでHJを強制できるようです（だたしちょっと分かりずらいね。Oracleとかと比べると）

表定義等は前々回のエントリー参照のこと。帰ってきた！標準はあるにはあるが癖の多いSQL #3 オプティマイザの結合順評価テーブル数上限にも癖が出る

起動直後、バッファキャッシュが空だと（未検証）Hash Joinが選択されるので、まずは、オプティマイザが Hash Join (等価結合でNLJに利用できる索引が存在する状況でも）が選択されている（前回のブログのおさらい）

[master@localhost ~]$ sudo service mysqld restart Redirecting to /bin/systemctl restart mysqld.service [master@localhost ~]$ mysql -u scott -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 8 Server version: 8.0.32 Source distribution Copyright (c) 2000, 2023, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> select version(); +-----------+ | version() | +-----------+ | 8.0.32 | +-----------+ 1 row in set (0.00 sec) mysql> mysql> \. test1.sql Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed +----------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +----------------------------------------------------------------------------------------------------------------------+ | -> Inner hash join (t10.id = `master`.id) (cost=20489.43 rows=10240) -> Table scan on t10 (cost=0.00 rows=20) -> Hash -> Inner hash join (t9.id = `master`.id) (cost=10238.74 rows=5120) -> Table scan on t9 (cost=0.00 rows=20) -> Hash -> Inner hash join (t8.id = `master`.id) (cost=5113.38 rows=2560) -> Table scan on t8 (cost=0.00 rows=20) -> Hash -> Inner hash join (t7.id = `master`.id) (cost=2550.45 rows=1280) -> Table scan on t7 (cost=0.00 rows=20) -> Hash -> Inner hash join (t6.id = `master`.id) (cost=1268.60 rows=640) -> Table scan on t6 (cost=0.00 rows=20) -> Hash -> Inner hash join (t5.id = `master`.id) (cost=627.24 rows=320) -> Table scan on t5 (cost=0.01 rows=20) -> Hash -> Inner hash join (t4.id = `master`.id) (cost=306.09 rows=160) -> Table scan on t4 (cost=0.02 rows=20) -> Hash -> Inner hash join (t3.id = `master`.id) (cost=145.03 rows=80) -> Table scan on t3 (cost=0.03 rows=20) -> Hash -> Inner hash join (t2.id = `master`.id) (cost=64.01 rows=40) -> Table scan on t2 (cost=0.06 rows=20) -> Hash -> Inner hash join (detail.id = `master`.id) (cost=23.00 rows=20) -> Table scan on detail (cost=0.12 rows=20) -> Hash -> Index scan on master using ix_master (cost=2.00 rows=10) | +----------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.01 sec)

関連する表をアクセスしてバッファープールに乗った状態にすると。オプティマイザは、INDEXを利用したNLJを選択するようになった。（前回のブログのおさらい）

mysql> mysql> select * from master; +----+--------+ | id | dummya | +----+--------+ | 1 | 1 | | 10 | 10 | ....中略.... | 7 | 7 | | 8 | 8 | | 9 | 9 | +----+--------+ 10 rows in set (0.01 sec) mysql> select * from detail; +----+-------+--------+ | id | subid | dummya | +----+-------+--------+ | 1 | 1 | 11 | | 1 | 2 | 12 | | 2 | 1 | 21 | | 2 | 2 | 22 | ....中略.... | 9 | 1 | 91 | | 9 | 2 | 92 | | 10 | 1 | 101 | | 10 | 2 | 102 | +----+-------+--------+ 20 rows in set (0.01 sec) mysql> \. test1.sql Database changed +----------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +----------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=7163.00 rows=10240) -> Nested loop inner join (cost=3579.00 rows=5120) -> Nested loop inner join (cost=1787.00 rows=2560) -> Nested loop inner join (cost=891.00 rows=1280) -> Nested loop inner join (cost=443.00 rows=640) -> Nested loop inner join (cost=219.00 rows=320) -> Nested loop inner join (cost=107.00 rows=160) -> Nested loop inner join (cost=51.00 rows=80) -> Nested loop inner join (cost=23.00 rows=40) -> Nested loop inner join (cost=9.00 rows=20) -> Index scan on master using ix_master (cost=2.00 rows=10) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.52 rows=2) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) | +----------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec)

オプティマイザがNLJを選択するようになった状況で、Hash Join となるヒントを追加（ヒント等は後半のスクリプト test1_hj.sql　を参照のこと）すると、NLJで利用可能なINDEXが存在していたとしても、HJを強制できる。(8.0.20ごろまでは、HJは選択されなかったようなので、8.0.21から8.0.32の間でHJの適用範囲がさらに拡大されたのでしょうね。想像ですけども）

mysql> mysql> \. test1_hj.sql Database changed +----------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +----------------------------------------------------------------------------------------------------------------------+ | -> Inner hash join (t10.id = `master`.id) (cost=20468.86 rows=10240) -> Table scan on t10 (cost=0.00 rows=20) -> Hash -> Inner hash join (t9.id = `master`.id) (cost=10226.19 rows=5120) -> Table scan on t9 (cost=0.00 rows=20) -> Hash -> Inner hash join (t8.id = `master`.id) (cost=5104.85 rows=2560) -> Table scan on t8 (cost=0.00 rows=20) -> Hash -> Inner hash join (t7.id = `master`.id) (cost=2544.11 rows=1280) -> Table scan on t7 (cost=0.00 rows=20) -> Hash -> Inner hash join (t6.id = `master`.id) (cost=1263.65 rows=640) -> Table scan on t6 (cost=0.00 rows=20) -> Hash -> Inner hash join (t5.id = `master`.id) (cost=623.31 rows=320) -> Table scan on t5 (cost=0.00 rows=20) -> Hash -> Inner hash join (t4.id = `master`.id) (cost=303.02 rows=160) -> Table scan on t4 (cost=0.01 rows=20) -> Hash -> Inner hash join (t3.id = `master`.id) (cost=142.76 rows=80) -> Table scan on t3 (cost=0.01 rows=20) -> Hash -> Inner hash join (t2.id = `master`.id) (cost=62.50 rows=40) -> Table scan on t2 (cost=0.02 rows=20) -> Hash -> Inner hash join (detail.id = `master`.id) (cost=22.25 rows=20) -> Table scan on detail (cost=0.05 rows=20) -> Hash -> Table scan on master (cost=2.00 rows=10) | +----------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.03 sec)

ついでなので、NLJになるようにがっつりヒントで固めてみた場合はどうなるか？　想定通り、NLJに倒せますね。（前回のブログのおさらい）

mysql> mysql> \. test1_nlj.sql Database changed +----------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +----------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=7173.00 rows=10240) -> Nested loop inner join (cost=3589.00 rows=5120) -> Nested loop inner join (cost=1797.00 rows=2560) -> Nested loop inner join (cost=901.00 rows=1280) -> Nested loop inner join (cost=453.00 rows=640) -> Nested loop inner join (cost=229.00 rows=320) -> Nested loop inner join (cost=117.00 rows=160) -> Nested loop inner join (cost=61.00 rows=80) -> Nested loop inner join (cost=33.00 rows=40) -> Nested loop inner join (cost=19.00 rows=20) -> Index scan on master using ix_master (cost=12.00 rows=10) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.52 rows=2) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) | +----------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) mysql>

検証で利用した表と索引定義は前回のブログ参照のこと。

以下、今回検証で利用したスクリプト

オリジナル。結合順だけ JOIN_ORDERで制御。オプティマイザが、NLJ/HJをその時の気分で（嘘w）、その時の状況で判断して、NLJ/HJのいずれかを選択する（ことがわかっている 8.0.32　では）

[master@localhost ~]$ cat test1.sql use perftestdb; explain format=tree select /*+ JOIN_ORDER(master,detail,t2,t3,t4,t5,t6,t7,t8,t9,t10) */ * from master inner join detail on master.id = detail.id inner join detail t2 on t2.id = detail.id inner join detail t3 on t3.id = t2.id inner join detail t4 on t4.id = t3.id inner join detail t5 on t5.id = t4.id inner join detail t6 on t6.id = t5.id inner join detail t7 on t7.id = t6.id inner join detail t8 on t8.id = t7.id inner join detail t9 on t9.id = t8.id inner join detail t10 on t10.id = t9.id ;

JOIN_ORDER/NO_INDEX/NO_JOIN_INDEXヒントを利用して、結合順と索引スキャンの抑止、そして、NLJで利用する索引の利用を抑止することで　HJ　になるようにしたスクリプト

[master@localhost ~]$ cat test1_hj.sql use perftestdb; explain format=tree select /*+ JOIN_ORDER(master,detail,t2,t3,t4,t5,t6,t7,t8,t9,t10) NO_INDEX(master ix_master) NO_JOIN_INDEX(detail primary) NO_JOIN_INDEX(t2 primary) NO_JOIN_INDEX(t3 primary) NO_JOIN_INDEX(t4 primary) NO_JOIN_INDEX(t5 primary) NO_JOIN_INDEX(t6 primary) NO_JOIN_INDEX(t7 primary) NO_JOIN_INDEX(t8 primary) NO_JOIN_INDEX(t9 primary) NO_JOIN_INDEX(t10 primary) */ * from master inner join detail on master.id = detail.id inner join detail t2 on t2.id = detail.id inner join detail t3 on t3.id = t2.id inner join detail t4 on t4.id = t3.id inner join detail t5 on t5.id = t4.id inner join detail t6 on t6.id = t5.id inner join detail t7 on t7.id = t6.id inner join detail t8 on t8.id = t7.id inner join detail t9 on t9.id = t8.id inner join detail t10 on t10.id = t9.id ;

最後に、前回も利用した NLJ　に倒すためのガチガチヒントバージョンのスクリプト

[master@localhost ~]$ cat test1_nlj.sql use perftestdb; explain format=tree select /*+ JOIN_ORDER(master,detail,t2,t3,t4,t5,t6,t7,t8,t9,t10) INDEX(master ix_master) JOIN_INDEX(detail primary) JOIN_INDEX(t2 primary) JOIN_INDEX(t3 primary) JOIN_INDEX(t4 primary) JOIN_INDEX(t5 primary) JOIN_INDEX(t6 primary) JOIN_INDEX(t7 primary) JOIN_INDEX(t8 primary) JOIN_INDEX(t9 primary) JOIN_INDEX(t10 primary) */ * from master inner join detail on master.id = detail.id inner join detail t2 on t2.id = detail.id inner join detail t3 on t3.id = t2.id inner join detail t4 on t4.id = t3.id inner join detail t5 on t5.id = t4.id inner join detail t6 on t6.id = t5.id inner join detail t7 on t7.id = t6.id inner join detail t8 on t8.id = t7.id inner join detail t9 on t9.id = t8.id inner join detail t10 on t10.id = t9.id ;

ということで、まだまだまだ、蒸し暑いし、台風直撃しそうな、東京からお送りしました。台風に注意しつつ週末を過ごすしかなさそう。

では、また。

・悩ませ過ぎは及ばざるがごとし（MySQL 8.0.32編）

投稿日時 2023年9月 7日 (木) 17時10分チューニング, FAQ, SQL, MySQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2023年9月 2日 (土)

帰ってきた！標準はあるにはあるが癖の多いSQL #3 オプティマイザの結合順評価テーブル数上限にも癖が出る

Previously on Mac De Oracle前回の癖はw
帰ってきた！標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出る
でした。
実は、今日の癖は、その検証時に気づいた、MySQLで結合表数が多いと、パース時間長くなってね？　というか長いよね！　という点。

オプティマイザは、皆さんの難しい（いや、難しい必要はないですが）SQLを無駄なく、そのSQLに見合った最短の時間で結果を返そうと努力して実行計画を立てています。これを解析フェーズとかパース時間とか、ハードパース時間とかいくつかのバリエーションで表現していたりします。
今回は、中をとってw パース時間としますね。SQL文の実行計画を立てる、オプティマイザがあれやこれや考えて実行計画を立て終えるまでの時間のことです。

先日の検証で、10表結合したのですが、MySQLでは、20秒以上要していました。実行計画でオプティマイザ考えすぎて帰ってこない。SQL文の実行ではなく実行計画を立てるところで時間がかかるケースはいくつか有名なのがありますが。
そうならないように各データベースは閾値を設けています。今回は、結合順評価テーブル数上限　ってやつです。結合する表の順序の組み合わせをどこまで検討するかということなのですが、これが、票数が増えると鰻登りに増加します。
今回のケースだと、1011表なので、10!11!ですね。2表をを繰り返し結合していてもしっかり考えてくれちゃいます。

ただ、何も考えずにオプティマイザに時間を与えていると、パース時間だけでとんでもない時間になったり、性能要件に見合わないといったケースが出てきます。なので、適当なところで手を打って、オプティマイザに考えさせ過ぎないようしています。
その閾値のデフォルト値が、MySQLとOracle/PostgreSQLとでは結構違うみたい。というところが今回の癖！

ちなみに、Oracleの例ですが、結合以外にINリストに大量にリテラルがあり、かつ考慮する必要のある索引も多いケースでは、悩ませ過ぎは及ばざるがごとし #7 - おまけなんてことも起こりますw オプティマイザを悩ませすぎると大変なので、そんな時は、SQLヒントなどを使って、オプティマイザに考えさせないという治療で回避するのが特効薬ですw

余談はこれぐらいにして、本題へ。

Note:
(MySQL/PostgreSQL/Oracle 23c freeそれぞれ、同一Virtualbox VMを利用して検証しているため、CPUリソース等の差異はありません）

最初は、ネタの発端になったMySQL 8.0.32から

mysql> select version(); +-----------+ | version() | +-----------+ | 8.0.32 | +-----------+ 1 row in set (0.00 sec) mysql> show tables; +----------------------+ | Tables_in_perftestdb | +----------------------+ | detail | | master | +----------------------+ 2 rows in set (0.00 sec) mysql> desc detail; +--------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------+-------------+------+-----+---------+-------+ | id | int | NO | PRI | NULL | | | subid | int | NO | PRI | NULL | | | dummya | varchar(10) | YES | | NULL | | +--------+-------------+------+-----+---------+-------+ 3 rows in set (0.00 sec) mysql> show indexes from detail; +--------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible | Expression | +--------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+ | detail | 0 | PRIMARY | 1 | id | A | 10 | NULL | NULL | | BTREE | | | YES | NULL | | detail | 0 | PRIMARY | 2 | subid | A | 20 | NULL | NULL | | BTREE | | | YES | NULL | +--------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+ 2 rows in set (0.02 sec) mysql> desc master; +--------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------+-------------+------+-----+---------+-------+ | id | int | NO | PRI | NULL | | | dummya | varchar(10) | YES | MUL | NULL | | +--------+-------------+------+-----+---------+-------+ 2 rows in set (0.00 sec) mysql> show indexes from master; +--------+------------+-----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible | Expression | +--------+------------+-----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+ | master | 0 | PRIMARY | 1 | id | A | 10 | NULL | NULL | | BTREE | | | YES | NULL | | master | 1 | ix_master | 1 | dummya | A | 10 | NULL | NULL | YES | BTREE | | | YES | NULL | +--------+------------+-----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+ 2 rows in set (0.02 sec) mysql> analyze table master; +-------------------+---------+----------+----------+ | Table | Op | Msg_type | Msg_text | +-------------------+---------+----------+----------+ | perftestdb.master | analyze | status | OK | +-------------------+---------+----------+----------+ 1 row in set (0.04 sec) mysql> analyze table detail; +-------------------+---------+----------+----------+ | Table | Op | Msg_type | Msg_text | +-------------------+---------+----------+----------+ | perftestdb.detail | analyze | status | OK | +-------------------+---------+----------+----------+ 1 row in set (0.02 sec) mysql>

表定義とデータは以前のエントリーも参考に
MySQL 8.0.32 / explain analyze 実行途中でキャンセルできるみたいだけど、キャンセルしたら、Actual Plan、途中まで出るの？

では、

MySQL 8.0.32で、パースに時間を要するケースの再現。optimizer_search_depthパラメータはデフォルトのまま

MySQL : optimizer_search_depth optimizer_search_depth

mysql> show variables like 'optimizer_search_depth'; +------------------------+-------+ | Variable_name | Value | +------------------------+-------+ | optimizer_search_depth | 62 | +------------------------+-------+ 1 row in set (0.00 sec) mysql> \. test1.sql Database changed +----------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +----------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=7162.25 rows=10240) -> Nested loop inner join (cost=3578.25 rows=5120) -> Nested loop inner join (cost=1786.25 rows=2560) -> Nested loop inner join (cost=890.25 rows=1280) -> Nested loop inner join (cost=442.25 rows=640) -> Nested loop inner join (cost=218.25 rows=320) -> Nested loop inner join (cost=106.25 rows=160) -> Nested loop inner join (cost=50.25 rows=80) -> Nested loop inner join (cost=22.25 rows=40) -> Nested loop inner join (cost=8.25 rows=20) -> Index scan on master using ix_master (cost=1.25 rows=10) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.52 rows=2) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) | +----------------------------------------------------------------------------------------------------------------------+ 1 row in set (21.37 sec)

パースに 21.37 sec 要していますね。 62!まで結合順を探査する設定ですから、このケースだと、10!まで行っているということなのでしょうね。

では、Oracleなどで設けられてる閾値と同等の　6　にせってしてみた場合のパース時間はどうでしょうね。このケースで実行計画を間違うことはない（単純なので）ですが、複雑な結合だと、実行計画をミスする率は多くなりそうですけども、Oracleとかだとその程度で使ってますし。。この程度でも良いのかもしれません。時間かかってもいいよというケースも当然あるので、非機能要件次第ではありますけどね。

mysql> set optimizer_search_depth = 6; Query OK, 0 rows affected (0.00 sec) mysql> show variables like 'optimizer_search_depth'; +------------------------+-------+ | Variable_name | Value | +------------------------+-------+ | optimizer_search_depth | 6 | +------------------------+-------+ 1 row in set (0.00 sec) mysql> \. test1.sql Database changed +----------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +----------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=7162.25 rows=10240) -> Nested loop inner join (cost=3578.25 rows=5120) -> Nested loop inner join (cost=1786.25 rows=2560) -> Nested loop inner join (cost=890.25 rows=1280) -> Nested loop inner join (cost=442.25 rows=640) -> Nested loop inner join (cost=218.25 rows=320) -> Nested loop inner join (cost=106.25 rows=160) -> Nested loop inner join (cost=50.25 rows=80) -> Nested loop inner join (cost=22.25 rows=40) -> Nested loop inner join (cost=8.25 rows=20) -> Index scan on master using ix_master (cost=1.25 rows=10) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.52 rows=2) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) | +----------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.27 sec)

はい！　パース時間は、一気短縮され、 0.27 sec　になりました。Oracleのハードパースでもこれぐらいなこんな程度だとは思います。

次に、PostgreSQLで確認してみましょ。 PostgreSQLの場合は、Oracleに近かったはず。表定義とデータ量は同じです。

PostgreSQLでは、結合順序評価上限は以下join_collapse_limitパラメータで制御するようですね。あまり気にしてなかったので脳のしわが一つ増えた！ defaultは、8　でOracleより多少、多いというところですね。
join_collapse_limit

perftestdb=> select version(); version -------------------------------------------------------------------------------------------------------- PostgreSQL 13.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4), 64-bit (1 行) perftestdb=> show join_collapse_limit; join_collapse_limit --------------------- 8 (1 行) perftestdb=> \d+ master テーブル"public.master" 列 | タイプ | 照合順序 | Null 値を許容 | デフォルト | ストレージ | 統計目標 | 説明 --------+-----------------------+----------+---------------+------------+------------+----------+------ id | integer | | not null | | plain | | dummya | character varying(10) | | | | extended | | インデックス: "master_pkey" PRIMARY KEY, btree (id) アクセスメソッド: heap perftestdb=> \d+ detail テーブル"public.detail" 列 | タイプ | 照合順序 | Null 値を許容 | デフォルト | ストレージ | 統計目標 | 説明 --------+-----------------------+----------+---------------+------------+------------+----------+------ id | integer | | not null | | plain | | subid | integer | | not null | | plain | | dummya | character varying(10) | | | | extended | | インデックス: "pk_detail" PRIMARY KEY, btree (id, subid) アクセスメソッド: heap perftestdb=> analyze verbose master; INFO: analyzing "public.master" INFO: "master": scanned 1 of 1 pages, containing 10 live rows and 0 dead rows; 10 rows in sample, 10 estimated total rows ANALYZE perftestdb=> analyze verbose detail; INFO: analyzing "public.detail" INFO: "detail": scanned 1 of 1 pages, containing 20 live rows and 0 dead rows; 20 rows in sample, 20 estimated total rows ANALYZE perftestdb=>

では試してみましょう。

perftestdb=> \timing on タイミングは on です。 perftestdb=> perftestdb=> perftestdb=> \i ./test1_pg.sql QUERY PLAN ----------------------------------------------------------------------------------------------- Hash Join (cost=19.53..156.40 rows=10240 width=116) Hash Cond: (master.id = t8.id) -> Hash Join (cost=12.93..31.40 rows=1280 width=83) Hash Cond: (master.id = detail.id) -> Hash Join (cost=6.33..10.00 rows=160 width=50) Hash Cond: (master.id = t4.id) -> Hash Join (cost=2.67..4.45 rows=40 width=28) Hash Cond: (master.id = t7.id) -> Hash Join (cost=1.23..2.50 rows=20 width=17) Hash Cond: (t6.id = master.id) -> Seq Scan on detail t6 (cost=0.00..1.20 rows=20 width=11) -> Hash (cost=1.10..1.10 rows=10 width=6) -> Seq Scan on master (cost=0.00..1.10 rows=10 width=6) -> Hash (cost=1.20..1.20 rows=20 width=11) -> Seq Scan on detail t7 (cost=0.00..1.20 rows=20 width=11) -> Hash (cost=3.15..3.15 rows=40 width=22) -> Hash Join (cost=1.45..3.15 rows=40 width=22) Hash Cond: (t4.id = t5.id) -> Seq Scan on detail t4 (cost=0.00..1.20 rows=20 width=11) -> Hash (cost=1.20..1.20 rows=20 width=11) -> Seq Scan on detail t5 (cost=0.00..1.20 rows=20 width=11) -> Hash (cost=5.60..5.60 rows=80 width=33) -> Hash Join (cost=2.90..5.60 rows=80 width=33) Hash Cond: (detail.id = t3.id) -> Hash Join (cost=1.45..3.15 rows=40 width=22) Hash Cond: (detail.id = t2.id) -> Seq Scan on detail (cost=0.00..1.20 rows=20 width=11) -> Hash (cost=1.20..1.20 rows=20 width=11) -> Seq Scan on detail t2 (cost=0.00..1.20 rows=20 width=11) -> Hash (cost=1.20..1.20 rows=20 width=11) -> Seq Scan on detail t3 (cost=0.00..1.20 rows=20 width=11) -> Hash (cost=5.60..5.60 rows=80 width=33) -> Hash Join (cost=2.90..5.60 rows=80 width=33) Hash Cond: (t8.id = t10.id) -> Hash Join (cost=1.45..3.15 rows=40 width=22) Hash Cond: (t8.id = t9.id) -> Seq Scan on detail t8 (cost=0.00..1.20 rows=20 width=11) -> Hash (cost=1.20..1.20 rows=20 width=11) -> Seq Scan on detail t9 (cost=0.00..1.20 rows=20 width=11) -> Hash (cost=1.20..1.20 rows=20 width=11) -> Seq Scan on detail t10 (cost=0.00..1.20 rows=20 width=11) (41 行) 時間: 29.117 ミリ秒 perftestdb=>

MySQLで上限を制限した時間と似たような時間でパースが行われていますね。ただ、HASH JOINが選択されていますがw この辺りも、MySQLの生い立ちと、PostgreSQL、そしてOracleの違いとして現れてきます。MySQL 8のHash Joinって、MySQL 8.0.20 でHASH JOINが効くケースが拡大したという元々、Block Nested Loopの置き換えとしての意味が強かったという生い立ちが影響しているようにも見えます。なので、等価結合のINNER JOIN（今回の例）の場合、MySQL 8.0.32でもNLJが選択されているということのようですね。似てるようで似てないRDBMSの世界。まだまだ、私も学びが必要ですね。ちょっと曲のあるMySQLのHash Joinの発動条件。。いずれPostgreSQLやOracleっぽくHash Joinをカジュアルに使えちゃう日が来るのだろうか。。。

最後に真打w Oracle Database

今回は、23c Freeで試します。ただし、前回のエントリーにあるように、23c freeでは、"_optimizer_max_permutations" = 300と少なく設定されています。
今回の確認では、正式リリースされれば、通常の 2000 になるだろう。という想定で、 2000 にしてハードパース時間を確認しておきます。

SCOTT@freepdb1> select banner from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 23c Free, Release 23.0.0.0.0 - Developer-Release

デフォルトの設定はいかですが、.sqlスクリプト内で、 _optimizer_max_permutations を 2000 に設定して実行します！

parameter name parameter value -------------------------------- ------------------------------ _optimizer_max_permutations 300 _optimizer_search_limit 5 SCOTT@freepdb1> desc master 名前 NULL? 型 ----------------------------------------- -------- ---------------------------- ID NOT NULL NUMBER DUMMYA VARCHAR2(10) SCOTT@freepdb1> desc detail 名前 NULL? 型 ----------------------------------------- -------- ---------------------------- ID NOT NULL NUMBER SUBID NOT NULL NUMBER DUMMYA VARCHAR2(10) SCOTT@freepdb1> select table_name,index_name,column_name from user_ind_columns where table_name in ('MASTER','DETAIL') order by table_name,index_name,column_position; TABLE_NAME INDEX_NAME COLUMN_NAME ------------------------------ ------------------------------ ------------------------------ DETAIL PK_DETAIL ID DETAIL PK_DETAIL SUBID MASTER SYS_C008265 ID SCOTT@freepdb1> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'MASTER',cascade=>true,no_invalidate=>false); PL/SQLプロシージャが正常に完了しました。経過: 00:00:01.08 SCOTT@freepdb1> exec dbms_stats.gather_table_stats(ownname=>'SCOTT',tabname=>'DETAIL',cascade=>true,no_invalidate=>false); PL/SQLプロシージャが正常に完了しました。経過: 00:00:00.13

では、試してみましょう！

SCOTT@freepdb1> @test1_ora セッションが変更されました。経過: 00:00:00.01 NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ _optimizer_max_permutations integer 2000 1* alter system flush shared_pool システムが変更されました。経過: 00:00:00.68 解析されました。経過: 00:00:00.27

一般的なOracleの_optimizer_max_permutationsパラメータの設定で、 0.27 sec　となりました. こんなもんでしょうね。- this is an adaptive plan　となっているので、ACTUAL PLANを見ないと確定できないケースですが、多分
Hash joinが選ばれていることでしょうw(なので確認まではしませんが)

ついでなので、実行計画（見積もり）を見ておきましょう。　hash joinになってますね。一部、SORT MERGE JOINになってますが、

SCOTT@freepdb1> @?/rdbms/admin/utlxpls PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------------------------------- Plan hash value: 3620033460 ----------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 10240 | 950K| 33 (4)| 00:00:01 | |* 1 | HASH JOIN | | 10240 | 950K| 33 (4)| 00:00:01 | | 2 | TABLE ACCESS FULL | DETAIL | 20 | 180 | 3 (0)| 00:00:01 | |* 3 | HASH JOIN | | 5120 | 430K| 30 (4)| 00:00:01 | | 4 | TABLE ACCESS FULL | DETAIL | 20 | 180 | 3 (0)| 00:00:01 | |* 5 | HASH JOIN | | 2560 | 192K| 27 (4)| 00:00:01 | | 6 | TABLE ACCESS FULL | DETAIL | 20 | 180 | 3 (0)| 00:00:01 | |* 7 | HASH JOIN | | 1280 | 87040 | 24 (5)| 00:00:01 | | 8 | TABLE ACCESS FULL | DETAIL | 20 | 180 | 3 (0)| 00:00:01 | |* 9 | HASH JOIN | | 640 | 37760 | 21 (5)| 00:00:01 | | 10 | TABLE ACCESS FULL | DETAIL | 20 | 180 | 3 (0)| 00:00:01 | |* 11 | HASH JOIN | | 320 | 16000 | 18 (6)| 00:00:01 | | 12 | TABLE ACCESS FULL | DETAIL | 20 | 180 | 3 (0)| 00:00:01 | |* 13 | HASH JOIN | | 160 | 6560 | 15 (7)| 00:00:01 | |* 14 | HASH JOIN | | 80 | 2560 | 12 (9)| 00:00:01 | |* 15 | HASH JOIN | | 40 | 920 | 9 (12)| 00:00:01 | | 16 | MERGE JOIN | | 20 | 280 | 6 (17)| 00:00:01 | | 17 | TABLE ACCESS BY INDEX ROWID| MASTER | 10 | 50 | 2 (0)| 00:00:01 | | 18 | INDEX FULL SCAN | SYS_C008265 | 10 | | 1 (0)| 00:00:01 | |* 19 | SORT JOIN | | 20 | 180 | 4 (25)| 00:00:01 | | 20 | TABLE ACCESS FULL | DETAIL | 20 | 180 | 3 (0)| 00:00:01 | | 21 | TABLE ACCESS FULL | DETAIL | 20 | 180 | 3 (0)| 00:00:01 | | 22 | TABLE ACCESS FULL | DETAIL | 20 | 180 | 3 (0)| 00:00:01 | | 23 | TABLE ACCESS FULL | DETAIL | 20 | 180 | 3 (0)| 00:00:01 | ----------------------------------------------------------------------------------------------------- Note ----- - this is an adaptive plan 174行が選択されました。経過: 00:00:00.71

MySQL/PostgreSQL/Oracleそれぞれ、ハードパースの結合順評価テーブル数上限にも癖というか違いがあって、かつ、それが、パース時間の差になってみたり。癖が多いですよね。それぞれの特徴というか。
ついでに、実行計画、MySQLのHash Joinの発動ケース。現状OracleやPostgreSQLのようには使えないので、その辺りは、認識しておいた方が良いですよね。癖として；）

8月末に東北に居たのですが、例年だと朝晩は涼しくて、過ごしやすいのに、今年は、ダメですね。東京と同じです。農作物への影響が気になりますね。寒暖の差が美味しさに影響するのもありますからね。。。

では、また。

次回は、OracleのSQLヒントネタでもしようかと思ってます。Oracleのヒントレポートが出力されるようになって、そこ気になる、なぜ。みたいな方も多かったり、それにより無用な議論があったりと聞いているのでw 一応書いておこうかなと。

MySQL/PostgreSQL/Oracleで利用したスクリプト（テーブル、索引定義およびデータ取得と統計取得コマンドは本文参照のこと）

MySQL

[master@localhost ~]$ cat test1.sql use perftestdb; explain select * from master inner join detail on master.id = detail.id inner join detail t2 on t2.id = detail.id inner join detail t3 on t3.id = t2.id inner join detail t4 on t4.id = t3.id inner join detail t5 on t5.id = t4.id inner join detail t6 on t6.id = t5.id inner join detail t7 on t7.id = t6.id inner join detail t8 on t8.id = t7.id inner join detail t9 on t9.id = t8.id inner join detail t10 on t10.id = t9.id ;

PostgreSQL

[master@localhost ~]$ cat test1_pg.sql explain select * from master inner join detail on master.id = detail.id inner join detail t2 on t2.id = detail.id inner join detail t3 on t3.id = t2.id inner join detail t4 on t4.id = t3.id inner join detail t5 on t5.id = t4.id inner join detail t6 on t6.id = t5.id inner join detail t7 on t7.id = t6.id inner join detail t8 on t8.id = t7.id inner join detail t9 on t9.id = t8.id inner join detail t10 on t10.id = t9.id ;

Oracle

[master@localhost ~]$ cat test1_ora.sql alter session set "_optimizer_max_permutations"=2000; show parameter "_optimizer_max_permutations" alter system flush shared_pool . l / explain plan for select * from master inner join detail on master.id = detail.id inner join detail t2 on t2.id = detail.id inner join detail t3 on t3.id = t2.id inner join detail t4 on t4.id = t3.id inner join detail t5 on t5.id = t4.id inner join detail t6 on t6.id = t5.id inner join detail t7 on t7.id = t6.id inner join detail t8 on t8.id = t7.id inner join detail t9 on t9.id = t8.id inner join detail t10 on t10.id = t9.id ;

関連エントリー
・Oracle Database 23c Free Developer Releaseの”_optimizer_max_permutations” parameterの設定値について

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)
・標準はあるにはあるが癖の多いSQL 全部俺　おまけ SQL de 湯婆婆やるにも癖がでるw
・帰ってきた！標準はあるにはあるが癖の多いSQL #1 SQL de ROT13 やるにも癖が出るw・帰ってきた！標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出る

投稿日時 2023年9月 2日 (土) 12時59分 Oracle, チューニング, FAQ, SQL, MySQL, PostgreSQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2023年8月29日 (火)

帰ってきた！標準はあるにはあるが癖の多いSQL #2 Actual Plan取得中のキャンセルでも癖が出る

前々回のエントリーで、MySQL 8.0.32のActual Plan取得中にキャンセルしてもキャンセルされるまでのActual Planを取得できることを確認した。

では、OracleやPostgreSQLではどうなのだろう？（Oracleは皆さんご存知だと思いますが、確認の意味も含めて）

Oracle Database 21c と PostgreSQL 13.6 (私の環境の都合上w）で確認しておこうと思います。

Actual Plan欲しいけど、本番環境でしか試せないとか、実行に数時間以上要するような状況と大人の事情で、泣く泣くキャンセルしなければいけない。
でも、途中まででもいいからActual Plan返してくれたら、原因特定できる。。。かもしれないし。。。と思いますよね。

MySQL 8.0.32では、キャンセルしても途中まで取得できました。
（SQLパースフェーズの場合を除く。これはOracleでも、PostgreSQLでも同じでしょう。だって、実行前の解析フェーズでキャンセルされたらActual Planなんて返しようがないですからね）

では、Oracle Database 21cから見てみましょう！
(ご存知の方も多いと思いますので最初に答えを言っちゃうと、Oracleの場合、Actual Plan取得でも、SQLモニターの場合でもキャンセルしても途中までの結果を見ることができます！)

再帰問合せを利用した連番生成を行う方法で試してみます。

SYS@ORCLCDB> select banner_full from v$version; BANNER_FULL ------------------------------------------------------------------------------------------ Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production　Version 21.3.0.0.0

gather_plan_statisticsヒントを利用した、Actual Plan取得（キャンセルせず最後まで実行した例です）

SCOTT@freepdb1> @actual 1 WITH gen_nums(v) 2 AS 3 ( 4 SELECT /*+ gather_plan_statistics */ 1 5 FROM 6 dual 7 UNION ALL 8 SELECT v + 1 9 FROM 10 gen_nums 11 WHERE v + 1 <= 10000000 12 ) 13* SELECT v from gen_nums

SCOTT@freepdb1> @actual_plan 6n3sc0n82t9dq PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- SQL_ID 6n3sc0n82t9dq, child number 0 ------------------------------------- WITH gen_nums(v) AS ( SELECT /*+ gather_plan_statistics */ 1 FROM dual UNION ALL SELECT v + 1 FROM gen_nums WHERE v + 1 <= 10000000 ) SELECT v from gen_nums Plan hash value: 1492144221 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time | A-Rows | A-Time | Buffers | Writes | OMem | 1Mem | Used-Mem | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | | | 4 (100)| | 10M|00:07:57.97 | 105M| 28831 | | | | | 1 | VIEW | | 1 | 2 | 26 | 4 (0)| 00:00:01 | 10M|00:07:57.97 | 105M| 28831 | | | | | 2 | UNION ALL (RECURSIVE WITH) BREADTH FIRST| | 1 | | | | | 10M|00:07:53.30 | 105M| 28831 | 2048 | 2048 | 97M (0)| | 3 | FAST DUAL | | 1 | 1 | | 2 (0)| 00:00:01 | 1 |00:00:00.01 | 0 | 0 | | | | | 4 | RECURSIVE WITH PUMP | | 10M| | | | | 9999K|00:00:16.81 | 0 | 0 | | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

同SQLを途中でキャンセルした例です。
A-Rows/A-Timeが途中まで実行されたことを示しています。

SCOTT@freepdb1> @actual 1 WITH gen_nums(v) 2 AS 3 ( 4 SELECT /*+ gather_plan_statistics */ 1 5 FROM 6 dual 7 UNION ALL 8 SELECT v + 1 9 FROM 10 gen_nums 11 WHERE v + 1 <= 10000000 12 ) 13* SELECT v from gen_nums ^CSCOTT@freepdb1>

SCOTT@freepdb1> @actual_plan 6n3sc0n82t9dq PLAN_TABLE_OUTPUT --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- SQL_ID 6n3sc0n82t9dq, child number 0 ------------------------------------- WITH gen_nums(v) AS ( SELECT /*+ gather_plan_statistics */ 1 FROM dual UNION ALL SELECT v + 1 FROM gen_nums WHERE v + 1 <= 10000000 ) SELECT v from gen_nums Plan hash value: 1492144221 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows |E-Bytes| Cost (%CPU)| E-Time | A-Rows | A-Time | Buffers | Writes | OMem | 1Mem | Used-Mem | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | | | 4 (100)| | 7479K|00:06:29.48 | 76M| 21535 | | | | | 1 | VIEW | | 1 | 2 | 26 | 4 (0)| 00:00:01 | 7479K|00:06:29.48 | 76M| 21535 | | | | | 2 | UNION ALL (RECURSIVE WITH) BREADTH FIRST| | 1 | | | | | 7479K|00:06:25.85 | 76M| 21535 | 2048 | 2048 | 2048 (0)| | 3 | FAST DUAL | | 1 | 1 | | 2 (0)| 00:00:01 | 1 |00:00:00.01 | 0 | 0 | | | | | 4 | RECURSIVE WITH PUMP | | 7479K| | | | | 7479K|00:00:12.40 | 0 | 0 | | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

次に、SQL監視の例を見てみます。まず、キャンセルせず、最後まで実行した場合の例

Global Information ------------------------------ Status : DONE (ALL ROWS) Instance ID : 1 Session : SCOTT (379:17125) SQL ID : 8m5nwydj0rk2t ...中略... Global Stats ============================================================================ | Elapsed | Cpu | IO | Other | Fetch | Buffer | Write | Write | | Time(s) | Time(s) | Waits(s) | Waits(s) | Calls | Gets | Reqs | Bytes | ============================================================================ | 294 | 195 | 3.56 | 95 | 100K | 105M | 1126 | 225MB | ============================================================================ SQL Plan Monitoring Details (Plan Hash Value=1492144221) ============================================================================================================================================================================================ | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Write | Write | Mem | Temp | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | Reqs | Bytes | (Max) | (Max) | (%) | (# samples) | ============================================================================================================================================================================================ | 0 | SELECT STATEMENT | | | | 411 | +0 | 1 | 10M | | | . | . | | | | 1 | VIEW | | 2 | 4 | 411 | +0 | 1 | 10M | | | . | . | | | | 2 | UNION ALL (RECURSIVE WITH) BREADTH FIRST | | | | 411 | +0 | 1 | 10M | 1126 | 225MB | 98MB | 226MB | 95.44 | Cpu (248) | | | | | | | | | | | | | | | | direct path write temp (3) | | 3 | FAST DUAL | | 1 | 2 | 1 | +0 | 1 | 1 | | | . | . | | | | 4 | RECURSIVE WITH PUMP | | | | 411 | +0 | 10M | 10M | | | . | . | 1.90 | Cpu (5) | ============================================================================================================================================================================================

次に途中でキャンセルした場合の例。 410sec要していたので、10sec後ぐらいにキャンセルしました。どちらの方法でもキャンセルした場合でも途中までのActual Planを取得できました。MySQLは、Actual Plan取得時のキャンセルの挙動をOracle Database側にあわせたのでしょうかね？

SQLモニターの場合、Global informationのStatusにも着目してください。全行取得できたのか、途中で止められたのか、エラーで途中終了したのかなどの情報も確認できます。

1 WITH gen_nums(v) 2 AS 3 ( 4 SELECT /*+ MONITOR */　1 5 FROM 6 dual 7 UNION ALL 8 SELECT v + 1 9 FROM 10 gen_nums 11 WHERE v + 1 <= 10000000 12 ) 13* SELECT v from gen_nums ^CSCOTT@orclpdb1>

Global Information ------------------------------ Status : DONE (FIRST N ROWS) Instance ID : 1 Session : SCOTT (379:17125) SQL ID : 8m5nwydj0rk2t ...中略... Global Stats ================================================= | Elapsed | Cpu | Other | Fetch | Buffer | | Time(s) | Time(s) | Waits(s) | Calls | Gets | ================================================= | 10 | 5.49 | 4.45 | 7216 | 2M | ================================================= SQL Plan Monitoring Details (Plan Hash Value=1492144221) ========================================================================================================================================================= | Id | Operation | Name | Rows | Cost | Time | Start | Execs | Rows | Mem | Activity | Activity Detail | | | | | (Estim) | | Active(s) | Active | | (Actual) | (Max) | (%) | (# samples) | ========================================================================================================================================================= | 0 | SELECT STATEMENT | | | | 19 | +0 | 1 | 722K | . | | | | 1 | VIEW | | 2 | 4 | 19 | +0 | 1 | 722K | . | | | | 2 | UNION ALL (RECURSIVE WITH) BREADTH FIRST | | | | 19 | +0 | 1 | 722K | 34MB | 83.33 | Cpu (5) | | 3 | FAST DUAL | | 1 | 2 | 1 | +0 | 1 | 1 | . | | | | 4 | RECURSIVE WITH PUMP | | | | 19 | +0 | 722K | 722K | . | | | =========================================================================================================================================================

次にPostgreSQL

perftestdb=> select version(); version -------------------------------------------------------------------------------------------------------- PostgreSQL 13.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4), 64-bit (1 行)

キャンセルせず、最後まで実行した例

perftestdb=> explain (analyze, buffers, verbose) perftestdb-> WITH RECURSIVE gen_nums(v) perftestdb-> AS perftestdb-> ( perftestdb(> SELECT 1 perftestdb(> UNION ALL perftestdb(> SELECT v + 1 perftestdb(> FROM perftestdb(> gen_nums perftestdb(> WHERE v + 1 <= 100000000 perftestdb(> ) perftestdb-> SELECT v from gen_nums; QUERY PLAN ----------------------------------------------------------------------------------------------------------------------------------------- CTE Scan on gen_nums (cost=3.21..3.83 rows=31 width=4) (actual time=0.007..98357.448 rows=100000000 loops=1) Output: gen_nums.v Buffers: temp written=170898 CTE gen_nums -> Recursive Union (cost=0.00..3.21 rows=31 width=4) (actual time=0.005..67023.784 rows=100000000 loops=1) -> Result (cost=0.00..0.01 rows=1 width=4) (actual time=0.002..0.002 rows=1 loops=1) Output: 1 -> WorkTable Scan on gen_nums gen_nums_1 (cost=0.00..0.26 rows=3 width=4) (actual time=0.000..0.000 rows=1 loops=100000000) Output: (gen_nums_1.v + 1) Filter: ((gen_nums_1.v + 1) <= 100000000) Rows Removed by Filter: 0 Planning Time: 0.090 ms Execution Time: 103968.625 ms (13 行)

キャンセルした例。
Planning Time: 0.090 ms なので、パースフェーズ中にキャンセルする方が難しいですね。103秒ほど要するので、60秒ぐらいでキャンセルしましたが、PostgreSQLの場合は、Actual Plan取得中のキャンセルでは何も出力されません。
XにPostしたところ、篠田さんから、本体側で対応しないと返せなようだ、とコメントをもらいコードを見始めたり() 機能として、あったら便利かもしれないですね。PostgreSQLでも。キャンセルしたところまでのActual Planを返してくれたら問題解決の糸口になることもあるだろうし。

perftestdb=> explain (analyze, buffers, verbose) WITH RECURSIVE gen_nums(v) AS ( SELECT 1 UNION ALL SELECT v + 1 FROM gen_nums WHERE v + 1 <= 100000000 ) SELECT v from gen_nums; ^Cキャンセル要求を送信しました ERROR: canceling statement due to user request perftestdb=>

温泉三昧と、いつも満席で諦めてた蕎麦屋のいくつかは食べ歩けた遅いお盆休みも終わり。もう9月が目の前ですね。

では、また。

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)
・標準はあるにはあるが癖の多いSQL 全部俺　おまけ SQL de 湯婆婆やるにも癖がでるw
・帰ってきた！標準はあるにはあるが癖の多いSQL #1 SQL de ROT13 やるにも癖が出るw

投稿日時 2023年8月29日 (火) 06時00分 Oracle, チューニング, FAQ, SQL, MySQL, PostgreSQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2023年8月 7日 (月)

帰ってきた！標準はあるにはあるが癖の多いSQL #1 SQL de ROT13 やるにも癖が出るw

先日、Facebookの思い出なんぞを見返していたら、子供が小さい頃、ROT13で、謎の文字列を解かせる、コナンくん遊びをしてたことを思い出した。

ROT13

流石に小さい頃なので、難易度を下げるためROT13の文字対応表をヒントとして与えることにしようと思ったのですが、それだと逆に簡単になり過ぎると考え、文字列の順番を示す数字を、犯人からのメッセージとして、

謎の数字から犯人のメッセージを解け！。

みたいなことをやっていました。

意外と受けが良くて、複数の問題を解いて遊んで、問題を作る方が疲れるというわけわからん事態になってしまったことがありましたw

ということで、

本日の、帰ってきた！標準はあるにはあるが癖の多いSQL　は、 ROT13やるにも、Oracle/PostgreSQL/MySQLの癖が出ますよ！。というお話。

(実装は、SQL script file化してパラメータ渡し、渡せない癖のあるものは、代替方法にて渡すことにします。また、SQLだけで解決することにします）

前置きはこれぐらいにして、早速、間違いない、Oracleからw

ROT13 cipher実装するのにベタな感じで、PL/SQLになどに逃げる必要はないです。非常に強力な関数、 translate() 一発で解決できますよ。

SCOTT@freepdb1> select banner from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 23c Free, Release 23.0.0.0.0 - Developer-Release 経過: 00:00:00.02

文字列をrot13/derot13するSQL scriptファイルです。
Oracleの場合、単純です。translate()で対応する文字を返すようにするだけです。

SCOTT@freepdb1> !cat rot13.sql SELECT TRANSLATE ( '&1' ,'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz' ,'NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm' ) ; UNDEFINE 1

SCOTT@freepdb1> !cat derot13.sql SELECT TRANSLATE ( '&1' ,'NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm' ,'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz') ; UNDEFINE 1

では、実行！　うまく行った！
簡単でしょ！この手のSQL文でのお遊びは。

SCOTT@freepdb1> @rot13 'Mac De Oracle' TRANSLATE('MA ------------- Znp Qr Benpyr 経過: 00:00:00.00

SCOTT@freepdb1> @derot13 'Znp Qr Benpyr' TRANSLATE('ZN ------------- Mac De Oracle 経過: 00:00:00.01

つづいで、PostgreSQLです。

perftestdb=> select version(); version -------------------------------------------------------------------------------------------------------- PostgreSQL 13.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-4), 64-bit (1 行)

実行！　

[postgres@localhost ~]$ psql -d perftestdb -U discus -p 5432 -W -h localhost -f /var/lib/pgsql/pg_rot13.sql -v str="'Mac De Oracle'" translate --------------- Znp Qr Benpyr (1 行)

[postgres@localhost ~]$ psql -d perftestdb -U discus -p 5432 -W -h localhost -f /var/lib/pgsql/pg_derot13.sql -v str="'Znp Qr Benpyr'" translate --------------- Mac De Oracle (1 行)

PostgreSQLの場合、translate()関数が実装されており、Oracleと同じように利用できました。SQL scriptファイル実行時のパラメータの渡し方に癖がある感じですかね。（なかなか、慣れないです。これ）

[postgres@localhost ~]$ cat pg_rot13.sql SELECT TRANSLATE ( :str ,'NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm' ,'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz') ;

[postgres@localhost ~]$ cat pg_derot13.sql SELECT TRANSLATE ( ':str' ,'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz' ,'NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm') ;

さて、最後は、MySQL 8.0.xを利用します。理由は使える構文が多くなったためですが。おそらくそれ以前のMySQLだと実装はかなり辛い。

mysql> select version(); +-----------+ | version() | +-----------+ | 8.0.32 | +-----------+ 1 row in set (0.00 sec)

理由は、見ての通り、再帰問合せを利用する必要があるためです。これ使えないとかなりキツイ。w
ついでに、translate()関数も存在しないため、バリバリ既存の関数を使ってシンプルに書いても多分これぐらいw

他に、もっといいやり方あるよーって方、ブログ書いて公開してほしいっす！
ちなみに、ググったら、こんなのをGitHubで見つけました。同じ方法じゃなくてよかったという感じではあります :)　俺オリジナルだ:)

こちらの方は、function化したようですね
https://github.com/samuelfaj/MySQL-rot13/blob/master/MySQL_rot13.sql

では、私が作ったSQL scriptファイルでパラメータをSETコマンドで渡す方法。苦心の跡が見えるかと思います。（これは無理だ、function化して逃げるかー。と一瞬過りましたが、閃いた方法がよかったという感じ）

mysql> \! cat mysql_rot13.sql WITH RECURSIVE rot13(v) AS ( SELECT 1 UNION ALL SELECT v + 1 FROM rot13 WHERE v + 1 <= CHAR_LENGTH(@str) ) SELECT GROUP_CONCAT( CASE WHEN INSTR( CAST('ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz' AS BINARY) , SUBSTR(@str, v, 1) ) = 0 THEN SUBSTR(@str, v, 1) ELSE SUBSTR( 'NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm' , INSTR( CAST('ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyza' AS BINARY) , SUBSTR(@str, v, 1) ) , 1 ) END SEPARATOR '' ) AS rot13 FROM rot13 ;

mysql> \! cat mysql_derot13.sql WITH RECURSIVE derot13(v) AS ( SELECT 1 UNION ALL SELECT v + 1 FROM derot13 WHERE v + 1 <= CHAR_LENGTH(@str) ) SELECT GROUP_CONCAT( CASE WHEN INSTR( CAST('NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm' AS BINARY) , SUBSTR(@str, v, 1) ) = 0 THEN SUBSTR(@str, v, 1) ELSE SUBSTR( 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz' , INSTR( CAST('NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm' AS BINARY) , SUBSTR(@str, v, 1) ) , 1 ) END SEPARATOR '' ) AS derot13 FROM derot13 ;

では実行。

mysql> set @str='Mac De Oracle'; Query OK, 0 rows affected (0.01 sec) mysql> \. mysql_rot13.sql +---------------+ | rot13 | +---------------+ | Znp Qr Benpyr | +---------------+ 1 row in set (0.00 sec)

mysql> set @str='Znp Qr Benpyr'; Query OK, 0 rows affected (0.00 sec) mysql> \. mysql_derot13.sql +---------------+ | derot13 | +---------------+ | Mac De Oracle | +---------------+ 1 row in set (0.00 sec)

ということで、いろいろな、癖という鞭に打たれても、ニッコリ笑える。変態になれると良いですね :)

まだまだまだ、クソ暑い、東京からお送りしました。　ではまた。

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)
・標準はあるにはあるが癖の多いSQL 全部俺　おまけ SQL de 湯婆婆やるにも癖がでるw

投稿日時 2023年8月 7日 (月) 21時23分 Oracle, SQL, MySQL, PostgreSQL | 固定リンク | 0 | コメント (0)

2023年8月 4日 (金)

MySQL 8.0.32 / explain analyze 実行途中でキャンセルできるみたいだけど、キャンセルしたら、Actual Plan、途中まで出るの？

本年度一発目のw　Databaseネタは、なんと、MySQLネタからのスタートですw

MySQL 8.0.18以降、Actualプランが取得できるようになってた。
また、MySQL 8.0.20 以降、KILL QUERY または CTRL-C を使用してこのステートメントを終了できるとある。
ただ、マニュアルに記載されているのはここまでで、キャンセルできることは記載されているが、キャンセルした場合のActual Planはどこまで出力されるのだろう？　or 全く出力されない？

OracleのリアルタイムSQL監視だとキャンセルすると不完全ではあるけども、なんとなーく判断できる程度の情報は途中まで取得できるが、
GATHER_PLAN_STATISTICSヒントなどを使ったActualプランは最後まで実行しないとアcつあlはしゅとくできない。どちらのタイプに似ているのでしょうね？

長時間（数日とかw）かかってしまうようになったSQLのActualプラン取得するの意外と難しいケースも場合によってはあったりするわけで。。。そんなとき、Actualみたいけど、キャンセルしたらどうなるのだろうと。。
途中まででも取得できるのか、それとも、Nothingなのか。。。

MySQLのActualプランの取得はどうなんだろう。。。ということで、試してみた。

EXPLAIN ANALYZE による情報の取得
https://dev.mysql.com/doc/refman/8.0/ja/explain.html#explain-analyze

結論から書くと、
MySQL 8.0.32での検証だが、

explain analyzeで取得できるActual Planは、対応しているSQL文の実行中にCTRL-Cでキャンセルしても、その時点までの、Actual Planを表示してくれる!!!!!!

ただし、パース時間が異常に長めのSQL文(結合数めちゃ多いとか）だと、実行以前に、パース時間が長いため、パースフェーズでキャンセルしてしまうの何も表示されない。。と（最初はこちらを引いてしまったので、常に表示されないものかと思い込んでしまった）
他の方法で実行をキャンセルした場合も同じだろう。とは思う。

いや、他にも出力されないケースがあるとか、その検証方法だから出力されているだけどか、MySQLのexplain analyzeのディープなツッコミがありましたら、よろしくお願いします。:)

MySQLの8.0台ってマイナー番号変わっても機能追加されたり変化しているので、一応。 MySQL 8.0.32 上では。ということにしておく。

以下、検証の記録的なもの。

確認に使用した　MySQLのバージョン

[master@localhost ~]$ mysql -u scott -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 8 Server version: 8.0.32 Source distribution Copyright (c) 2000, 2023, Oracle and/or its affiliates. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> select version(); +-----------+ | version() | +-----------+ | 8.0.32 | +-----------+ 1 row in set (0.00 sec)

事前に準備したクエリ向け表と索引など

Database changed mysql> use perftestdb Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> mysql> desc master; +--------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------+-------------+------+-----+---------+-------+ | id | int | NO | PRI | NULL | | | dummya | varchar(10) | YES | | NULL | | +--------+-------------+------+-----+---------+-------+ 2 rows in set (0.01 sec) mysql> desc detail; +--------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------+-------------+------+-----+---------+-------+ | id | int | NO | PRI | NULL | | | subid | int | NO | PRI | NULL | | | dummya | varchar(10) | YES | | NULL | | +--------+-------------+------+-----+---------+-------+ 3 rows in set (0.00 sec) mysql> show indexes from master; +--------+------------+----------+--------------+-------------+------------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Index_type | +--------+------------+----------+--------------+-------------+------------+ | master | 0 | PRIMARY | 1 | id | BTREE | +--------+------------+----------+--------------+-------------+------------+ 1 row in set (0.02 sec) mysql> show indexes from detail; +--------+------------+----------+--------------+-------------+------------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Index_type | +--------+------------+----------+--------------+-------------+------------+ | detail | 0 | PRIMARY | 1 | id | BTREE | | detail | 0 | PRIMARY | 2 | subid | BTREE | +--------+------------+----------+--------------+-------------+------------+ 2 rows in set (0.02 sec) mysql> select * from master; +----+--------+ | id | dummya | +----+--------+ | 1 | 1 | | 2 | 2 | | 3 | 3 | | 4 | 4 | | 5 | 5 | | 6 | 6 | | 7 | 7 | | 8 | 8 | | 9 | 9 | | 10 | 10 | +----+--------+ 10 rows in set (0.01 sec) mysql> select * from detail; +----+-------+--------+ | id | subid | dummya | +----+-------+--------+ | 1 | 1 | 11 | | 1 | 2 | 12 | | 2 | 1 | 21 | | 2 | 2 | 22 | | 3 | 1 | 31 | ...略... | 7 | 1 | 71 | | 7 | 2 | 72 | | 8 | 1 | 81 | | 8 | 2 | 82 | | 9 | 1 | 91 | | 9 | 2 | 92 | | 10 | 1 | 101 | | 10 | 2 | 102 | +----+-------+--------+ 20 rows in set (0.01 sec)

検証用に作ったSQL。どのぐらいのElapsed Timeかanaluyzeをつけて実行して、キャンセルしやすい程度のElapsed Timeか確認しておきます。

mysql> explain analyze -> select * -> from -> master inner join detail -> on master.id = detail.id -> inner join detail t2 -> on -> t2.id = detail.id -> inner join detail t3 -> on -> t3.id = t2.id -> inner join detail t4 -> on -> t4.id = t3.id -> inner join detail t5 -> on -> t5.id = t4.id -> inner join detail t6 -> on -> t6.id = t5.id -> inner join detail t7 -> on -> t7.id = t6.id -> inner join detail t8 -> on -> t8.id = t7.id -> inner join detail t9 -> on -> t9.id = t8.id -> inner join detail t10 -> on -> t10.id = t9.id -> ; +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=5729.85 rows=8192) (actual time=0.115..37.938 rows=10240 loops=1) -> Nested loop inner join (cost=2862.65 rows=4096) (actual time=0.108..18.747 rows=5120 loops=1) -> Nested loop inner join (cost=1429.05 rows=2048) (actual time=0.102..9.267 rows=2560 loops=1) -> Nested loop inner join (cost=712.25 rows=1024) (actual time=0.097..4.689 rows=1280 loops=1) -> Nested loop inner join (cost=353.85 rows=512) (actual time=0.091..2.336 rows=640 loops=1) -> Nested loop inner join (cost=174.65 rows=256) (actual time=0.086..1.203 rows=320 loops=1) -> Nested loop inner join (cost=85.05 rows=128) (actual time=0.080..0.630 rows=160 loops=1) -> Nested loop inner join (cost=40.25 rows=64) (actual time=0.075..0.337 rows=80 loops=1) -> Nested loop inner join (cost=17.85 rows=32) (actual time=0.069..0.189 rows=40 loops=1) -> Nested loop inner join (cost=6.65 rows=16) (actual time=0.063..0.110 rows=20 loops=1) -> Table scan on master (cost=1.05 rows=8) (actual time=0.041..0.047 rows=10 loops=1) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.53 rows=2) (actual time=0.005..0.006 rows=2 loops=10) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) (actual time=0.003..0.004 rows=2 loops=20) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) (actual time=0.002..0.003 rows=2 loops=40) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.002..0.003 rows=2 loops=80) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.002..0.003 rows=2 loops=160) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.002..0.003 rows=2 loops=320) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.002..0.003 rows=2 loops=640) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.002..0.003 rows=2 loops=1280) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.002..0.003 rows=2 loops=2560) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.002..0.003 rows=2 loops=5120) | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (21.18 sec)

では、explain analyseを途中でキャンセルしてみます。elapsed timeが21秒ほどなので、20秒後にキャンセルしてみます。

mysql> explain analyze select * from master inner join detail on master.id = detail.id inner join detail t2 on t2.id = master.id inner join detail t3 on t3.id = master.id inner join detail t4 on t4.id = master.id inner join detail t5 on t5.id = master.id inner join detail t6 on t6.id = master.id inner join detail t7 on t7.id = master.id inner join detail t8 on t8.id = master.id inner join detail t9 on t9.id = master.id inner join detail t10 on t10.id = master.id ; ^C^C -- query aborted ERROR 1317 (70100): Query execution was interrupted mysql>

！　やはり、実行途中のキャンセルだとActual Planは何も出力されないみたい。。。。

？？ん？　いや、なんか違うな。これw！

SQL文の実行時間はたいしたことない。人間がこの時間内にピンポイントでキャンセルするには短すぎるよね。
SQL文の実行時間は、約38ミリ秒！！！　こっちだw 最終に表示されている21秒には、SQLのパース時間も含まれているはず。。。。見逃した。俺としたことが。。。

| -> Nested loop inner join (cost=5729.85 rows=8192) (actual time=0.115..37.938 rows=10240 loops=1)

キャンセルしたのは、SQL実行後、おおよそ、20秒後。SQLのActualタイムを見ると38ミリ秒なので、ギリギリ、パース時間中に被ってそう。

1 row in set (21.00 sec)

だとしたら、まず、そこから確認。パースにどの程度要しているか、explainだけにすれば、良さそうだよね。Oracle Databaseでもそうだし。(PostgreSQLはパース時間も表示してくれたりするけども。あれ意外に便利なんだよ）

mysql> explain format=tree -> select * -> from -> master inner join detail -> on master.id = detail.id -> inner join detail t2 -> on -> t2.id = detail.id -> inner join detail t3 -> on -> t3.id = t2.id -> inner join detail t4 -> on -> t4.id = t3.id -> inner join detail t5 -> on -> t5.id = t4.id -> inner join detail t6 -> on -> t6.id = t5.id -> inner join detail t7 -> on -> t7.id = t6.id -> inner join detail t8 -> on -> t8.id = t7.id -> inner join detail t9 -> on -> t9.id = t8.id -> inner join detail t10 -> on -> t10.id = t9.id -> ; +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=5729.85 rows=8192) -> Nested loop inner join (cost=2862.65 rows=4096) -> Nested loop inner join (cost=1429.05 rows=2048) -> Nested loop inner join (cost=712.25 rows=1024) -> Nested loop inner join (cost=353.85 rows=512) -> Nested loop inner join (cost=174.65 rows=256) -> Nested loop inner join (cost=85.05 rows=128) -> Nested loop inner join (cost=40.25 rows=64) -> Nested loop inner join (cost=17.85 rows=32) -> Nested loop inner join (cost=6.65 rows=16) -> Table scan on master (cost=1.05 rows=8) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.53 rows=2) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (21.84 sec)

お！　予想通り、explainでパースだけさせたら、explain analyze（SQL文の実行を含む）とほぼ同じ 21秒台。想定は正しそう。

だとすると、今回確認したいことを実現するには、..... SQLの実行時間をもっと長くして、人がw キャンセルしやすい程度に実行時間を間延びさせておく必要がある。。
とはいえ、大量のデータを用意する時間もVMのストレージもないと。。。

さて、どうするか。。。。

***** ここで、　一休さん、考え中。。。木魚の音。ポク、ポク、ポク。。。。w *****

***** ここで、　一休さん、閃いた。。。鐘の音、チーーーーーん *****
　
sleep()関数を使って、眠らせると時間稼ぎできるのでは？　　やってみよう！
おおおおお、いい感じだ。

mysql> explain analyze -> select *, sleep(0.01) -> from -> master inner join detail -> on master.id = detail.id -> inner join detail t2 -> on -> t2.id = detail.id -> inner join detail t3 -> on -> t3.id = t2.id -> inner join detail t4 -> on -> t4.id = t3.id -> inner join detail t5 -> on -> t5.id = t4.id -> inner join detail t6 -> on -> t6.id = t5.id -> inner join detail t7 -> on -> t7.id = t6.id -> inner join detail t8 -> on -> t8.id = t7.id -> inner join detail t9 -> on -> t9.id = t8.id -> inner join detail t10 -> on -> t10.id = t9.id -> ; +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=5729.85 rows=8192) (actual time=0.170..232.399 rows=10240 loops=1) -> Nested loop inner join (cost=2862.65 rows=4096) (actual time=0.164..75.457 rows=5120 loops=1) -> Nested loop inner join (cost=1429.05 rows=2048) (actual time=0.159..37.659 rows=2560 loops=1) -> Nested loop inner join (cost=712.25 rows=1024) (actual time=0.154..17.709 rows=1280 loops=1) -> Nested loop inner join (cost=353.85 rows=512) (actual time=0.149..9.612 rows=640 loops=1) -> Nested loop inner join (cost=174.65 rows=256) (actual time=0.143..4.658 rows=320 loops=1) -> Nested loop inner join (cost=85.05 rows=128) (actual time=0.138..2.285 rows=160 loops=1) -> Nested loop inner join (cost=40.25 rows=64) (actual time=0.132..1.174 rows=80 loops=1) -> Nested loop inner join (cost=17.85 rows=32) (actual time=0.126..0.625 rows=40 loops=1) -> Nested loop inner join (cost=6.65 rows=16) (actual time=0.120..0.347 rows=20 loops=1) -> Table scan on master (cost=1.05 rows=8) (actual time=0.097..0.122 rows=10 loops=1) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.53 rows=2) (actual time=0.017..0.021 rows=2 loops=10) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) (actual time=0.010..0.013 rows=2 loops=20) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) (actual time=0.010..0.013 rows=2 loops=40) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.010..0.013 rows=2 loops=80) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.010..0.014 rows=2 loops=160) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.011..0.015 rows=2 loops=320) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.009..0.012 rows=2 loops=640) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.011..0.015 rows=2 loops=1280) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.010..0.014 rows=2 loops=2560) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.010..0.028 rows=2 loops=5120) | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (2 min 47.64 sec)

Elapsed Timeがパース時間より長くなったので、できそう。　60秒後にキャンセルすれば余裕はありそう。

1 row in set (2 min 47.64 sec)

explain analyzeを実行して、60秒後にキャンセルした！

mysql> explain analyze -> select *, sleep(0.01) -> from -> master inner join detail -> on master.id = detail.id -> inner join detail t2 -> on -> t2.id = detail.id -> inner join detail t3 -> on -> t3.id = t2.id -> inner join detail t4 -> on -> t4.id = t3.id -> inner join detail t5 -> on -> t5.id = t4.id -> inner join detail t6 -> on -> t6.id = t5.id -> inner join detail t7 -> on -> t7.id = t6.id -> inner join detail t8 -> on -> t8.id = t7.id -> inner join detail t9 -> on -> t9.id = t8.id -> inner join detail t10 -> on -> t10.id = t9.id -> ; ^C^C -- query aborted +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | -> Nested loop inner join (cost=5729.85 rows=8192) (actual time=0.113..92.382 rows=2639 loops=1) -> Nested loop inner join (cost=2862.65 rows=4096) (actual time=0.106..29.480 rows=1320 loops=1) -> Nested loop inner join (cost=1429.05 rows=2048) (actual time=0.101..14.323 rows=660 loops=1) -> Nested loop inner join (cost=712.25 rows=1024) (actual time=0.096..7.161 rows=330 loops=1) -> Nested loop inner join (cost=353.85 rows=512) (actual time=0.090..3.507 rows=165 loops=1) -> Nested loop inner join (cost=174.65 rows=256) (actual time=0.085..1.624 rows=83 loops=1) -> Nested loop inner join (cost=85.05 rows=128) (actual time=0.079..0.867 rows=42 loops=1) -> Nested loop inner join (cost=40.25 rows=64) (actual time=0.073..0.352 rows=21 loops=1) -> Nested loop inner join (cost=17.85 rows=32) (actual time=0.068..0.210 rows=11 loops=1) -> Nested loop inner join (cost=6.65 rows=16) (actual time=0.062..0.122 rows=6 loops=1) -> Table scan on master (cost=1.05 rows=8) (actual time=0.040..0.044 rows=3 loops=1) -> Index lookup on detail using PRIMARY (id=`master`.id) (cost=0.53 rows=2) (actual time=0.021..0.024 rows=2 loops=3) -> Index lookup on t2 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) (actual time=0.011..0.014 rows=2 loops=6) -> Index lookup on t3 using PRIMARY (id=`master`.id) (cost=0.51 rows=2) (actual time=0.009..0.012 rows=2 loops=11) -> Index lookup on t4 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.020..0.024 rows=2 loops=21) -> Index lookup on t5 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.014..0.017 rows=2 loops=42) -> Index lookup on t6 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.015..0.022 rows=2 loops=83) -> Index lookup on t7 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.014..0.021 rows=2 loops=165) -> Index lookup on t8 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.016..0.021 rows=2 loops=330) -> Index lookup on t9 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.015..0.022 rows=2 loops=660) -> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.015..0.044 rows=2 loops=1320) | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set, 1 warning (1 min 3.57 sec)

SQLのActualタイムは、92ミリ秒、処理した行数が、2629行。

| -> Nested loop inner join (cost=5729.85 rows=8192) (actual time=0.113..92.382 rows=2639 loops=1)

以下を見ると、loopsが、1320回となっている。

-> Index lookup on t10 using PRIMARY (id=`master`.id) (cost=0.50 rows=2) (actual time=0.015..0.044 rows=2 loops=1320)

やった〜〜〜。　MySQLの explain analyzeは、"SQLの実行途中"(パース時間が長い割に、実行時間が短い場合は、実行中にキャンセルするのが難しいので表示されないケースはあるので注意）でキャンセルしても、途中までのActual Planを返してくれる！

念の為、sleep()関数を使ったトリッキーな再現方法ではなく、実際にSQLの実行中にキャンセルする方法を思いついたので、さらに、試してみる！

お分かりだろうか。みなさん大好き（？）、　~~再起問い合わせ~~再帰問合せでシーケンス番号を生成するクエリーだ。100000000ぐらい生成すれば、いい感じの実行時間になるだろうと、思われるので、まず、このSQLのパース時間だけ確認。

mysql> SET SESSION cte_max_recursion_depth = 100000000; Query OK, 0 rows affected (0.00 sec)

パース時間はほぼかかってないですね。先ほどの例は、結合する表が多いので、パース時間は長くなる傾向があるので、シンプルなSQLだけど、実行時間は、なげ〜〜〜〜ぞ〜というのにしてみた。

mysql> explain format=tree -> WITH RECURSIVE gen_nums(v) -> AS -> ( -> SELECT 1 -> UNION ALL -> SELECT v + 1 -> FROM -> gen_nums -> WHERE v + 1 <= 100000000 -> ) -> SELECT v from gen_nums; +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | -> Table scan on gen_nums (cost=3.87..5.56 rows=3) -> Materialize recursive CTE gen_nums (cost=3.03..3.03 rows=3) -> Rows fetched before execution (cost=0.00..0.00 rows=1) -> Repeat until convergence -> Filter: ((gen_nums.v + 1) <= 100000000) (cost=2.73 rows=2) -> Scan new records on gen_nums (cost=2.73 rows=2) | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec)

explain analyzeの実時間を確認

mysql> explain analyze -> WITH RECURSIVE gen_nums(v) -> AS -> ( -> SELECT 1 -> UNION ALL -> SELECT v + 1 -> FROM -> gen_nums -> WHERE v + 1 <= 100000000 -> ) -> SELECT v from gen_nums; +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | -> Table scan on gen_nums (cost=3.87..5.56 rows=3) (actual time=139082.095..178091.268 rows=100000000 loops=1) -> Materialize recursive CTE gen_nums (cost=3.03..3.03 rows=3) (actual time=139081.959..139081.959 rows=100000000 loops=1) -> Rows fetched before execution (cost=0.00..0.00 rows=1) (actual time=0.000..0.000 rows=1 loops=1) -> Repeat until convergence -> Filter: ((gen_nums.v + 1) <= 100000000) (cost=2.73 rows=2) (actual time=0.003..29453.367 rows=50000000 loops=2) -> Scan new records on gen_nums (cost=2.73 rows=2) (actual time=0.002..21852.139 rows=50000000 loops=2) | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (3 min 8.46 sec)

Actual timeは、178秒なので、60秒後にキャンセルすればよさそうですね。

| -> Table scan on gen_nums (cost=3.87..5.56 rows=3) (actual time=139082.095..178091.268 rows=100000000 loops=1)

では、キャンセルでどうなるか検証！！

mysql> explain analyze -> WITH RECURSIVE gen_nums(v) -> AS -> ( -> SELECT 1 -> UNION ALL -> SELECT v + 1 -> FROM -> gen_nums -> WHERE v + 1 <= 100000000 -> ) -> SELECT v from gen_nums; ^C^C -- query aborted +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | EXPLAIN | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | -> Table scan on gen_nums (cost=3.87..5.56 rows=3) (never executed) -> Materialize recursive CTE gen_nums (cost=3.03..3.03 rows=3) (never executed) -> Rows fetched before execution (cost=0.00..0.00 rows=1) (actual time=0.000..0.000 rows=1 loops=1) -> Repeat until convergence -> Filter: ((gen_nums.v + 1) <= 100000000) (cost=2.73 rows=2) (actual time=0.004..27789.355 rows=47924088 loops=1) -> Scan new records on gen_nums (cost=2.73 rows=2) (actual time=0.002..20555.788 rows=47924088 loops=1) | +------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set, 1 warning (1 min 3.94 sec)

60行でキャンセルしたので、ほぼ同じ。

1 row in set, 1 warning (1 min 3.94 sec

以下の行ソースを見ると、Actual timeが21秒ほど、rowsも47924088行。

-> Scan new records on gen_nums (cost=2.73 rows=2) (actual time=0.002..20555.788 rows=47924088 loops=1)

興味深い部分は、以下の2行の行ソース。never execute　と表示されている。

| -> Table scan on gen_nums (cost=3.87..5.56 rows=3) (never executed) -> Materialize recursive CTE gen_nums (cost=3.03..3.03 rows=3) (never executed) ¥

これを見る限り、MySQLのexplain analyzeは、SQL文の実行フェース中にキャンセルすると、その時点までの Actual Planを出力してくれる。これ、結構嬉しいよね。長時間実行で、仕方なくキャンセルするにしても途中の状態。運が良ければ、詰まっている部分が見えるかもしれないわけで。。。

いや、他にも出力されないケースがあるとか、その検証方法だから出力されているだけどか、MySQLのexplain analyzeのディープなツッコミがありましたら、よろしくお願いします。:) (大事なので、2度書いておくw）

以上、explain analyze のブラックボックステスト。　実行途中でキャンセルできるみたいだけど、キャンセルしたら、Actual Plan、途中まで出るの？　の巻。終わり。

似てるようで、似てない。それぞれのRDBMSの世界w。　ではまた。

　

参考）
EXPLAIN ANALYZE による情報の取得
https://dev.mysql.com/doc/refman/8.0/ja/explain.html#explain-analyze

投稿日時 2023年8月 4日 (金) 06時00分 Oracle, Linux, チューニング, FAQ, SQL, MySQL, パフォーマンス | 固定リンク | 0 | コメント (0)

2020年12月26日 (土)

標準はあるにはあるが癖の多いSQL 全部俺　おまけ SQL de 湯婆婆やるにも癖がでるw

恒例の標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020のおまけですw

忙しすぎて、この手の遊びが疎かになっておりました。完全に乗り遅れておりましたが、湯婆婆やりましたw

スタジオジブリさん、「画像は常識の範囲でご自由にお使いください。」とのことでありがたく使わせていただきます！
https://www.ghibli.jp/works/chihiro/#frame

では、Oracle (19c)を使って、Oracle 湯婆婆　から
Advent Calendar 標準はあるにはあるが癖の多いSQL 全部俺でも登場したSUBSTR/DBMS_RANDOM.VALUEや文字列連結の違い。
それに、SQLスクリプトでインタラクティブにパラメータを渡せるかという点にも違いがあります。

SQL*Plus/psqlではインタラクティブにパラメータを渡せますが、mysqlにはなさそう（あったらコメントください）

インタラクティブにパラメータを渡せるSQL*Plus/psqlでは、それぞれ、ACCEPTや\promptなどで名前を入力しています。
mysqlでは仕方ないのでSETコマンドで設定する方法をとりました。

ORACLE> @ora_yubaba 契約書だよ。そこに名前を書きな。山田千尋湯婆婆 -------------------------------------------------------------------------------- フン山田千尋というのかい。贅沢な名だねぇ今からお前の名前は田だ。いいかい、田だよ。わかったら返事をするんだ、 !!

$ cat ora_yubaba.sql SET LINESIZE 80 SET TAB OFF SET VERIFY OFF ACCEPT fullname CHAR PROMPT '契約書だよ。そこに名前を書きな。' WITH yourname AS ( SELECT SUBSTR( '&&fullname' , DBMS_RANDOM.VALUE(1,LENGTH('&&fullname')), 1 ) AS newname FROM dual ) SELECT 'フン ' ||'&&fullname' ||' というのかい。贅沢な名だねぇ' ||CHR(13)||CHR(10) ||'今からお前の名前は ' ||newname ||' だ。いいかい、' ||newname ||' だよ。' ||CHR(13)||CHR(10)||'わかったら返事をするんだ、' ||CHR(13)||CHR(10)||'!!' AS "湯婆婆" FROM yourname; undefine fullname SET VERIFY ON

PostgreSQL (12)

次は、PostgreSQL 湯婆婆

postgres=> \i postgresql_yubaba.sql 契約書だよ。そこに名前を書きな : 山田千尋湯婆婆 ---------------------------------------------- フン　山田千尋というのかい。贅沢な名だねぇ + 今からお前の名は田　だ。いいかい、田だよ。+ わかったら返事をするんだ、 + !! (1 row)

$ cat postgresql_yubaba.sql \prompt '契約書だよ。そこに名前を書きな : ' fullname WITH yourname AS ( SELECT SUBSTR( :'fullname'::TEXT , CEIL(RANDOM() * LENGTH(:'fullname'::TEXT))::INTEGER, 1::INTEGER ) AS newname ) SELECT 'フン　' ||:'fullname' ||' というのかい。贅沢な名だねぇ' ||E'\n' ||'今からお前の名は ' ||newname ||'　だ。いいかい、' ||newname ||' だよ。' ||E'\n'||'わかったら返事をするんだ、' ||E'\n'||'!!' AS "湯婆婆" FROM yourname;

MySQL 8.0

最後に、MySQL 湯婆婆

mysql> SET @契約書だよ。そこに名前を書きな = '山田千尋'; Query OK, 0 rows affected (0.13 sec) mysql> \! vi mysql_yubaba.sql mysql> \. mysql_yubaba.sql Query OK, 0 rows affected (0.02 sec) *************************** 1. row *************************** 湯婆婆: フン　山田千尋というのかい。贅沢な名だねぇ今からお前の名は尋　だ。いいかい、尋だよ。わかったら返事をするんだ、 !! 1 row in set (0.02 sec)

$ cat mysql_yubaba.sql SET sql_mode = 'ANSI'; WITH yourname AS ( SELECT SUBSTRING( @契約書だよ。そこに名前を書きな , CEIL(RAND() * CHAR_LENGTH(@契約書だよ。そこに名前を書きな)), 1 ) AS newname ) SELECT 'フン　' ||@契約書だよ。そこに名前を書きな ||' というのかい。贅沢な名だねぇ' ||'\r\n' ||'今からお前の名は ' ||newname ||'　だ。いいかい、' ||newname ||' だよ。' ||'\r\n'||'わかったら返事をするんだ、' ||'\r\n'||'!!' AS "湯婆婆" FROM yourname\G

こういう遊びはみなさん好きですよね？　
では、また。

似たようなネタのエントリー
・Oracle de Fizzbuzz #1 -　いまごろ・・・ですが・・
・Oracle de Fizzbuzz #2
・Mac de Caché というか MUMPS というか Objectscript か - fizzbuzz
・PL/SQL de ケンブリッジ関数
・こんなのでいいのかなぁ。ズンドコキヨシ　　ObjectScript / MUMPS

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)

投稿日時 2020年12月26日 (土) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

2020年12月25日 (金)

標準はあるにはあるが癖の多いSQL 全部俺　#25 SQL de Fractalsにも癖がある:)

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の25日目です。

５年前にクリスマスのお遊び - SQL de Fractals :)というネタを書いてました。

EXPLAIN EXTENDED - Happy New Year!
元ネタは、ARRAY_TO_STRINGとARRAY_AGGの組み合わせ、とgenerate_seriesを利用した再帰問合せを利用したPostgreSQLバージョンのSQL

今であれば、以下のように書き換え、STRING_AGGでけにした方が良いのではないだろうか。
また、generate_series部分の方言の影響を最小にするのであれば、この部分も再帰問合せを利用した一連番号のセット生成にするなどの変更は可能ですね。

では、オリジナルのPostgreSQLの構文でARRAY_TO_STRINGとARRAY_AGGをSTRING_AGGに変更した例から（generate_seriesを階層再帰問合せにすることも可能）

PostgreSQL

WITH RECURSIVE q (r, i, rx, ix, g) AS ( SELECT r::DOUBLE PRECISION * 0.02 , i::DOUBLE PRECISION * 0.02 , .0::DOUBLE PRECISION , .0::DOUBLE PRECISION , 0 FROM generate_series(-60, 20) r , generate_series(-50, 50) i UNION ALL SELECT r , i , CASE WHEN ABS(rx * rx + ix * ix) <= 2 THEN rx * rx - ix * ix END + r , CASE WHEN ABS(rx * rx + ix * ix) <= 2 THEN 2 * rx * ix END + i , g + 1 FROM q WHERE rx IS NOT NULL AND g < 99 ) SELECT STRING_AGG(s, '' ORDER BY r) AS Mandelbrot FROM ( SELECT i, r, SUBSTRING(' .:-=+*#%@', MAX(g) / 10 + 1, 1) s FROM q GROUP BY i, r ) q GROUP BY i ORDER BY i;

Oracle

では、上記、非互換の多いSQLをOracle向けに書き換えてみましょう。一連番号生成はOracleの方言である階層問合せにしてあります。あえてw
また、PostgreSQLのSTRING_AGG部分は、OracleのLISTAGGで代替しています。

WITH q (r, i, rx, ix, g) AS ( SELECT CAST(r.r AS DOUBLE PRECISION) * 0.02 AS r , CAST(i.i AS DOUBLE PRECISION) * 0.02 AS i , CAST(.0 AS DOUBLE PRECISION) AS rx , CAST(.0 AS DOUBLE PRECISION) AS ix , 0 AS g FROM ( SELECT LEVEL - 61 AS r FROM DUAL CONNECT BY LEVEL <= 80 ) r, ( SELECT LEVEL - 51 AS i FROM DUAL CONNECT BY LEVEL <= 100 ) i UNION ALL SELECT r , i , CASE WHEN ABS(rx * rx + ix * ix) <= 2 THEN rx * rx - ix * ix END + r AS rx , CASE WHEN ABS(rx * rx + ix * ix) <= 2 THEN 2 * rx * ix END + i AS ix , g + 1 AS g FROM q WHERE rx IS NOT NULL AND g < 99 ) SELECT LISTAGG(s,'') WITHIN GROUP ( ORDER BY r ) AS Mandelbrot FROM ( SELECT i, r, SUBSTR(' .:-=+*#%@', MAX(g) / 10 + 1, 1) s FROM q GROUP BY i, r ) q GROUP BY i ORDER BY i;

MySQL 8.0

さて、最後は、これまで一連番号生成が辛かったMySQLです。
MySQL 8.0から再帰問合せが利用できるようになったおかげてMySQLのSQLでもこんな遊びができるようになりました！！！！

すげーーーーーーーっ！

再帰問合せを駆使し、PostgreSQLのSTRING_AGG、OracleのLISTAGGの代替としてGROUP_CONCAT関数を利用しています。
部分文字列はSUBSTRINGですね。
そしてもう一つの非互換対応が　TRUNCATE(MAX(g) / 10 + 1, 0)　部分です。
OracleとPostgreSQLは　MAX(g) / 10 + 1　だけでも問題ないですが、MySQLでは MAX(g) / 10 + 1　の結果は整数にはなりません。
その対策としてTRUNCATEを追加しています。

なかなか痺れますね。これまで紹介してきた非互換対応の総まとめは大げさですが、それらを有効に組み合わせて書き換えてみました。

WITH RECURSIVE q (r, i, rx, ix, g) AS ( SELECT CAST(r.v AS DOUBLE PRECISION) * 0.02 AS r , CAST(i.v AS DOUBLE PRECISION) * 0.02 AS i , CAST(0.0 AS DOUBLE PRECISION) AS rx , CAST(0.0 AS DOUBLE PRECISION) AS ix , 0 AS g FROM ( WITH RECURSIVE gen_nums(v) AS ( SELECT -60 UNION ALL SELECT v + 1 FROM gen_nums WHERE v + 1 < 20 ) SELECT v from gen_nums ) r ,( WITH RECURSIVE gen_nums(v) AS ( SELECT -50 UNION ALL SELECT v + 1 FROM gen_nums WHERE v + 1 < 50 ) SELECT v from gen_nums ) i UNION ALL SELECT CAST(r AS DOUBLE PRECISION) AS r , CAST(i AS DOUBLE PRECISION) AS i , CAST( CASE WHEN ABS(rx * rx + ix * ix) <= 2 THEN rx * rx - ix * ix END + r AS DOUBLE PRECISION ) AS rx , CAST( CASE WHEN ABS(rx * rx + ix * ix) <= 2 THEN 2 * rx * ix END + i AS DOUBLE PRECISION ) AS ix , g + 1 AS g FROM q WHERE rx IS NOT NULL AND g < 99 ) SELECT GROUP_CONCAT(s,'' ORDER BY r SEPARATOR '') AS Mandelbrot FROM ( SELECT i, r, SUBSTRING(' .:-=+*#%@', TRUNCATE(MAX(g) / 10 + 1, 0), 1) s FROM q GROUP BY i, r ) q GROUP BY q.i ORDER BY q.i;

ちなみに、Redshiftは再帰的なCTEは現時点では未サポートなので再帰問合せが必要なお遊びは今のところできません。

Amazon Redshift - サポートされていないPostgreSQL機能
https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_unsupported-postgresql-features.html

さてさて、なんとか25個の窓を開けることができました。

今年は、コロナ禍の中、大変厳しい一年になりましたが、みなさま、お身体を大事に、そして、ご家族と過ごす時間を大切に。

メリークリスマス。（何年か前に作った Pipeline function で christmas treeのムービーで）

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある

投稿日時 2020年12月25日 (金) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar, AWS | 固定リンク | 0 | コメント (0)

2020年12月24日 (木)

標準はあるにはあるが癖の多いSQL 全部俺　#24 乱数作るにも癖がある

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の24日目です。

たまに、乱数が必要になることがあるのですが、その乱数生成にも癖があるんですよね。

簡単ですが今日はこれぐらいでw　（ラストスパートで息切れ中w

いつものようにOracleから

131.4 DBMS_RANDOMサブプログラムの要約
131.4.7 VALUEファンクション
https://docs.oracle.com/cd/F19136_01/arpls/DBMS_RANDOM.html#GUID-AAD9E936-D74F-440D-9E16-24F3F0DE8D31

Oracleの場合は組み込み関数ではなく、パッケージ関数として提供されています。この点が大きな違いですよね。

ORACLE> SELECT (DBMS_RANDOM.VALUE(1,10)) FROM dual; (DBMS_RANDOM.VALUE(1,10)) ------------------------- 3.37937063 ORACLE> SELECT DBMS_RANDOM.VALUE FROM dual; VALUE ---------- .853380477

PostgreSQL

表9.6 乱数関数
https://www.postgresql.jp/document/12/html/functions-math.html

postgres=> select random(); random ------------------- 0.774311667308211 (1 row)

MySQL

三者三様で皆関数名も違ったり、提供されている機能も差がありますね。

RAND([N])
https://dev.mysql.com/doc/refman/8.0/en/mathematical-functions.html#function_rand

mysql> select rand(); +--------------------+ | rand() | +--------------------+ | 0.6516789492700984 | +--------------------+ 1 row in set (0.06 sec)

クリスマス、何食べようか考えているところで、年越しそば予約してないことに気づくw　（なんとかなるさw

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある

投稿日時 2020年12月24日 (木) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

2020年12月23日 (水)

標準はあるにはあるが癖の多いSQL 全部俺　#23 複数行INSERTにも癖がある

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の23日目です。

クリスマスイブイブですね。なんとかここまできたw

ネタ尽きた感がなくもないですが、ほぼ使っている方はいないのではないかという、複数行INSERTにも癖があるというお話

では、Oracleからみてください

Oracle

INESRT
https://docs.oracle.com/cd/F19136_01/sqlrf/INSERT.html#GUID-903F8043-0254-4EE9-ACC1-CB8AC0AF3423

この構文実は、マルチテーブルインサートの変形パターンで同一表へ複数インサートするようにしたもの。。。
そもそもこの構文が方言ではあるのですが、。。。。

ORACLE> desc a Name Null? Type ----------------------------------------- -------- ---------------------------- ID NUMBER STR VARCHAR2(100) ORACLE> INSERT ALL 2 INTO a VALUES(2,'yama') 3 INTO a VALUES(3,'kawa') 4 INTO a VALUES(4,'umi') 5 SELECT * FROM dual;

PostgreSQL

PostgreSQLにはやはりない。そりゃ、Oracleの方言だからねw　ですが、一応同一表なら可能です。

INSERT
https://www.postgresql.jp/document/12/html/sql-insert.html

同じく、MySQLも同一構文。。。。

postgres=> \d a Table "bill.a" Column | Type | Collation | Nullable | Default --------+------------------------+-----------+----------+--------- id | integer | | | str | character varying(100) | | | postgres=> postgres=> INSERT postgres-> INTO a VALUES postgres-> (2,'yama') postgres-> ,(3,'kawa') postgres-> ,(4,'umi'); INSERT 0 3

MySQL(8.0)

INSERT
https://dev.mysql.com/doc/refman/8.0/en/insert.html

mysql> desc a; +-------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+--------------+------+-----+---------+-------+ | id | int | YES | | NULL | | | str | varchar(100) | YES | | NULL | | +-------+--------------+------+-----+---------+-------+ 2 rows in set (0.02 sec) mysql> INSERT -> INTO a VALUES -> (2,'yama') -> ,(3,'kawa') -> ,(4,'umi'); Query OK, 3 rows affected (0.07 sec) Records: 3 Duplicates: 0 Warnings: 0

クリスマスイブのネタ何にしよう。本気で浮かばないw　（最終日のネタはほぼできているのにw）

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある
・

投稿日時 2020年12月23日 (水) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

2020年12月22日 (火)

標準はあるにはあるが癖の多いSQL 全部俺　#22 集合演算にも癖がある

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の22日目です。

さて、残すところ、今日をいれてあと4回

なんとなくネタが１つ足りてない気がするがw　なんとかするw

ということで、集合演算の癖を見てみましょう。Oracle 20cがリリースされていたら試せた機能もありますが、使える環境がないので、マニュアルだけ貼っておきます。

Oracle 20c - SQL set演算子の拡張 - union [all] / minus [all] / intersect [all] / except[all]
https://docs.oracle.com/cd/F32587_01/ftnew/enhanced-sql-set-operators1.html

19cまではこんな感じ

Oracle 19c - UNION [ALL]、INTERSECTおよびMINUS演算子
https://docs.oracle.com/cd/F19136_01/sqlrf/The-UNION-ALL-INTERSECT-MINUS-Operators.html#GUID-B64FE747-586E-4513-945F-80CB197125EE

MINUSはOracleの方言です。そのうちシノニム扱いされて、EXCEPTが一般的に利用されることになっていくのでしょうね。

Oracle

ORACLE> r 1 SELECT * 2 FROM 3 ( 4 WITH gen_nums(v) 5 AS 6 ( 7 SELECT 1 8 FROM 9 dual 10 UNION ALL 11 SELECT v + 1 12 FROM 13 gen_nums 14 WHERE v + 1 <= 10 15 ) 16 SELECT v FROM gen_nums 17 ) 18 UNION 19 SELECT * 20 FROM 21 ( 22 WITH gen_nums(v) 23 AS 24 ( 25 SELECT 5 26 FROM 27 dual 28 UNION ALL 29 SELECT v + 1 30 FROM 31 gen_nums 32 WHERE v + 1 <= 15 33 ) 34 SELECT v FROM gen_nums 35 ) 36* ORDER BY 1 V ---------- 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 15 rows selected. ORACLE> r 1 SELECT * 2 FROM 3 ( 4 WITH gen_nums(v) 5 AS 6 ( 7 SELECT 1 8 FROM 9 dual 10 UNION ALL 11 SELECT v + 1 12 FROM 13 gen_nums 14 WHERE v + 1 <= 10 15 ) 16 SELECT v FROM gen_nums 17 ) 18 UNION ALL 19 SELECT * 20 FROM 21 ( 22 WITH gen_nums(v) 23 AS 24 ( 25 SELECT 5 26 FROM 27 dual 28 UNION ALL 29 ELECT v + 1 30 FROM 31 gen_nums 32 WHERE v + 1 <= 15 33 ) 34 SELECT v FROM gen_nums 35 ) 36* ORDER BY 1 V ---------- 1 2 3 4 5 5 6 6 7 7 8 8 9 9 10 10 11 12 13 14 15 21 rows selected. ORACLE> r 1 SELECT * 2 FROM 3 ( 4 WITH gen_nums(v) 5 AS 6 ( 7 SELECT 1 8 FROM 9 dual 10 UNION ALL 11 SELECT v + 1 12 FROM 13 gen_nums 14 WHERE v + 1 <= 10 15 ) 16 SELECT v FROM gen_nums 17 ) 18 INTERSECT 19 SELECT * 20 FROM 21 ( 22 WITH gen_nums(v) 23 AS 24 ( 25 SELECT 5 26 FROM 27 dual 28 UNION ALL 29 SELECT v + 1 30 FROM 31 gen_nums 32 WHERE v + 1 <= 15 33 ) 34 SELECT v FROM gen_nums 35 ) 36* ORDER BY 1 V ---------- 5 6 7 8 9 10 6 rows selected. ORACLE> r 1 SELECT * 2 FROM 3 ( 4 WITH gen_nums(v) 5 AS 6 ( 7 SELECT 1 8 FROM 9 dual 10 UNION ALL 11 SELECT v + 1 12 FROM 13 gen_nums 14 WHERE v + 1 <= 10 15 ) 16 SELECT v FROM gen_nums 17 ) 18 MINUS 19 SELECT * 20 FROM 21 ( 22 WITH gen_nums(v) 23 AS 24 ( 25 SELECT 5 26 FROM 27 dual 28 UNION ALL 29 SELECT v + 1 30 FROM 31 gen_nums 32 WHERE v + 1 <= 15 33 ) 34 SELECT v FROM gen_nums 35 ) 36* ORDER BY 1 V ---------- 1 2 3 4

PostgreSQL

union [all] / intersect[all] / except[all]
https://www.postgresql.jp/document/12/html/queries-union.html

これらの構文に関しては、PostgreSQLの方が一歩先でしたね：）

Oracle 20c以降ではこんなことができるようになるよ、というイメージをPostgreSQLで掴んでおくと良いかもしれないですねー

postgres=> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 1 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 10 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) a postgres-> UNION postgres-> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 5 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 15 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) b postgres-> ORDER BY 1; v ---- 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 (15 rows) postgres=> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 1 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 10 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) a postgres-> UNION ALL postgres-> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 5 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 15 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) b postgres-> ORDER BY 1; v ---- 1 2 3 4 5 5 6 6 7 7 8 8 9 9 10 10 11 12 13 14 15 (21 rows) postgres=> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 1 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 10 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) a postgres-> INTERSECT postgres-> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 5 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 15 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) b postgres-> ORDER BY 1; v ---- 5 6 7 8 9 10 (6 rows) postgres=> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 1 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 10 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) a postgres-> INTERSECT ALL postgres-> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 5 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 15 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) b postgres-> ORDER BY 1; v ---- 5 6 7 8 9 10 (6 rows) postgres=> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 1 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 10 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) a postgres-> EXCEPT postgres-> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 5 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 15 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) b postgres-> ORDER BY 1; v --- 1 2 3 4 (4 rows) postgres=> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 1 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 10 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) a postgres-> EXCEPT ALL postgres-> SELECT * postgres-> FROM postgres-> ( postgres(> WITH RECURSIVE gen_nums(v) postgres(> AS postgres(> ( postgres(> SELECT 5 postgres(> UNION ALL postgres(> SELECT v + 1 postgres(> FROM postgres(> gen_nums postgres(> WHERE v + 1 <= 15 postgres(> ) postgres(> SELECT v FROM gen_nums postgres(> ) b postgres-> ORDER BY 1; v --- 1 2 3 4 (4 rows)

MySQL (8.0)

union [all]

13.2.10.3 UNION Clause
https://dev.mysql.com/doc/refman/8.0/en/union.html

MySQLはこれらの部分では少々遅れてますね。実際同じ結果を得ようとすると工夫しないといけないです。
これまで実装されてこなかったということは、恐そのような用途で利用されることが少なかったということなのでしょうか。（想像でしかないけど。。なんとなく今後は実装されそうな方向に向かっているような雰囲気も感じつつ。）

mysql> SELECT * -> FROM -> ( -> WITH RECURSIVE gen_nums(v) -> AS -> ( -> SELECT 1 -> UNION ALL -> SELECT v + 1 -> FROM -> gen_nums -> WHERE v + 1 <= 10 -> ) -> SELECT v FROM gen_nums -> ) a -> UNION -> SELECT * -> FROM -> ( -> WITH RECURSIVE gen_nums(v) -> AS -> ( -> SELECT 5 -> UNION ALL -> SELECT v + 1 -> FROM -> gen_nums -> WHERE v + 1 <= 15 -> ) -> SELECT v FROM gen_nums -> ) b -> ORDER BY 1; +------+ | v | +------+ | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | | 7 | | 8 | | 9 | | 10 | | 11 | | 12 | | 13 | | 14 | | 15 | +------+ 15 rows in set (0.02 sec) mysql> SELECT * -> FROM -> ( -> WITH RECURSIVE gen_nums(v) -> AS -> ( -> SELECT 1 -> UNION ALL -> SELECT v + 1 -> FROM -> gen_nums -> WHERE v + 1 <= 10 -> ) -> SELECT v FROM gen_nums -> ) a -> UNION ALL -> SELECT * -> FROM -> ( -> WITH RECURSIVE gen_nums(v) -> AS -> ( -> SELECT 5 -> UNION ALL -> SELECT v + 1 -> FROM -> gen_nums -> WHERE v + 1 <= 15 -> ) -> SELECT v FROM gen_nums -> ) b -> ORDER BY 1; +------+ | v | +------+ | 1 | | 2 | | 3 | | 4 | | 5 | | 5 | | 6 | | 6 | | 7 | | 7 | | 8 | | 8 | | 9 | | 9 | | 10 | | 10 | | 11 | | 12 | | 13 | | 14 | | 15 | +------+ 21 rows in set (0.02 sec)

来年は全部俺、どうするかな。ネタの一気放出みたいな時間取りやすければいいんだけど。先週までは本気で辛かった。時間ギリギリでw

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある

投稿日時 2020年12月22日 (火) 00時00分 Oracle, FAQ, SQL, MySQL, PostgreSQL, Advent Calendar | 固定リンク | 0 | コメント (0)

2020年12月21日 (月)

標準はあるにはあるが癖の多いSQL 全部俺　#21 演算結果にも癖がある

標準はあるにはあるが癖の多いSQL 全部俺w Advent Calendar 2020の21日目です。

以前取り上げた内容にも近いですが、演算だけに着目した方がわかりやすいだろうということでネタにしてみました。

SQLを移植する場合は、このようなところでも注意しないと。。。ね。デフォルトの挙動に任せたままでは危険ですね

Oracle

ORACLE> SELECT 1 / 3 FROM dual; 1/3 ---------- .333333333 ORACLE> SELECT 1 / 3 * 3 FROM dual; 1/3*3 ---------- 1 ORACLE> SELECT (1 / 3) * 3 FROM dual; (1/3)*3 ---------- 1 ORACLE> SELECT CAST(1 AS DOUBLE PRECISION) / CAST(3 AS DOUBLE PRECISION) * CAST(3 AS DOUBLE PRECISION) FROM dual; CAST(1ASDOUBLEPRECISION)/CAST(3ASDOUBLEPRECISION)*CAST(3ASDOUBLEPRECISION) -------------------------------------------------------------------------- 1 ORACLE> SELECT DUMP(CAST(1 AS DOUBLE PRECISION) / CAST(3 AS DOUBLE PRECISION)) FROM dual; DUMP(CAST(1ASDOUBLEPRECISION)/CAST(3ASDOUBLEPRECISION)) -------------------------------------------------------------------------------- Typ=2 Len=21: 192,34,34,34,34,34,34,34,34,34,34,34,34,34,34,34,34,34,34,34,34 ORACLE> SELECT DUMP(CAST(1 AS DOUBLE PRECISION) / CAST(3 AS DOUBLE PRECISION) * CAST(3 AS DOUBLE PRECISION)) FROM dual; DUMP(CAST(1ASDOUBLEPRECISION)/CAST(3ASDOUBLEPRECISION)*CAST(3ASDOUBLEPRECISION)) -------------------------------------------------------------------------------- Typ=2 Len=21: 192,100,100,100,100,100,100,100,100,100,100,100,100,100,100,100,10 0,100,100,100,100

MySQL

Oracleに近いですが、若干差異がありますね。

mysql> SELECT 1 / 3; +--------+ | 1 / 3 | +--------+ | 0.3333 | +--------+ 1 row in set (0.02 sec) mysql> SELECT 1 / 3 * 3; +-----------+ | 1 / 3 * 3 | +-----------+ | 1.0000 | +-----------+ 1 row in set (0.02 sec) mysql> SELECT CAST(1 AS DOUBLE PRECISION) / 3 * 3; +---------------------------+ | cast(1 as double) / 3 * 3 | +---------------------------+ | 1 | +---------------------------+ 1 row in set (0.26 sec) mysql> SELECT CAST(1 AS DOUBLE) / CAST(3 AS DOUBLE) * 3; +-------------------------------------------+ | cast(1 as double) / cast(3 as double) * 3 | +-------------------------------------------+ | 1 | +-------------------------------------------+ 1 row in set (0.02 sec) mysql> SELECT CAST(1 AS DOUBLE) / CAST(3 AS DOUBLE) * CAST(3 AS DOUBLE); +-----------------------------------------------------------+ | cast(1 as double) / cast(3 as double) * cast(3 as double) | +-----------------------------------------------------------+ | 1 | +-----------------------------------------------------------+ 1 row in set (0.01 sec)

PostgreSQL

PostgreSQLはデフォルトの挙動が明らかに異なります。

postgres=> SELECT 1 / 3; ?column? ---------- 0 (1 row) postgres=> SELECT 1 / 3 * 3; ?column? ---------- 0 (1 row) postgres=> SELECT 1::DOUBLE PRECISION / 3::DOUBLE PRECISION * 3::DOUBLE PRECISION; ?column? ---------- 1 (1 row) postgres=> SELECT PG_TYPEOF(1::DOUBLE PRECISION / 3::DOUBLE PRECISION * 3::DOUBLE PRECISION); pg_typeof ------------------ double precision (1 row) postgres=> SELECT PG_TYPEOF(1 / 3 * 3); pg_typeof ----------- integer (1 row)

あと少し :)

・標準はあるにはあるが癖の多いSQL 全部俺　#1 Pagination
・標準はあるにはあるが癖の多いSQL 全部俺　#2 関数名は同じでも引数が逆の罠！
・標準はあるにはあるが癖の多いSQL 全部俺　#3 データ型確認したい時あるんです
・標準はあるにはあるが癖の多いSQL 全部俺　#4 リテラル値での除算の内部精度も違うのよ!
・標準はあるにはあるが癖の多いSQL 全部俺　#5 和暦変換機能ある方が少数派
・標準はあるにはあるが癖の多いSQL 全部俺　#6 時間厳守！
・標準はあるにはあるが癖の多いSQL 全部俺　#7 期間リテラル！
・標準はあるにはあるが癖の多いSQL 全部俺　#8 翌月末日って何日？
・標準はあるにはあるが癖の多いSQL 全部俺　#9 部分文字列の扱いでも癖が出る＞＜
・標準はあるにはあるが癖の多いSQL 全部俺　#10 文字列連結の罠（有名なやつ）
・標準はあるにはあるが癖の多いSQL 全部俺　#11 デュエル、じゃなくて、デュアル
・標準はあるにはあるが癖の多いSQL 全部俺　#12 文字[列]探すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#13 あると便利ですが意外となかったり
・標準はあるにはあるが癖の多いSQL 全部俺　#14 連番の集合を返すにも癖がある
・標準はあるにはあるが癖の多いSQL 全部俺　#15 SQL command line client
・標準はあるにはあるが癖の多いSQL 全部俺　#16 SQLのレントゲンを撮る方法
・標準はあるにはあるが癖の多いSQL 全部俺　#17 その空白は許されないのか？
・標準はあるにはあるが癖の多いSQL 全部俺　#18 (+)の外部結合は方言
・標準はあるにはあるが癖の多いSQL 全部俺　#19 帰ってきた、部分文字列の扱いでも癖w
・標準はあるにはあるが癖の多いSQL 全部俺　#20 結果セットを単一列に連結するにも癖がある

投稿日時 2020年12月21日 (月) 04時02分 Oracle, FAQ,

	Format	Description
Scan method	`SeqScan(table)`	Forces sequential scan on the table.
	`TidScan(table)`	Forces TID scan on the table.
	`IndexScan(table[ index...])`	Forces index scan on the table. Restricts to specified indexes if any.
	`IndexOnlyScan(table[ index...])`	Forces index-only scan on the table. Restricts to specified indexes if any. Index scan may be used if index-only scan is not available.
	`BitmapScan(table[ index...])`	Forces bitmap scan on the table. Restricts to specified indexes if any.
	`IndexScanRegexp(table[ POSIX Regexp...])` `IndexOnlyScanRegexp(table[ POSIX Regexp...])` `BitmapScanRegexp(table[ POSIX Regexp...])`	Forces index scan, index-only scan (For PostgreSQL 9.2 and later) or bitmap scan on the table. Restricts to indexes that matches the specified POSIX regular expression pattern.
	`NoSeqScan(table)`	Forces to not do sequential scan on the table.
	`NoTidScan(table)`	Forces to not do TID scan on the table.
	`NoIndexScan(table)`	Forces to not do index scan and index-only scan on the table.
	`NoIndexOnlyScan(table)`	Forces to not do index only scan on the table.
	`NoBitmapScan(table)`	Forces to not do bitmap scan on the table.
Join method	`NestLoop(table table[ table...])`	Forces nested loop for the joins on the tables specified.
	`HashJoin(table table[ table...])`	Forces hash join for the joins on the tables specified.
	`MergeJoin(table table[ table...])`	Forces merge join for the joins on the tables specified.
	`NoNestLoop(table table[ table...])`	Forces to not do nested loop for the joins on the tables specified.
	`NoHashJoin(table table[ table...])`	Forces to not do hash join for the joins on the tables specified.
	`NoMergeJoin(table table[ table...])`	Forces to not do merge join for the joins on the tables specified.
Join order	`Leading(table table[ table...])`	Forces join order as specified.
	`Leading(<join pair>)`	Forces join order and directions as specified. A join pair is a pair of tables and/or other join pairs enclosed by parentheses, which can make a nested structure.
Behavior control on Join	`Memoize(table table[ table...])`	Allows the topmost join of a join among the specified tables to Memoize the inner result. Not enforced.
	`NoMemoize(table table[ table...])`	Inhibits the topmost join of a join among the specified tables from Memoizing the inner result.
Row number correction	`Rows(table table[ table...] correction)`	Corrects row number of a result of the joins on the tables specified. The available correction methods are absolute (#), addition (+), subtract (-) and multiplication (*). should be a string that strtod() can understand.
Parallel query configuration	`Parallel(table <# of workers> [soft\|hard])`	Enforces or inhibits parallel execution of the specified table. <# of workers> is the desired number of parallel workers, where zero means inhibiting parallel execution. If the third parameter is soft (default), it just changes max_parallel_workers_per_gather and leaves everything else to the planner. Hard enforces the specified number of workers.
GUC	`Set(GUC-param value)`	Sets GUC parameter to the value defined while planner is running.

Hint Name	Description	Applicable Scopes
`BKA`, `NO_BKA`	Affects Batched Key Access join processing	Query block, table
`BNL`, `NO_BNL`	Prior to MySQL 8.0.20: affects Block Nested-Loop join processing; MySQL 8.0.18 and later: also affects hash join optimization; MySQL 8.0.20 and later: affects hash join optimization only	Query block, table
`DERIVED_CONDITION_PUSHDOWN`, `NO_DERIVED_CONDITION_PUSHDOWN`	Use or ignore the derived condition pushdown optimization for materialized derived tables (Added in MySQL 8.0.22)	Query block, table
`GROUP_INDEX`, `NO_GROUP_INDEX`	Use or ignore the specified index or indexes for index scans in `GROUP BY` operations (Added in MySQL 8.0.20)	Index
`HASH_JOIN`, `NO_HASH_JOIN`	Affects Hash Join optimization (MySQL 8.0.18 only	Query block, table
`INDEX`, `NO_INDEX`	Acts as the combination of `JOIN_INDEX`, `GROUP_INDEX`, and `ORDER_INDEX`, or as the combination of `NO_JOIN_INDEX`, `NO_GROUP_INDEX`, and `NO_ORDER_INDEX` (Added in MySQL 8.0.20)	Index
`INDEX_MERGE`, `NO_INDEX_MERGE`	Affects Index Merge optimization	Table, index
`JOIN_FIXED_ORDER`	Use table order specified in `FROM` clause for join order	Query block
`JOIN_INDEX`, `NO_JOIN_INDEX`	Use or ignore the specified index or indexes for any access method (Added in MySQL 8.0.20)	Index
`JOIN_ORDER`	Use table order specified in hint for join order	Query block
`JOIN_PREFIX`	Use table order specified in hint for first tables of join order	Query block
`JOIN_SUFFIX`	Use table order specified in hint for last tables of join order	Query block
`MAX_EXECUTION_TIME`	Limits statement execution time	Global
`MERGE`, `NO_MERGE`	Affects derived table/view merging into outer query block	Table
`MRR`, `NO_MRR`	Affects Multi-Range Read optimization	Table, index
`NO_ICP`	Affects Index Condition Pushdown optimization	Table, index
`NO_RANGE_OPTIMIZATION`	Affects range optimization	Table, index
`ORDER_INDEX`, `NO_ORDER_INDEX`	Use or ignore the specified index or indexes for sorting rows (Added in MySQL 8.0.20)	Index
`QB_NAME`	Assigns name to query block	Query block
`RESOURCE_GROUP`	Set resource group during statement execution	Global
`SEMIJOIN`, `NO_SEMIJOIN`	Affects semijoin strategies; beginning with MySQL 8.0.17, this also applies to antijoins	Query block
`SKIP_SCAN`, `NO_SKIP_SCAN`	Affects Skip Scan optimization	Table, index
`SET_VAR`	Set variable during statement execution	Global
`SUBQUERY`	Affects materialization, `IN`-to-`EXISTS` subquery strategies	Query block

DROP SHADOW CTRL

GaragebandとiMovieで

検索

Twitter

最近の記事

最近のコメント

最近のトラックバック

カテゴリー

Oracle

Apple

その他

Googleの広告

RSS

当サイトについて

2024年9月 7日 (土)

2024年8月21日 (水)

2024年8月16日 (金)

2024年8月 8日 (木)

2024年7月24日 (水)

2024年7月23日 (火)

2024年7月22日 (月)

2024年7月11日 (木)

2024年7月10日 (水)

2024年7月 8日 (月)

2024年7月 1日 (月)

2024年6月29日 (土)

2024年6月23日 (日)

2024年6月22日 (土)

2024年6月15日 (土)

2024年5月31日 (金)

2024年5月29日 (水)

2024年5月 4日 (土)

2024年1月27日 (土)

2023年12月17日 (日)

2023年12月13日 (水)

2023年12月10日 (日)

2023年12月 9日 (土)

2023年11月22日 (水)

Hint list

2023年11月17日 (金)

2023年9月23日 (土)

2023年9月 7日 (木)

2023年9月 2日 (土)

2023年8月29日 (火)

2023年8月 7日 (月)

2023年8月 4日 (金)

2020年12月26日 (土)

2020年12月25日 (金)

2020年12月24日 (木)

2020年12月23日 (水)

2020年12月22日 (火)

2020年12月21日 (月)