SQLの大いなる飛躍。MySQL 8.0リリース

SQL-92をまだ使っていますか」というのが、私の講演の冒頭の質問でした。この質問をしたところ、驚くほど多くの聴衆が25年前の技術をまだ使っていることを認めました。もし私が、同じく1992年にリリースされたWindows 3.1をまだ使っている人はいるかと尋ねたら、ほんの一握りの人しか手を挙げなかったでしょう・・・・・・・。そして、彼らは明らかに冗談を言っていた。

もちろん、この比較はあまり公平ではありません。しかし、少なくとも、新しいSQL標準に関する技術的な働きかけがかなり不足していることは確かです。SQL-92以来、実際には5回のアップデートがありましたが、多くの開発者はそのことを聞いたことがないのです。最新バージョンはSQL: 2016です。

そのため、多くの開発者は、1999年以降、SQLが関係代数や関係モデルに限定されなくなったことを知らないでいます。SQL:1999では、関係代数では利用できない操作（水平方向に再帰的）が導入され、従来解釈されていた型の最初のパラダイム（配列！）が崩れました。

あれから19年、SQLの関数が関係性の考え方に沿っているかどうかは、もはや重要ではありません。重要なのは、関数が明確に定義されたセマンティクスを持ち、実際の問題を解決することなのです。学術的なアプローチは、実用的なアプローチに取って代わられたのです。今日、標準SQLはほとんどすべてのデータ処理問題に対する実用的な解決策を提供しています。その中には、リレーショナルな領域にとどまるものもあれば、そうでないものもあります。

備考

SQLデータベースの話をするときにリレーショナルと言わないように。SQLは、実は関係性だけではないのです。

多くの開発者が25年前と同じようにSQLを使っているのは残念なことです。その主な理由は、開発者の知識や関心の低さ、そしてデータベース製品に新しいSQLがサポートされていないことだと思います。

MySQLのサポートレベルについて見てみましょう。その市場シェアを考えると、MySQLが新しいSQLを蔑ろにしていることが、この不幸な状況に大きく寄与していると思うのです。私は、2013年のブログ記事 "MySQL is as bad for SQL as MongoDB is for NoSQL" で、この点を指摘しました。重要なメッセージは、"MongoDBは人気があるが、MySQLと同じように大きな代表格ではない"というものです。そこからキーワードを拝借してSQL"。

YouTubeのMySQL WATのプレゼンテーションで、問題のあるSQLの説明の例を見ることができます。なお、この動画は2012年のもので、MySQL 5.5（当時のGAバージョン）を使用しています。その後、MySQL 5.6、5.7が登場し、大きく改善されました。新規インストール時のデフォルト設定もかなり良くなりました。

特に、デフォルトを変更したときの影響を軽減する方法をきちんと考えてくれているのは嬉しいですね。例えば、ONLY_FULL_GROUP_BYがデフォルトで有効になっていたとき、彼らは主要なSQLデータベース間の最も完全な機能依存性チェックの実装により多くの時間を費やしました:.

MySQL 5.7 がリリースされたのと同じ頃、私は MySQL を攻撃するのをやめました。もちろん、冗談です。時折、私はまだ MySQL を叩いている・・・・・・。しかし、そのバッシングはそれ以来、あまり容易ではなくなった。

ところで、MySQLはいまだにチェック制約をサポートしていないことをご存知でしょうか？以前のバージョンと同じように、テーブル作成文の中でチェック制約を使うことはできますが、無視されます。そうです、警告なしに無視されるだけなのです。MariaDBでさえ、1年前にこの問題を修正しました。

うっ、またバッシングされてる！？すみません、古い習慣はなかなか直りませんね。

それにもかかわらず、MySQL の開発哲学は、ここ数回のリリースで大きく変化しています。何が起こったのでしょうか？答えはもうお分かりでしょう。Oracle が Sun を通じて MySQL を買収したため、MySQL は新しい管理下に置かれたのです。これはおそらく、過去10年間に SQL に起こったことの中で最高の出来事だと思います。

データベースのバージョンが1つになることで、SQLのエコシステム全体に大きな影響が出ると思う理由は簡単です。MySQL は鎖の中で最も弱いリンクです。そのリンクを強化すれば、チェーン全体がずっと強くなる。それについて詳しく説明しましょう。

MySQLは非常に人気があります。db-engines.com によると、2 番目に人気のある SQL データベースです。さらに重要なことは、最も人気のある無料の SQL データベースであるということです。このことは、複数の特定の SQL データベースを使用しなければならない人に大きな影響を与えます。このようなベンダーは、通常、コンテンツ管理システム（CRM）、電子商取引ソフトウェア、オブジェクトリレーショナルマッパー（ORM）などの製品を製造しているソフトウェアベンダーです。この点では、Java Object Oriented Querying (jOOQ)が非常に優れています。多くのベンダーは、通常サポートされているSQL言語のうち1つ、つまりMySQLのみに限定しています。

