MySQL 8.0 マニュアル(Rev.68436)

2021-01-06
revision: 68430 to 68436

はじめに

 開始して3回目の日記ですが、うん、これは毎回の変更を追うのは、無理だ(笑)。
ということで、更新のたびに(日記を)更新、というのは断念し、次回以降は、目についた面白そうな更新があるときだけ紹介するようにしたいと思います。

全体の更新の傾向

 数日間見た程度の範囲ですが、以下のような更新の傾向を感じました。

  • 機能やオプション、変数らの追加に対する説明の追加
  • リファレンスマニュアルの索引への情報追加
  • 本文へのちょっとした(もうひとこと)説明の追加
  • ドキュメントソース(今回はhtmlで比較確認)改行位置の変更
  • 冠詞の変更、言い回しの変更などの、内容を大きくは変えないがニュアンスに影響する変更

 この中で、本質的な内容の追加・変更ではない部分を目視で判断していくところが、結構大変だなーというのが現時点での感想です。

今回(r68436) での変更点

 引き続き、AUTOEXTEND_SIZE に関する説明の追加や書換えが目立ちます。INFORMATION_SCHEMA.INNODB_TABLESPACES からの extend size 情報の取得SQL例など。

 その他、レプリケーションについて、こんな記述が追加:

From MySQL 8.0.23, you can improve the performance of semisynchronous replication by enabling the system variables replication_sender_observe_commit_only, which limits callbacks, and replication_optimize_for_static_plugin_config, which adds shared locks and avoids necessary lock acquisitions. These settings help as the number of replicas increases, because contention for locks can slow down performance. Semisynchronous replication source servers can also get performance benefits from enabling these system variables, because they use the same locking mechanisms as the replicas.

MySQL 8.0.23 からは、システム変数 replication_sender_observe_commit_only を有効にしてコールバックを制限し、 replication_optimize_for_static_plugin_config を有効にして、共有ロックを追加して不要なロック取得を回避することで、準同期レプリケーションのパフォーマンスを向上させることができます。これらの設定は、レプリカの数が増えるにつれて役立ちます。
なぜなら、ロックの競合はパフォーマンスを低下させる可能性があるからです。準同期レプリケーションのソースサーバは、これらのシステム変数を有効にすることでもパフォーマンスを向上させることができます。


では次回はまた気が向いたときに:^)


追記

 ちょっとしたことは、ここに追記していくことにしよう。

  • 2021-01-08 (revision: 68447) は、主にレプリケーション用語の修正。 MASTER→REPLICATION SOURCE, SLAVE→REPLICA。そうか、CHANGE MASTER が CHANGE REPLICATION SOURCE になるのか。長いなぁ。

MySQL 8.0 マニュアル(Rev.68430)

2021-01-04 → 2021-01-05
revision: 68413 to 68430


基本的には、auto-extend に関するあれこれ追加。

マニュアルのインデックスへの追加や
13.1.10 ALTER TABLESPACE Statement に AUTOEXTEND_SIZE に関する情報をより詳細に記述追加


5.1.4 Server Option, System Variable, and Status Variable Reference
5.1.5 Server System Variable Reference
5.1.9.2 Dynamic System Variables
の一覧表に

  • replication_optimize_for_static_plugin_config
  • replication_sender_observe_commit_only

を追加

インデックスの追加の例は、
https://dev.mysql.com/doc/refman/8.0/en/dynindex-sysvar.html

  • Section 17.1.6.3, “Replica Server Options and Variables”
  • Section 17.1.6.5, “Global Transaction ID System Variables”

を追加 など

MySQL 8.0 マニュアル(Rev.68413)

日々更新されている MySQL リファレンスマニュアル。どれくらい、どんな事がどんな粒度で更新されているのかを知りたくなったので、少しおいかけてみています。気が向いた範囲でここでも披露できればと思います。
 もう既に、こりゃ大変だ、、と気づいてしまい、やめる気満々なのですが、ちょっとだけ。



2021-01-04時点
revision: 68409 から revision: 68413 の変更内容(主観による要約)。

Section 15.6.3.9, “Tablespace AUTOEXTEND_SIZE Configuration”追加

