承前
タイトルを見て何の事を言ってるのかわかる人向けのメモ書きです。結論としては「私もよくわかっていない」の段階ですが、調査して（正しいかどうかは分からないけど）多少の情報と仮説ができてきたので、メモとして記す次第です。
最終目的
MySQLの INFORMATION_SCHEMA.ST_SPATIAL_REFERENCE_SYSTEMS の JGD2011の定義には「towgs84」の記述が含まれていません。JGD2000には含まれています。Tokyoにも（値がなんかおかしいのは別の問題として一応）値は含まれています。JGD2000に含まれているのにJGD2011に含まれていないのはおかしい。含めて欲しい、というのが当方の立場です。
MySQLの立場
測地系に関する定義情報は、ソースコードの scripts/mysql_system_tables_data.sql に含まれています。このファイルの JGD2011の行に towgs84 を書いてくれればすべて解決です*1。しかし、MySQL開発チームはこれをやってくれません。
というのは、私の長年の活動の中で見聞きした感覚では、最近のMySQLの開発方針として「外部の組織が定めているものはそれに従うこととし、MySQL独自の部分的な変更や例外対応などはしない」というものがあるように思えます。文字コード（Unicode）もそうですし、今回の測地系の情報についても同じです。なので、大元の定義にないものを「JGD2011には towgs84が必要だから入れて」と言っても、簡単には対応してもらえない、という立場を取っていることを私は理解しています。
今回のケースでは EPSGの元の定義情報に何らかの変更が加わるか、そこからmysql_system_tables_data.sqlに変換する際のルールに（結果としてJGD2011に towgs84が加えられるような）合理的な変更の提案ができるか、のいずれかが、今採れる対応なのかな、と考えています。
登場する測地系情報
ここでは Tokyo（日本測地系）、JGD2000、JGD2011 を比較しながら眺めていきます。それぞれの SRIDは以下のとおりです。
| TOKYO | 4301 |
| JGD2000 | 4612 |
| JGD2011 | 6668 |
それぞれのEPSGによる定義
Tokyo
GEOGCS["Tokyo",
DATUM["Tokyo",
SPHEROID["Bessel 1841",6377397.155,299.1528128],
TOWGS84[-146.414,507.337,680.507,0,0,0,0]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4301"]]
JGD2000
GEOGCS["JGD2000",
DATUM["Japanese_Geodetic_Datum_2000",
SPHEROID["GRS 1980",6378137,298.257222101,
AUTHORITY["EPSG","7019"]],
AUTHORITY["EPSG","6612"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4612"]]
JGD2011
GEOGCS["JGD2011",
DATUM["Japanese_Geodetic_Datum_2011",
SPHEROID["GRS 1980",6378137,298.257222101,
AUTHORITY["EPSG","7019"]],
AUTHORITY["EPSG","1128"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","6668"]]
Tokyo測地系の課題
Tokyo(4301)の ST_SRS上の定義です。
mysql> SELECT * FROM ST_SPATIAL_REFERENCE_SYSTEMS WHERE SRS_ID='4301'\G
*************************** 1. row ***************************
SRS_NAME: Tokyo
SRS_ID: 4301
ORGANIZATION: EPSG
ORGANIZATION_COORDSYS_ID: 4301
DEFINITION: GEOGCS["Tokyo",DATUM["Tokyo",SPHEROID["Bessel 1841",6377397.155,299.1528128,AUTHORITY["EPSG","7004"]],TOWGS84[-147,506,687,0,0,0,0],AUTHORITY["EPSG","6301"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.017453292519943278,AUTHORITY["EPSG","9122"]],AXIS["Lat",NORTH],AXIS["Lon",EAST],AUTHORITY["EPSG","4301"]]
DESCRIPTION: NULLここにはちゃんと(?) TOWGS84 が含まれています。ただし、EPSGの定義と見比べると分かりますが、値がなんか変です。一致していません。本件については更に調査を進めているところなので、本稿ではこれ以上触れません。何か分かったら別途書きたいと思います。
TOWGS84[-147,506,687,0,0,0,0],
JGD2000の場合
JGD2000の場合は、EPSGの定義中には towgs84は含まれていませんが、MySQLの ST_SRS上には TOWGS84が含まれた定義が登録されています。何ででしょうね。このあと考察します。
mysql> SELECT * FROM ST_SPATIAL_REFERENCE_SYSTEMS WHERE SRS_ID='4612'\G
*************************** 1. row ***************************
SRS_NAME: JGD2000
SRS_ID: 4612
ORGANIZATION: EPSG
ORGANIZATION_COORDSYS_ID: 4612
DEFINITION: GEOGCS["JGD2000",DATUM["Japanese Geodetic Datum 2000",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6612"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.017453292519943278,AUTHORITY["EPSG","9122"]],AXIS["Lat",NORTH],AXIS["Lon",EAST],AUTHORITY["EPSG","4612"]]
DESCRIPTION: NULL
JGD2011の場合
JGD2011の場合は、EPSGの定義中にはtowgs84は含まれず、MySQLのST_SRSの定義中にもTOWGS84が含まれていません(含んで欲しい)。JGD2000とほぼ同等と見なして良いはずなのに、なぜでしょうね。
mysql> SELECT * FROM ST_SPATIAL_REFERENCE_SYSTEMS WHERE SRS_ID='6668'\G
*************************** 1. row ***************************
SRS_NAME: JGD2011
SRS_ID: 6668
ORGANIZATION: EPSG
ORGANIZATION_COORDSYS_ID: 6668
DEFINITION: GEOGCS["JGD2011",DATUM["Japanese Geodetic Datum 2011",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","1128"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.017453292519943278,AUTHORITY["EPSG","9122"]],AXIS["Lat",NORTH],AXIS["Lon",EAST],AUTHORITY["EPSG","6668"]]
DESCRIPTION: NULL
JGD2000とJGD2011の違い
ここから先は、完全に推測だけで書く内容です。仕様を確認して裏取りをした話ではなく、データを見て「もしかしてこういうことじゃね？」と想像した内容ですので、この点ご了承ください。
追記：その後の調査で、この段まるごと、まったく関係ないことが分かりました。こんなことを考えていたこともあったな、という記録として残しておきますので、内容は真に受けないようにお願いいたします。追記ここまで。
似たような JGD2000とJGD2011なのに、方やMySQLに持ってきたときにTOWGS84値を持ち、方や持たない、という状況になっています。MySQL上での定義は、EPSGの定義を元にあるルールに従って変換しているだけのはずなので、何かが違うはずです。どこが違うのかな。
関係ない（と私が判断した）ところをざっくりと畳んでみました。違いが分かるでしょうか。そう、DATUMの AUTHORITY が異なりますね。
GEOGCS["JGD2000",
DATUM["Japanese_Geodetic_Datum_2000",
SPHEROID[....],
AUTHORITY["EPSG","6612"]],
PRIMEM[....],
UNIT[....],
AUTHORITY["EPSG","4612"]]GEOGCS["JGD2011",
DATUM["Japanese_Geodetic_Datum_2011",
SPHEROID[....],
AUTHORITY["EPSG","1128"]],
PRIMEM[....],
UNIT[....],
AUTHORITY["EPSG","6668"]]
JGD2000のDATUM EPSG:6612、JGD2011のDATUM EPSG:1128それぞれの定義を見てみます。正直なところ、この追跡に意味があるか（正しいか）すら確証なく、とりあえず見てみている状態です(笑)。
JGD2000のEPSG:6612(一部省略)。DATUMに TOWGS84の記述が含まれています。ただしなんで NAD83に紐付いているのか、とか、これそもそも投影座標系じゃないかとか、意味がわからない点が多々ありますが、ここはもうEPSGの番号だけで追ってみました。
https://epsg.io/6612
PROJCS["NAD83(2011) / Wyoming East (ftUS)",
GEOGCS["NAD83(2011)",
DATUM["NAD83_National_Spatial_Reference_System_2011",
SPHEROID["GRS 1980",6378137,298.257222101],
TOWGS84[0,0,0,0,0,0,0]],
....
AUTHORITY["EPSG","6612"]]
一方の JGD2011。こちらは EPSG:1128。COORDINATEOPERATIONという見たことのないタイプであり、名前が "Cape to WGS 84"という、なぜこれがJGD2011から参照されているのか理解に苦しみます（ケープペンギンさんのいるケープのことですかね？）。意味不明だなと思いながら、とりあえずこの長い定義の中には towgs84 が含まれていない、ということを押さえておきます。
COORDINATEOPERATION["Cape to WGS 84 (1)",
VERSION["DMA-Zaf"],
SOURCECRS[
GEOGCRS["Cape",
DATUM["Cape",
ELLIPSOID["Clarke 1880 (Arc)",6378249.145,293.4663077,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
CS[ellipsoidal,2],
AXIS["geodetic latitude (Lat)",north,
ORDER[1],
ANGLEUNIT["degree",0.0174532925199433]],
AXIS["geodetic longitude (Lon)",east,
ORDER[2],
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4222]]],
.....
結論にならない結論
MySQL開発チームが scripts/mysql_system_tables_data.sql ファイルをどのようにして作成しているのかは、恐らく存在するであろう変換スクリプトを見ないと分からないのですが、EPSGの定義ではJGD2000と2011の間の違いらしい違いはDATUMのAUTHORITYくらいだなということを今回確認できました。
なお、QGISで JGD2000と JGD2011の定義をそれぞれ見てみると、どちらにも
Proj4 +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
が含まれています。QGISはMySQLとはまた別の変換ルールを持っているようですね。（TOWGS84定義がなければオールゼロで定義する、など）
MySQLのJGD2011にTOWGS84が追加される日を願って、今日のところはこれくらいで。
追記：Transformationを見るべきだ！
とーかさんが最新情報を調べて、ブログに整理してくれました！
色々書いてありますが、towgs84の話に絞って書くと、結論としては
「EPSG-CRSの定義だけでなく、EPSG-Transformationの定義も見るべきだ（そちらに書いてある）」ということです。
番号の紐付けは不明。一旦ぜんたいを見直したり検索したりして、別エントリにまとめるかもしれません（まとめないかもしれません）。
*1:手元のマシンに適用したいだけなら、自分で JGD2011の行にtowgs84を書き加えて、その行のクエリ(REPLACE文)を実行すればめでたしめでたしです
