日々の覚書: InnoDB FULLTEXT KEYがメモリを食う件(未解決) の続き。

何がメモリを使ってるのかを performance_schema.memory_summary_global_by_event_name テーブルで(できないだろうなと思いながら)観測してみる。

mysql80> RESTART;
$ sysbench --mysql-socket=/usr/mysql/8.0.45/data/mysql.sock --mysql-user=root oltp_read_write --table_size=1000000 --time=600 --report-interval=1 cleanup
$ sysbench --mysql-socket=/usr/mysql/8.0.45/data/mysql.sock --mysql-user=root oltp_read_write --table_size=1000000 --time=600 --report-interval=1 prepare
$ date ; sysbench --mysql-socket=/usr/mysql/8.0.45/data/mysql.sock --mysql-user=root oltp_write_only --table_size=1000000 --time=600 …

そもそもこの構文破壊されたCREATE TRIGGER文は、DELIMITERの変更とバージョン指定コメント構文が揃わないと起こらないので、おそらくmysqldumpで引っこ抜いたトリガー定義を間違っていじったりコピペし間違えた時くらいしか起こらない気がする。

が、一度この状態になるとそれ以降のmysqldumpで発火する。

How to repeat

• MySQL 5.7とそれ以前に対して以下を実行すると、CREATE TRIGGERは成功するけどSyntax Errorが返ってくる。

CREATE DATABASE d1;
CREATE TABLE d1.t1 (num INT);

DELIMITER ;;
/*!50003 CREATE TRIGGER d1.test BEFORE INSERT ON d1.t1 FOR EACH ROW INSERT INTO d1.t1 VALUES (1); */;;
DELIMITER ;

• こんな風に。

mysql57 5> CREATE DATABASE d1;
Query OK, 1 row affected (0.00 sec)

mysql57 5> CREATE TABLE d1.t1 (num INT);
Query OK, 0 …

前回 とは趣向を変えて、自力ビルドと公式ビルドの差を試す。

自力ビルドは大したオプションを与えずにコンパイルするだけ。

$ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/mysql ../mysql-9.7.0-er
$ make -j4
$ sudo make install
$ cd /usr/local/mysql

$ bin/mysqld --no-defaults --initialize-insecure --lower_case_table_names=1
$ bin/mysqld --no-defaults --lower_case_table_names=1 --innodb-dedicated-server=1 --log-error-verbosity=3 --innodb-monitor-enable=all --daemonize

前回と同じoltp_read_writeで比較。

$ sysbench --mysql-host=10.0.0.177 --mysql-user=sbtest oltp_read_write --table_size=1000000 --tables=10 --time=60 --report-interval=1 --threads=8 prepare

$ sysbench --mysql-host=10.0.0.177 --mysql-user=sbtest oltp_read_write --table_size=1000000 …

MySQL 9.7.0-erではPGO(Profile Guided Optimization)が有効になっているらしいので、それまでのバイナリよりもちょっと性能が良さそう。あと、これはビルドの中で有効にするので手でビルドしたものよりもちょっと性能が良いはず。

• MySQL コミュニティ版のEarly Access リリースビルド | mysql-jp

というわけで雑ベンチ。

$ cat /etc/os-release

NAME="Oracle Linux Server"

VERSION="8.10"

ID="ol"

ID_LIKE="fedora"

VARIANT="Server"

VARIANT_ID="server"

VERSION_ID="8.10"

PLATFORM_ID="platform:el8"

PRETTY_NAME="Oracle Linux Server 8.10"

ANSI_COLOR="0;31"

CPE_NAME="cpe:/o:oracle:linux:8:10:server"

HOME_URL="https://linux.oracle.com/"

BUG_REPORT_URL="https://github.com/oracle/oracle-linux"

ORACLE_BUGZILLA_PRODUCT="Oracle …

準備

$ sysbench --mysql-socket=/usr/mysql/8.0.45/data/mysql.sock --mysql-user=root oltp_common --table_size=1000000 prepare