表領域のサイズがエクステント未満の場合は、 一度に 1 ページずつ拡張される。
表空間が 1 エクステントより大きくてもサイズが 32 エクステントより小さい場合は、1 度に 1 エクステントずつ拡張される。
表領域のサイズが 32 エクステントを超えている場合は、一度に 4 エクステントずつ拡張される。
エクステントについて詳しい情報は Section 15.11.2, “File Space Management"

MySQL 8.0.23 からは、file-per-table や 一般のテーブルスペースを拡張する量は、 AUTOEXTEND_SIZE オプションで設定可能。大きめの拡張サイズを設定することで、フラグメンテーションを回避して大きなデータを扱いやすくなる。

https://dev.mysql.com/doc/refman/8.0/en/innodb-tablespace-autoextend-size.html

MySQLの地理情報データをQGISで表示する方法

この日記は、 RDBMS-GIS(MySQL,PostgreSQLなど) Advent Calendar 2020 の14日目ぶんとして後から書いているものです。

この日記は

 QGISという GISの専用ツールがあります。 QGIS が何かについては私も語るほど整理できた情報を持っていないので、とにかく地理情報(緯度経度等の情報)のデータを、表示したり色々したりできるツールです(雑な説明)。
この、QGISからMySQLにアクセスし、MySQLのデータを表示する試みを紹介します。本日記ではとりあえず、Windows上で MySQLに接続して、テーブルまるごと表示するところまでです。
f:id:sakaik:20201224230835p:plain

概要

 実は非常に苦労して、あれこれトライしていたのですが(MySQLに接続されるものの、データが表示されなかった)、QGIS を 3.10 から 3.16 に上げたら、あっさりと表示されるようになりました。なので、この日記で紹介するものは、非常にシンプルです。 なんだったんだ、この数日の苦労は。。でも嬉しい。


 以下、手順を示します。

QGIS のインストール

 QGISWindows 10 にインストールします。今回成功したバージョンは 3.16 です。

MySQL にデータを用意

 以下の日記を参考にするなどして、適当なデータをMySQLに登録しておきます。今回動作しているのは MySQL 8.0.22 です。
sakaik.hateblo.jp
 私は、上の日記を書いたあとで、全国の境界値データと、全国の湖沼データを登録しておきました。

QGIS から MySQL への接続情報の登録

 レイヤ - データソースマネージャ を開きます。
左ペインで「ベクタ」を選択し、
 ソースタイプ:データベース
を選択。

データベース は「新規」を押して、以下の画面のとおりに設定。名前はお好きな名前で。
 タイプ:MySQL
 ホスト:localhost
 データベース:(データの入っているデータベース(スキーマ)名)ここでは shptest
 ポート番号:特に設定変更していなければ 3306
 認証はベーシックにして ユーザ名とパスワードを設定。保存にチェックを入れておくと、毎回入れなくて済むのでラク。「構成に変換」を押して変換しておくのが吉(そうでない場合はパスワードも平文で保存/表示されます)
f:id:sakaik:20201224225734p:plain

 「接続テスト」ボタン押下して接続が問題なければ、OK。
ここまでで、MySQLへの接続情報の登録が完了しました。
この画面を開いたままで、次の作業へと進みます。
閉じちゃった場合、次回以降は レイヤ - レイヤを追加 - ベクタレイヤを追加 で同じ画面が開かれます。接続情報は記憶されているので、上記DB接続設定作業を繰り返す必要はありません。
f:id:sakaik:20201224225244p:plain 

QGISMySQLデータを読み込む

 とりあえず今回は、テーブルを指定して、そのテーブルの空間データをすべて表示する、ということが目標です。
データソースマネージャのベクタの画面を開き(この日記の手順通りにやってきた場合は、ひらきっぱなしになっている画面のことです)、「追加」ボタンを押下します。(ベクタレイヤを追加する、という指示になります)
 設定されたデータベース(スキーマ)の全テーブルが一覧表示されるので、QGISで参照したいテーブルを指定してOKを押します。データのサイズによっては少し時間がかかるので、処理が終わるのをおとなしく待ちましょう。
f:id:sakaik:20201224230643p:plain

 そして表示されるのが、冒頭の日本地図です。関東地方を拡大してみたのが以下の図。
f:id:sakaik:20201224231133p:plain

 たったこれだけです。

