Bug #102953 1.3 MySQL 8.0 の新機能(オプティマイザ~)
Submitted: 12 Mar 2021 15:11 Modified: 24 Apr 2021 15:45
Reporter: Hiroyasu Matsuhisa Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Japanese Documentation Severity:S3 (Non-critical)
Version:8.0.23 OS:Any
Assigned to: CPU Architecture:Any

[12 Mar 2021 15:11] Hiroyasu Matsuhisa
Description:
Original Doc. (English)

> MySQL now supports invisible indexes. An invisible index is not used by the optimizer at all, but is otherwise maintained normally. Indexes are visible by default.

Suggestion (Japanese)

< ♪MySQL で非表示インデックスがサポートされるようになりました。 ♪不可視のインデックスはオプティマイザではまったく使用されませんが、それ以外の場合は正常にメンテナンスされます。 ♪インデックスはデフォルトで表示されます。
---
> MySQL で不可視インデックスがサポートされるようになりました。不可視のインデックスはオプティマイザではまったく使用されませんが、それ以外の場合は正常にメンテナンスされます。インデックスはデフォルトで可視化されます。

Original Doc. (English)

> MySQL now supports creation of functional index key parts that index expression values rather than column values. Functional key parts enable indexing of values that cannot be indexed otherwise, such as JSON values.

Suggestion (Japanese)

< ♪MySQL では、カラム値ではなく式の値をインデックス付けするファンクションインデックスキー部分の作成がサポートされるようになりました。 ♪ファンクションキー部分を使用すると、JSON 値など、インデックス付けできない値をインデックス付けできます。
---
> MySQL では、カラム値ではなく式の値をインデックス化する関数インデックスキーパーツの作成がサポートされました。関数インデックスキーパーツを使用すると、JSON 値など、他の方法ではインデックス化できない値のインデックス化が可能です。

Original Doc. (English)

> In MySQL 8.0.14 and later, trivial WHERE conditions arising from constant literal expressions are removed during preparation, rather than later on during optimization. Removal of the condition earlier in the process makes it possible to simplify joins for queries with outer joins having trivial conditions, such as this one:

Suggestion (Japanese)

< ♪MySQL 8.0.14 以降では、定数リテラル式から発生する簡単な WHERE 条件は、後で最適化するのではなく、準備中に削除されます。 ♪このプロセスの前半で条件を削除すると、次のような簡易条件を持つ外部結合を含むクエリーの結合を簡略化できます:
---
> MySQL 8.0.14 以降では、定数リテラル式から発生する自明の WHERE 条件は、後で最適化するのではなく、準備の段階で削除されます。プロセスの初期段階で条件を削除すると、次のような自明の条件を持つ外部結合を含むクエリーの結合を簡略化できます:

Original Doc. (English)

> Beginning with MySQL 8.0.16, the semijoin optimizations used with IN subqueries can now be applied to EXISTS subqueries as well.

Suggestion (Japanese)

< ♪MySQL 8.0.16 以降、IN サブクエリーで使用される半結合最適化を EXISTS サブクエリーにも適用できるようになりました。
---
> MySQL 8.0.16 以降、IN サブクエリーで使用される準結合最適化を EXISTS サブクエリーにも適用できるようになりました。

※「半結合」「セミ結合」->「準結合」「セミ結合」「セミジョイン」のいずれかに統一(全体で)

Original Doc. (English)

> As of MySQL 8.0.17, the server rewrites any incomplete SQL predicates (that is, predicates having the form WHERE value, in which value is a column name or constant expression and no comparison operator is used) internally as WHERE value <> 0 during the contextualization phase, so that the query resolver, query optimizer, and query executor need work only with complete predicates.

Suggestion (Japanese)

< ♪MySQL 8.0.17 では、サーバーはコンテキスト化フェーズ中に不完全な SQL 述語 (つまり、value がカラム名または定数式で、比較演算子が使用されていない WHERE value 形式の述語) を WHERE value <> 0 として内部的にリライトするため、クエリーリゾルバ、クエリーオプティマイザおよびクエリーエグゼキュータは完全な述語のみを処理する必要があります。
---
> MySQL 8.0.17 では、サーバーはコンテキスト化フェーズ中に不完全な SQL 述語 (つまり、value がカラム名または定数式で、比較演算子が使用されていない WHERE value 形式の述語) を WHERE value <> 0 として内部的にリライトするため、クエリーリゾルバ、クエリーオプティマイザおよびクエリーエグゼキュータは完全な述語のみ処理すればよくなりました。

Original Doc. (English)

> Another effect of this change is that evaluation of a JSON value in an SQL boolean context performs an implicit comparison against JSON integer 0. Consider the table created and populated as shown here:

Suggestion (Japanese)

< ♪この変更の別の効果は、SQL ブールコンテキストで JSON 値を評価すると、JSON 整数 0 に対して暗黙的な比較が実行されることです。 ♪次に示すように、作成および移入されたテーブルについて考えてみます:
---
> この変更によるもう一つの効果は、SQL ブールコンテキストで JSON 値を評価すると、JSON の整数 0 との暗黙の比較が行われることです。次のデータが入ったテーブルを例に考えてみます:

Original Doc. (English)

> In MySQL 8.0.17 and later, the implicit copmparison of the extracted value with JSON integer 0 leads to a different result:

Suggestion (Japanese)

< ♪MySQL 8.0.17 以降では、抽出された値を JSON 整数 0 と暗黙的に比較すると、結果が異なります:
---
> MySQL 8.0.17 以降では、抽出された値と JSON 整数 0 との暗黙の照合により、異なる結果をもたらします:

Original Doc. (English)

> Also beginning with MySQL 8.0.21, the server provides the warning Evaluating a JSON value in SQL boolean context does an implicit comparison against JSON integer 0; if this is not what you want, consider converting JSON to an SQL numeric type with JSON_VALUE RETURNING when comparing extracted values in an SQL boolean context in this manner.

Suggestion (Japanese)

< ♪また、MySQL 8.0.21 以降では、この方法で SQL ブールコンテキストの抽出された値を比較する際に、サーバーによって警告「SQL ブールコンテキストで JSON 値を評価すると、JSON 整数 0 に対する暗黙的な比較が実行されます。これが必要でない場合は、JSON_VALUE RETURNING を使用して JSON を SQL 数値型に変換することを検討してください」が提供されます。
---
> また、MySQL 8.0.21 以降では、サーバーによって警告「Evaluating a JSON value in SQL boolean context does an implicit comparison against JSON integer 0; if this is not what you want, consider converting JSON to an SQL numeric type with JSON_VALUE RETURNING when comparing extracted values in an SQL boolean context in this manner.」(SQL ブールコンテキストで JSON 値を評価すると、JSON の整数 0 との暗黙の比較が行われます。想定と違う場合は、JSON_VALUE RETURNING を使用して JSON を SQL 数値型に変換することを検討してください)が表示されます。

How to repeat:
https://dev.mysql.com/doc/translation-refman/8.0/ja/introduction.html#mysql-nutshell
[12 Mar 2021 23:55] MySQL Verification Team
Thank you for the bug report.
[24 Apr 2021 15:45] Ryusuke Kajiyama
Posted by developer:
 
Fixed in MySQL 8.0 Reference Manual (Japanese) 
https://dev.mysql.com/doc/refman/8.0/ja/mysql-nutshell.html