Bug #103001 1.3 MySQL 8.0 の新機能(JSON_VALUE() 関数~)
Submitted: 16 Mar 13:41 Modified: 24 Apr 14:46
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

[16 Mar 13:41] Hiroyasu Matsuhisa
Description:
> In many cases, this is simpler than creating a generated column from the JSON column and then creating an index on the generated column.

Suggestion (Japanese)

< ♪多くの場合、これは、JSON カラムから生成されたカラムを作成し、生成されたカラムにインデックスを作成するよりも簡単です。
---
> 多くの場合、これは、JSON カラムから生成カラムを作成し、生成カラムにインデックスを作成するよりも簡単です。

Original Doc. (English)

> This optimization is normally disabled, since it does not yield a noticeable performance benefit in most cases; the flag is set to off by default.

Suggestion (Japanese)

< ♪この最適化は、ほとんどの場合に顕著なパフォーマンス上の利点が得られないため、通常は無効になっているため、フラグはデフォルトで off に設定されます。
---
> この最適化は、ほとんどの場合に顕著なパフォーマンスの向上をもたらさないため、通常は無効になっています。フラグは、デフォルトで off に設定されます。

Original Doc. (English)

> Single preparation of statements.  As of MySQL 8.0.22, a prepared statement is prepared a single time, rather than once each time it is executed.

Suggestion (Japanese)

< ♪ステートメントの単一準備.  ♪MySQL 8.0.22 の時点では、プリコンパイルされたステートメントは、実行されるたびに一度ではなく、一度だけ準備されます。
---
> プリペアドステートメントの準備の単一化. MySQL 8.0.22 では、プリペアドステートメントは、実行されるたびに一度ではなく、最初に一度だけ準備されます。

Original Doc. (English)

> When executing a prepared statement of the form SELECT expr1, expr2, ... FROM table ORDER BY ?, passing an integer value N for the parameter no longer causes ordering of the results by the Nth expression in the select list; the results are no longer ordered, as is expected with ORDER BY constant.

Suggestion (Japanese)

< ♪SELECT expr1, expr2, ... FROM table ORDER BY ? 形式のプリコンパイルされたステートメントを実行するときに、パラメータに整数値 N を渡すと、選択リストの N th 式による結果の順序付けが行われなくなります。ORDER BY constant の場合と同様に、結果は順序付けされなくなります。
---
> SELECT expr1, expr2, ... FROM table ORDER BY ? 形式のプリペアドステートメントを実行するときに、パラメータに整数値 N を渡すと、選択リストの N th 式による結果の順序付けが行われなくなります。ORDER BY constant で期待される通りには、結果が順序付けされなくなります。

Original Doc. (English)

> Preparing a statement used as a prepared statement or within a stored procedure only once enhances the performance of the statement, since it negates the added cost of repeated preparation.

Suggestion (Japanese)

< ♪プリコンパイルされたステートメントとして、またはストアドプロシージャ内で使用されるステートメントを準備すると、ステートメントのパフォーマンスが一度だけ向上します。これは、繰返し準備の追加コストが削減されるためです。
---
> プリペアドステートメントとして、またはストアドプロシージャ内で使用されるステートメントとして最初に一度だけ準備することにより、ステートメントのパフォーマンスが向上します。これは、繰返し準備の追加コストが削減されるためです。

Original Doc. (English)

> As of MySQL 8.0.22, the server handles all instances of RIGHT JOIN internally as LEFT JOIN, eliminating a number of special cases in which a complete conversion was not performed at parse time.

Suggestion (Japanese)

< ♪MySQL 8.0.22 の時点では、サーバーは RIGHT JOIN のすべてのインスタンスを LEFT JOIN として内部的に処理するため、解析時に完全な変換が実行されなかった特殊なケースが数多くなくなります。
---
> MySQL 8.0.22 では、サーバーが RIGHT JOIN のすべてのインスタンスを LEFT JOIN として内部的に処理することで、パース時に完全な変換が行われないいくつかの特別なケースを排除しました。

Original Doc. (English)

> (also added in MySQL 8.0.22)

Suggestion (Japanese)

< (MySQL 8.0.22 でも追加)
---
> (こちらも MySQL 8.0.22 で追加)

Original Doc. (English)

> DML operations that read data from grant tables (through join lists or subqueries) but do not modify them, using any transaction isolation level.

Suggestion (Japanese)

< ♪(結合リストまたはサブクエリーを介して) 付与テーブルからデータを読み取るが、トランザクション分離レベルを使用して変更しない DML 操作。
---
> 任意のトランザクション分離レベルを使用して (結合リストまたはサブクエリーを介して) 付与テーブルからデータを読み取り、変更を伴わない DML 操作。

How to repeat:
https://dev.mysql.com/doc/translation-refman/8.0/ja/introduction.html#mysql-nutshell
[16 Mar 13:47] Hiroyasu Matsuhisa
Original Doc. (English)

> For additional information, see Grant Table Concurrency.

Suggestion (Japanese)

< 追加情報については ♪テーブル同時実行性の付与を参照してください。
---
> 追加情報については 付与テーブルの同時実行性を参照してください。

※「付与テーブルの同時実行性」または「権限付与テーブルの同時実行性」。リンク先の小見出しも同様。
[16 Mar 13:55] MySQL Verification Team
Thank you for the bug report.
[24 Apr 14:46] 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