おまけ:表示の変更、調整など

 ここからは単純に QGIS の操作の話になります。もうMySQL関係ない。
左側にある「レイヤ」は、取り込んだテーブル1つがひとつのレイヤとなっています。チェックマークを付け外しすることで、表示オンオフを切り替えられます。レイヤの右端にハテナ(?)がついている場合は、そのレイヤに適切な測地系の指定が行われていません。クリックして、一応ちゃんと設定しておいたほうが良いでしょう。
 表示の塗りつぶしや線の色・太さを変えるには、レイヤのひとつを選択して、右クリックーシンボロジ(上から3番目)です。以下にキャプチャした画面で塗りつぶしの色や塗りつぶしパターンを、同画面上部の、ここでは「シンプル塗りつぶし」になっている部分をクリックすると、線の色や太さの設定ができます。
f:id:sakaik:20201224231604p:plain

まとめ

 MySQL(データつき) と QGIS が動作する環境で、QGISからMySQLへの接続情報の設定方法から表示までを説明しました。今回使った日本全土の境界ポリゴンは、構成するポイントが12万ポイント近くあります。なので、マシンスペックによっては表示に結構時間がかかる(北から順にじわじわと表示されていく感じ)と思います。今のところ私も「そういうものだ」と思っていますが、本気で今後触っていくにはポイント数の削減等を含め、もう少しサクサク動くようにしておきたいところですね。今後の課題といたします。






mysql CLCをWindows10上でデバッグするメモ

先日、Windows 10 上であっさりと mysql.exe が落ちる事象について書きました。
sakaik.hateblo.jp

早速、yoku0825 さんがバグ報告を上げてくださったので、対応されるのが楽しみです。
bugs.mysql.com


あとは本家の対応待ちでも良いのですが、あまりにも落ち方が潔かったので、ちょっと覗いてみたくなったので、やってみました。この日記は、Windows 10 上での mysql command line client (mysql CLC)のデバッグ環境のつくりかたのメモです。私のPCには一応、Visual Studio Community 2019 が入っているので、それを使います。MySQLサーバは動作済みであるものとします(今回ビルドするクライアントで、既に動作中のサーバに接続する、ということをやります)

ソースのダウンロードと展開

 今回は、mysql-8.0.22.zip を用意(当然、リリース直後にDL済み:-))。適当なフォルダに展開(今回は D:\work\mysql-8.0.22\)

Visual Studio 用のファイル群の作成(cmake)

 cmakeを使って、Windows用でビルドするための ソリューションファイルとかを生成させます。ソース内の client フォルダに移動してから実行します。私の環境では cmake にパスを通していなかったので、長々とフルパス指定で実行しました。 BOOST ライブラリをダウンロードする指定をせよ、とエラーになったので、指定しています。また、-G で指定する開発環境は、VS2018 までは 64ビット版用に Win64 という文字を付加していたのですが、2019ではなくなった、または、別オプションで指定することになったようです(古いブログを真似して Win64 を付けたりするとエラーになります)。

D:\work\mysql-8.0.22\client>"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake"  .. -DDOWNLOAD_BOOST=1 -DWITH_BOOST=. -G "Visual Studio 16 2019"

 これで sln ファイルが生成されました

Visual Studio の起動とプロジェクトの読み込みとビルド

 ファイル-開く-プロジェクト・ソリューション で、client フォルダ内の MySQL.sln を指定してひらきます。
次に、右ペインにある「ソリューションエクスプローラー」で mysql を選択して、右クリック、ビルド。日本語環境では、文字コードに関するワーニングが出ますが、今回追いかけたい部分には影響ないと判断し、とりあえず無視しておくことにします(ちゃんとやりたい場合は、せじまさんのブログを参考に、各ソースファイルに BOM を付けたら良いと思います)。
f:id:sakaik:20201224120843p:plain

 今回の設定の場合、ビルド後の実行ファイルは、client\runtime_output_directory\ に作成されます。(が、GUI上でデバッグするので、このファイルの所在を知らなくても今回は特に問題ありません)

 そういや、この時点ですでに mysql.ccのソースファイルを開いていますね、私。ソリューションエクスプローラーから、mysql - Source Files の中にあります。