mysql80 30> SELECT format_bytes(@@innodb_buffer_pool_size);
+-----------------------------------------+
| format_bytes(@@innodb_buffer_pool_size) |
+-----------------------------------------+
| 64.00 MiB                               |
+-----------------------------------------+
1 row in set (0.00 sec)

mysql80 30> SHOW ENGINE PERFORMANCE_SCHEMA STATUS;

..
| performance_schema | performance_schema.memory                                   | 240987688 |
+--------------------+-------------------------------------------------------------+-----------+
248 rows in set (0.00 sec)

$ ll -h /usr/mysql/8.0.45/data/sbtest/sbtest1.ibd
-rw-r-----. 1 yoku0825 yoku0825 248M Mar  9 06:03 /usr/mysql/8.0.45/data/sbtest/sbtest1.ibd

まずはそのままrun

$ date ; sysbench …

Perconaフォーラムで定期的に浮上する質問：Percona XtraDB Cluster (PXC)のすべてのノードにXtraBackupをインストールする必要がありますか？ これは混合環境を管理している場合や特定のノードのソフトウェアフットプリントを最小限に抑えようとする場合に特に妥当な質問です。実際の仕組みとテストが確認する内容を以下に示します。

簡潔な回答（ただし読み進めてください）

そのノードに何をさせたいかによります。 ここでのニュアンスがかなり重要なので、PXCにおけるState Snapshot Transfer (SST)の仕組みと、特定のノードにXtraBackupが存在する — または存在しない — ことがなぜ重要かを詳しく説明する価値があります。

PXCにおけるSSTの簡単なおさらい

新しいノードがPercona XtraDB …

TL;DR

• なんか見慣れない感じがするのは ALTER TABLE .. ADD INDEX .., ALGORITHM = INPLACE (Fast Index Creation)の時に起こるエラーだから
  • コード上は ALTER TABLE 以外にもHash Joinとかでも出るっぽい
    • https://github.com/search?q=repo%3Amysql%2Fmysql-server+ER_TEMP_FILE_WRITE_FAILURE&type=code
• innodb_tmpdir の容量が足りないと起こる
• なので他に容量があるなら innodb_tmpdir の場所を変えるか、 …

先日開催された日本MySQLユーザ会会(MyNA会) 2026年02月の発表では、MySQL 9.7 (LTS)ではEnterprise版でしか提供されていない機能がCommunity版にも入るかも！という話があった。
まだ確定情報ではないとのことで、9.7がリリースされるまで2ヶ月ほどは待つしかないが、話題に上がったOpenTeremetry機能がどれくらい使えそうか試してみた。

今回はMySQL Enterprise 8.4.8にcomponent_telemetryコンポーネントをインストールし、OpenTelemetry Collectorで収集、メトリクスはprometheus、traceはgrafana tempoで収集し、それぞれをData sourceにしてGrafanaでグラフにする構成とした。
OSはUbuntu 24.04。

構成図

This article was originally published in English at AnotherMySQLDBA.

この投稿では、MySQL 8.0 の JSON 関数のハンズオン解説を扱います。JSON サポートは MySQL 5.7 から存在しますが、8.0 では重要な改善が追加されました — より優れたインデックス戦略、新しい関数、マルチバリューインデックス — これにより JSON データの取り扱いが大幅に実用的になりました。以下の内容では、最も一般的に必要なパターンのいくつかを文書化し、EXPLAIN の出力と知っておくべきパフォーマンス観察を含めています。

これは「JSON vs. リレーショナル」の議論投稿ではありません。MySQL に JSON …

ことのおこり 地理情報機能（Spatial / GIS）に関心を持つMySQLユーザにとって、PostGISと比べての関数の少なさは最早深いコンプレックスと言っても良いものでしょう。実際に一つ一つ見てみると、そんなに使う関数ばかりでもないのですが、ここぞという時に「PostGISなら関数一発なんだけどな」と言われるシーンも少なくないので、やはり関数が充実しているのは利用者体験に大きく寄与しているのは間違いありません。 そんな思いから、昨年末にお試しでひとつ、MySQLへ新たなSpatial関数を追加してコントリビュートを出してみました。bugs.mysql.com 当初よりバージョンリリースの…