MySQL の影響を受けるもう 1 つの重要なグループは、SQL を学習する人たちです。彼らは、最も人気のあるフリーの SQL データベースが学習の良い基礎になると合理的に考えることができます。彼らが知らないのは、MySQL が SQL-foo を多くの SQL 言語の中で最も弱いものに制限しているということです。Joe Celko の発言に基づくと、これらの人々はキーワードは知っているが、その本当の意味を理解していない。さらに悪いことに、彼らは最新の SQL 機能をまったく知らないのです。

先週、オラクルがMySQL 8.0の一般利用可能バージョンをリリースしたことで、すべてが変わりました。これは、MySQL が SQL-92 と純粋なリレーショナルドグマをついに超えたという点で、画期的なリリースとなった。他の多くの標準的なSQL機能の中で、MySQLはウィンドウ関数（over）と共通テーブル式（with）をサポートするようになった。これらは間違いなく、ポスト SQL-92 の最も重要な機能のうちの 2 つです。

ソフトウェアベンダが、MySQL がサポートしていないためこれらの機能は利用できないと主張する時代は終わりを告げようとしているのです。現在最も人気のあるフリーの SQL データベースのドキュメントにも、すでにウィンドウ関数と一般的なテーブル式が含まれています。MySQL 8.0 は、データベースにとって小さな一歩、SQL にとっては大きな一歩である、と大胆に主張させてください。

事態は好転し、未来は明るい! MySQLはすでにOracleの手に渡っているので、MySQLの元チーム（オリジナルのクリエイターがいる）は、MariaDBを作成した。どうやら彼らの戦略は、多くの新しい機能を追加して、MySQLユーザーに彼らの競合製品を検討するように説得することであるようだ。個人的には、彼らは品質を犠牲にすると思う-昔のMySQLのように-が、それは別の話だ。ここでは、MariaDBは1年前までチェック制約を有効にしており、それがより実質的なものである。このことから、MySQLはいつまでチェック制約を無視し続けることができるのか、という疑問が生まれます。言い換えれば、彼らはいつまで私のバッシングに我慢できるのか、ということです;)

MariaDB 10.2では、チェック制約に加え、ウィンドウ関数とCTE（Common Table Expressions）が導入されました。当時、MySQLにはCTEのベータ版があったが、ウィンドウ機能はなかった。mariaDBは急速に改善されている。

10.3では、MariaDBは"システムバージョン管理されたテーブル"を公開するよう設定されました。簡単に言うと、テーブルがアクティブになると、システムのバージョン管理制御により、更新された行や削除された行の古いバージョンが保持されるようになります。デフォルトでは、クエリは通常通り現在のバージョンを返しますが、古いバージョンを取得するために特別な構文（as of）を使用することができます。これについては、MariaDBのアナウンスで詳細を読むことができます。

システムのバージョニングは、2011年に標準SQLで導入されました。そして今、MariaDBがそれをサポートする最初のフリーのSQLデータベースになるようです。これが他のベンダーにとって、そしてベンダーに新しいSQLの機能をサポートするよう求めるユーザーにとって、インセンティブになることを願っています