mysql CLC の起動前の準備

 Visual Studio 上で mysql.exe をデバッグ実行したいのですが、接続用パラメタを与えないと起動してすぐに終了してしまいますよね。以下の方法で、起動パラメタを指定します。

プロジェクト-mysqlのプロパティを開く
f:id:sakaik:20201224121511p:plain

デバッグ-コマンド引数のところに、-u -p などのパラメタを指定する
f:id:sakaik:20201224121704p:plain

デバッグ実行

 デバッグ実行は、ソリューションエクスプローラーから mysql を右クリックで、デバッグ-新しいインスタンスの開始。
f:id:sakaik:20201224122101p:plain

 とりあえず、SELECT REPEAT('a', 1000000); とかを実行して、落ちるところを楽しみましょう。

その他の情報

 ソースコードの左端をクリックしてブレークポイントの赤丸を付けることができます。
その箇所で停まった状態から、ステップイン/ステップアウトは上部のアイコンから(あるいは F10/F11でもできます)。一旦停まっている状態で、とりあえず後は全部流しちゃっていいや、という時には、「続行」のアイコンで流せます。


 とりあえずこの方法でできたという話をまとめたものなので、もっと効率のよいやり方やショートカットなどの情報があれば、ぜひ教えてください。

MySQLの空間データ型の変換(2)~POINTの集合からLINESTRINGを作る~

この日記は、RDBMS-GIS(MySQL,PostgreSQLなど) Advent Calendar 2020 の24日目の記事です。

はじめに

 先日の日記で、LINESTRING や MULTIPOINT にある点の要素を、POINTのデータ群として得る方法のアイデアを紹介しました。
MySQLの空間データ型の変換(1)~MULTIPOINTやLINESTRINGからPOINTを得る~

 今回は、その続編として、POINT型のデータ群をつなげて LINESTRING にする方法のアイデアについて書きたいと思います。正直なところ「ちからワザ」です。とりあえずこのようなやり方で実現は可能だぞという、ひとつの思考実験的なものとしてお読みいただければと思います。
f:id:sakaik:20201218223043p:plain

実験データの用意

GEOMETRY型のカラムを持つ、以下のテーブルを作成し、データを投入します。とりあえず3件(3点)

CREATE TABLE t1 (id integer, p geometry, odr integer, cat varchar(1))
INSERT INTO t1 VALUES (1,  ST_GeomFromText('POINT(1 3)'), 10, "A");
INSERT INTO t1 VALUES (2,  ST_GeomFromText('POINT(2 2)'), 20, "A");
INSERT INTO t1 VALUES (3,  ST_GeomFromText('POINT(3 4)'), 30, "A");

この3つの点を、odr列の値の順につなげて LINESTRING 型の結果を得ることを目標とします。

思考実験

 処理のイメージとしては、

  • 必要なPOINT型の行を GROUP BY でひとかたまりとして扱って
  • SUM() 関数みたいな感じで、例えば GROUP_LINESTRING()みたいな集約関数を使って LINESTRING にする(その際ORDERも指定する)

なんてことができたらいいなと考えるわけですが、残念ながらそんなグルーピング関数はありません。

 仕方がないので、作戦変更し、POINT型の集合を得た後、自力で LINESTRING にすることを考えてみます。
LINESTRING にするためには、ST_GeomFromText('LINESTRING(1 1, 2 2, 3 3, 4 4)') のように、WKT文字列を構成してから ST_GeomFromText() で変換すれば良いわけです。

3点をLINESTRINGにしてみる

 ということで、先ほどの3つのPOINTをLINESTRINGに変換してみたのが以下のSQL
GROUP_CONCATを使って、抽出したPOINTのX,Yの集合をコンマ区切りでつなげます。GROUP_CONCAT の ORDER BY を使うことで、点の順序を指定できます。

SELECT ST_AsText(
    ST_GeomFromText(
    CONCAT("LINESTRING(", GROUP_CONCAT(ST_X(p), " ", ST_Y(p) ORDER BY odr), ")"))) a
 FROM t1
 WHERE cat="A";
+-------------------------+
| a                       |
+-------------------------+
| LINESTRING(1 3,2 2,3 4) |
+-------------------------+
1 row in set (0.00 sec)

 なんだかそれっぽいLINESTRINGが得られました。これ、単に文字列結合した結果が表示されているわけではなくて、一旦Geomに変換後、改めて表示用に ST_AsText() してるんですからね。
念のため、ORDER BY がちゃんと効いていることを確認するために、ORDER BY の DESC の動作も見ておきましょう。

mysql> SELECT ST_AsText(
    ->     ST_GeomFromText(
    ->     CONCAT("LINESTRING(", GROUP_CONCAT(ST_X(p), " ", ST_Y(p) ORDER BY odr DESC), ")"))) a
    ->  FROM t1
    ->  WHERE cat="A";
+-------------------------+
| a                       |
+-------------------------+
| LINESTRING(3 4,2 2,1 3) |
+-------------------------+

 期待通りに ORDER BY が働いているようです。

このクエリの制限と回避方法

 とりあえず力業で、やりたいことを実現させましたが、実はこのやり方は万能ではありません。
どこに落とし穴があるのか。それは GROUP_CONCAT() の文字数制限です。
デフォルトでは、GROUP_CONCATは 1024文字までを扱うことができます。この値は変更することができるので、実際に、先ほどのSQLのGROUP_CONCAT() が出力することになりそうな最大のサイズを見積もった上で、group_concat_max_len を設定すると良いでしょう。

mysql> show variables like 'group_con%';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| group_concat_max_len | 1024  |
+----------------------+-------+

もう少し点数の多い例でも確認

 3点だけではやや物足りないので、もう少し点数の多いPOINTを、LINESTRINGにしてみましょう。以下のSQLでデータを追加します。

INSERT INTO t1 VALUES (10,  ST_GeomFromText('POINT(1 2)'), 21, "T");
INSERT INTO t1 VALUES (11,  ST_GeomFromText('POINT(1 3)'), 25, "T");
INSERT INTO t1 VALUES (12,  ST_GeomFromText('POINT(1 4)'), 31, "T");
INSERT INTO t1 VALUES (13,  ST_GeomFromText('POINT(3 0)'), 12, "T");
INSERT INTO t1 VALUES (14,  ST_GeomFromText('POINT(3 2)'), 16, "T");
INSERT INTO t1 VALUES (15,  ST_GeomFromText('POINT(3 3)'), 24, "T");
INSERT INTO t1 VALUES (16,  ST_GeomFromText('POINT(3 4)'), 29, "T");
INSERT INTO t1 VALUES (17,  ST_GeomFromText('POINT(4 6)'), 33, "T");
INSERT INTO t1 VALUES (18,  ST_GeomFromText('POINT(5 2)'), 55, "T");
INSERT INTO t1 VALUES (19,  ST_GeomFromText('POINT(5 3)'), 50, "T");
INSERT INTO t1 VALUES (20, ST_GeomFromText('POINT(5 4)'), 36, "T");
INSERT INTO t1 VALUES (21, ST_GeomFromText('POINT(5 0)'), 60, "T");
INSERT INTO t1 VALUES (22, ST_GeomFromText('POINT(7 2)'), 53, "T");
INSERT INTO t1 VALUES (23, ST_GeomFromText('POINT(7 3)'), 39, "T");
INSERT INTO t1 VALUES (24, ST_GeomFromText('POINT(7 4)'), 34, "T");

 先ほどうまくいったクエリを少し改良して、、、、、

mysql> SELECT ST_AsText(
    ->     ST_GeomFromText(
    ->     CONCAT("LINESTRING(", GROUP_CONCAT(ST_X(p), " ", ST_Y(p) ORDER BY odr), ")"))) a
    ->  FROM t1
    ->  WHERE cat="T";
+-------------------------------------------------------------------------+
| a                                                                       |
+-------------------------------------------------------------------------+
| LINESTRING(3 0,3 2,1 2,3 3,1 3,3 4,1 4,4 6,7 4,5 4,7 3,5 3,7 2,5 2,5 0) |
+-------------------------------------------------------------------------+

 LINESTRING が得られました。目的達成です! でも文字だけの出力結果を見ても何だかよく分からないので、やっぱりビジュアルに表示してみたいですね。MySQL Workbench を使って見てみましょう。
その際、クエリ結果を人間が見るわけじゃないので、ST_AsText()は外します。