新しいSQLの採用がようやくある程度支持されるようになったので、残るは細かい問題です。標準定義関数には多くのサブ関数があり、その数の多さから、通常はその一部しかサポートされていません。つまり、単にデータベースが窓関数をサポートしているというだけでは不十分なのです。実際にどのようなウィンドウ関数がサポートされているのか？どれがどんな単位なのか？(これらの質問に対する答えが、マーケティング上のギミックと本当に強力な機能を区別するのです。

開発者が新しいSQLを使いやすくするために、これらの詳細をテストして、製品間の違いを浮き彫りにしているんだ。これらのテストの結果は、上記と同じ表で紹介しています。この記事の残りの部分では、MySQL 8.0 で導入された新しい標準 SQL 機能を簡単に説明し、実装の違いについていくつか説明します。ご覧のように、MySQL 8.0 はこの点で非常に優れています。注目すべき例外は、その JSON 機能です。

ウインドウ機能

SQLは、窓関数以前のSQLと窓関数以降のSQLに分けられますが、窓関数がすべてを変えたと言っても過言ではありません。窓関数を一度理解すると、窓関数がない生活は考えられません。最も一般的な使い方は、例えば、グループごとに最適なN行を見つける、移動平均や累計を作成する、連続するイベントをグループ化するなど、氷山の一角を占めるだけです。窓関数は、自己接合を回避するための最も重要なツールのひとつです。これだけで、クエリの冗長性を減らし、高速化することができます。ウィンドウ関数は非常に強力なので、Apache SQLの実装（Hive、Impala、Spark）、NuoDB、Google BigQueryといった新しいものでも数年前に導入しています。だから、MySQLが追加されたというのは本当に遅いんだ。

下の表は、主要な SQL データベースの over 節のサポート状況を示しています。ご覧の通り、MySQLの実装は、PostgreSQLがその新しいホームページで主張しているように、実際には"世界で最も先進的なオープンソースリレーショナルデータベース"の能力を超えています。しかし、PostgreSQL 11はこの分野のリーダーとしての地位を取り戻すことでしょう。

MySQL 8.0 が提供する実際のウィンドウ関数のセットもまた、最新の状態に非常に近いものです。

汎用テーブル式（[recursive]付き）

MySQL 8.0 の次の大きな強化点は、汎用テーブル式または [recursive] 節を持つことです。重要なユースケースは、単一のクエリを使用したグラフのトラバース、任意の数の行の生成、CSV ストリングの行への変換（inverse listagg/group_concat） またはリテラート SQL です。

再び、MySQL の最初の実装がその差を縮める。

その他の標準SQL関数

MySQL 8.0 では、ウィンドウ関数と with 節の他に、いくつかの標準的な SQL 機能が導入されています。しかし、最初の2つと比べると、これは決してキラー機能ではありません。

このように、Oracleは標準SQLにおけるJSONサポートを推進しており、Oracle DatabaseとMySQLは現在この分野のリーダーです（両方とも同じベンダーの製品です！）。json_objectaggとjson_arrayaggの機能は、MySQL 5.7.22で互換性があるほどです。しかし、MySQLはこれら2つの関数の標準的な構文に従っていないことに注意する必要があります。json_objectagg はキーワードである key と value を認識せず、属性名と値を区切るコロン (:) も受け付けません。MySQL は、標準に記述された構文ではなく、通常の関数呼び出しとしてこれらを解析しているようです。

また、Oracleデータベース（NULLをデフォルトで無視しない）と同様に、json_arrayaggはNULL値の処理にエラーがあるようで、興味深いです。無関係と思われる2つの製品で同じ問題が見られるのは、いつも興味深いことです。さらに、両方の製品が同じベンダーのものであるという事実が、別のひねりを加えています。

リストの最後の2つの関数、グループ化関数（ロールアップに関連）とfrom句のカラム名は、特定の問題に対する解決策です。それらの MySQL 8.0 の実装は、他のデータベースとほぼ一致しています。

さらに、MySQL 8.0 では、標準的な SQL ロールが導入されています。上記の表が掲載されていない理由は簡単で、この表は私がこれらのデータベースすべてで実際に実行したテストに基づいているからです。私が自分で開発したテストフレームワークは、まだ複数のユーザーを必要とするテストケースをサポートしていません。現在、すべてのテストはデフォルトユーザーで実行されているため、アクセス権をテストすることはできません。しかし、時間をかけて改良していくつもりなので、期待していてください。

その他の主な機能強化

この記事の最後に、SQL標準とは関係のないMySQL 8.0のパッチと改善点を紹介したいと思います。

そのうちの1つは、インデックス宣言におけるdesc修飾子の使用に関するものです。

すべてではないにしても、ほとんどのデータベースは、order by句と同じロジックをインデックス作成に使用しています。つまり、デフォルトでは、列の値は昇順でソートされます。時には、いくつかのインデックスカラムを逆方向にソートすることが必要な場合があります。これは、インデックスに desc を指定する必要がある場合です。以下は、MySQL 5.7 のドキュメントに記載されている内容です。

index_col_name の指定は、ASC または DESC で終わらせることができます。これらのキーワードは、将来の拡張でインデックス値を格納する際の昇順または降順を指定するために使用することができます。現在、これらは構文解析を通過しますが、それまでの間は無視されます。 インデックス値は常に昇順で保存されます。

"シンタックスでパースされるが、同時に無視される"？具体的には、構文解析を通過しますが、上記のチェック制約のように警告なしで無視されます。

しかし、これは MySQL 8.0 で修正されました。警告が表示されるようになったのです。冗談です。Desc は現在でも非常に具体的です。

MySQL 8.0 には、他にも多くの改良点があります。MySQL 8.0 の新機能" を参照してください。その他は、記事で確認できます。

• ヒストグラム（オプティマイザ統計） (https://dev.mysql.com/doc/refman/8.0/en/analyze-table.html)

• InnoDBのデータ辞書（MyISAMの末尾も参照） (https://mysqlserverteam.com/atomic-ddl-in-mysql-8-0/)

• 暗黙のインデックス (https://mysqlserverteam.com/mysql-8-0-invisible-indexes/)

• デフォルトの改善(latin1_swedish_ciはもういらない！) (https://mysqlserverteam.com/new-defaults-in-mysql-8-0/)

<スパン ∞ <スパン ∞

ITパイ - {技術系青年サークル}のご紹介です。 <スパン インターネット、ブロックチェーン、人工知能に引き続き注目

<スパン 公開回答 <スパン "グループに参加する" <スパン は、その

<スパン ご招待します {IT Pie インタラクティブ・ファン・グループ｝