SELECT ST_GeomFromText(
    CONCAT("LINESTRING(", GROUP_CONCAT(ST_X(p), " ", ST_Y(p) ORDER BY odr), ")")) a
 FROM t1
WHERE cat="T";


f:id:sakaik:20201224002629p:plain

 メリークリスマス! Merry Xmas!!

カジュアルにmysqlを落とす(Windows)

 先日の日記を書くために色々試している最中、あまりにも潔く mysql クライアントコマンドがさくっと落ちるので、発生条件を調べてみました。原因の特定には至っていません。

起こっていること

 Windows 10 のMySQLにて、mysql> プロンプトが出ているところで、単純なSELECT文を叩くと、無言で mysql があっさり落ちる。

mysql> SELECT * FROM n03_20_200101 WHERE RECID<20;

D:\>

使用データ

 先日の日記に書いた方法で取り込んだ「全国」のデータ(千葉県ではなく全国)の入ったテーブルを使って再現させることができます。ふつうに blob に放り込んだ値を HEX() 取ったりしても再現できるかもしれません。あ、blob である必要すらなくて、varchar とか text とかでも良さそう。

sakaik.hateblo.jp

発生条件

 どうやら、結果セットに含まれるカラム値の サイズまたは行のサイズが大きすぎるときに落ちる気がする。

mysql> SELECT RECID, LENGTH(HEX(SHAPE)),LENGTH(ST_AsText(SHAPE)) FROM n03_20_200101 WHERE RECID<20;
+-------+--------------------+--------------------------+
| RECID | LENGTH(HEX(SHAPE)) | LENGTH(ST_AsText(SHAPE)) |
+-------+--------------------+--------------------------+
|     0 |              57826 |                    55812 |
|     1 |              57634 |                    55409 |
|     2 |              27394 |                    26233 |
|     3 |              25666 |                    24674 |
|     4 |              47362 |                    45461 |
|     5 |             162210 |                   156154 |
|     6 |              52898 |                    50970 |
|     7 |              22178 |                    21460 |
|     8 |              35874 |                    34414 |
|     9 |              56194 |                    54322 |
|    10 |               1154 |                     1079 |
|    11 |                386 |                      344 |
|    12 |                642 |                      582 |
(略)

という情報を元に、RECID=5 の行のみを抽出してみる。

mysql> SELECT RECID, LENGTH(SHAPE), ST_AsText(SHAPE) FROM n03_20_200101 WHERE RECID=5;

D:\>

うん、落ちた。AsTextとかよくわかんないという人は、代わりに HEX(SHAPE)でも良いです。

閾値はどこに

 試行錯誤で範囲を絞ったので、以下のクエリで閾値捜索の最後のツメを。

SELECT RECID, LENGTH(SHAPE) a, LENGTH(ST_AsText(SHAPE)) b FROM n03_20_200101 
  WHERE LENGTH(ST_AsText(SHAPE)) >101296 AND LENGTH(ST_AsText(SHAPE))<101719 ORDER BY b ;
+--------+-------+--------+
| RECID  | a     | b      |
+--------+-------+--------+
|  99545 | 54305 | 101297 |
|  31451 | 53921 | 101297 |
|  59657 | 54225 | 101307 |OK
|  33266 | 53905 | 101361 |OK
|  48032 | 54049 | 101376 |NG
|  32203 | 54245 | 101437 |
|  11066 | 53301 | 101528 |
| 115488 | 49233 | 101718 |
+--------+-------+--------+
8 rows in set (28.52 sec)
SELECT RECID, LENGTH(SHAPE), ST_AsText(SHAPE) FROM n03_20_200101 WHERE RECID=33266; --OK
SELECT RECID, LENGTH(SHAPE), ST_AsText(SHAPE) FROM n03_20_200101 WHERE RECID=48032; --NG

1文字ずつくわえて見ると RECID=33266 は1文字でも加えたら、もうアウト。

SELECT RECID, LENGTH(SHAPE), CONCAT(ST_AsText(SHAPE),"X") FROM n03_20_200101 WHERE RECID=59657; --OK
SELECT RECID, LENGTH(SHAPE), CONCAT(ST_AsText(SHAPE),"X") FROM n03_20_200101 WHERE RECID=33266; --NG

 もしかして、出力カラムのサイズではなくレコードサイズなのでは?と 余計な取得列を少しずつ削って見ると、アタリ。他の列をすべて取得やめてみた結果が以下のもの。

SELECT CONCAT(ST_AsText(SHAPE),"XXXXX") FROM n03_20_200101 WHERE RECID=33266;  //OK
SELECT CONCAT(ST_AsText(SHAPE),"XXXXXX") FROM n03_20_200101 WHERE RECID=33266; //NG

 101361+5= 101366 byte まではOK、 101367バイトがNGと推測できそうです。

環境

 Windows 10 上に、MySQL Installer を使ってインストールしたもの。サーバは utf8mb4、
クライアントは cp932 でも utfmb4 でも発生。

mysql> status
--------------
mysql  Ver 8.0.22 for Win64 on x86_64 (MySQL Community Server - GPL)

Connection id:          30
Current database:       shptest
Current user:           root@localhost
SSL:                    Cipher in use is TLS_AES_256_GCM_SHA384
Using delimiter:        ;
Server version:         8.0.22 MySQL Community Server - GPL
Protocol version:       10
Connection:             localhost via TCP/IP
Server characterset:    utf8mb4
Db     characterset:    utf8mb4
Client characterset:    cp932
Conn.  characterset:    cp932
TCP port:               3306
Binary data as:         Hexadecimal
Uptime:                 3 hours 35 min 55 sec

Threads: 4  Questions: 117  Slow queries: 8  Opens: 190  Flush tables: 3  Open tables: 111  Queries per second avg: 0.009
mysql> status
--------------
C:\Program Files\MySQL\MySQL Server 8.0\bin\mysql.exe  Ver 8.0.22 for Win64 on x86_64 (MySQL Community Server - GPL)

Connection id:          29
Current database:       shptest
Current user:           root@localhost
SSL:                    Cipher in use is TLS_AES_256_GCM_SHA384
Using delimiter:        ;
Server version:         8.0.22 MySQL Community Server - GPL
Protocol version:       10
Connection:             localhost via TCP/IP
Server characterset:    utf8mb4
Db     characterset:    utf8mb4
Client characterset:    utf8mb4
Conn.  characterset:    utf8mb4
TCP port:               3306
Binary data as:         Hexadecimal
Uptime:                 3 hours 35 min 21 sec

Threads: 3  Questions: 113  Slow queries: 8  Opens: 190  Flush tables: 3  Open tables: 111  Queries per second avg: 0.008

結局分からず仕舞い

 現時点では Linux での動作を試していないので、これが Windows固有の現象なのか OS問わず発生するものなのか、分かりません。また、サーバのエラーログには記録なしで、一切の調査の足がかりがないのが、なかなか辛いですね。 まぁ、許容サイズを超えてエラーになるのはまだしも、ストンと落ちてしまう(接続が切れてしまう)のはいただけないなぁというのが私の感覚です。

 mysql params でざっと見てみた感じでは、それっぽい制限値はなさそうで、もにゃもにゃした気分です。
variable / MySQL Parameters


 これ、なんなんですかね。

その晩の追記

 その後いろいろ試してみたら、とりあえず上で書いた「閾値」候補は、一旦とりさげ。
例えばこれ、

SELECT RECID, LENGTH(SHAPE), ST_AsText(SHAPE) FROM n03_20_200101 WHERE RECID=33266; --OK
SELECT RECID, LENGTH(SHAPE), ST_AsText(SHAPE) FROM n03_20_200101 WHERE RECID=48032; --NG

実行順序を逆にしたら、NGだったやつは通って、OKだったやつがダメになりました。もう少し再現性ある内容を書く前に、yoku0825さんが試してくれたものを紹介すると、これだけで落ちるらしい。

mysql> SELECT repeat('a', 101367);
(結果が表示される)

mysql> SELECT 'a';

D:\>

 「次のクエリをダメにするクエリ」みたいなのがあるっぽいと考えたほうがいいのかも?


もちょっと追記。「次のクエリをダメにするクエリ」という観点で試してみたら、こんな落とし方もあります、

mysql> SELECT repeat('a', 100000);
(結果が表示される)

mysql> STATUS

D:\>