GA

2023/03/16

WinDbgでMySQL on Windowsのミニダンプの中身を見てみる


datadirに吐かれたミニダンプをドラッグアンドドロップで食わせる。
なおデバッグシンボルは入れてない。

gdbでいう info threads みたいなことをしたい時は ~
thread apply all bt 相当のことがやりたいけどやり方はわからない。

bt 相当のものは kb っぽいんだけど何か足りない。

For analysis of this file, run !analyze -v なる表示が先頭の方にあったので、 !analyze -v を実行してみる。

と、見慣れた(?)いつものスタックトレースが出てきた。

将来の自分にメモ書きとして。

2023/03/11

MySQL 8.0ならGTIDのスキップはもっと簡単になる

TL;DR


とはいえそもそもSQL Threadが止まってイベントをスキップしなければならないような事態になったら、レプリカを真っ新に作り直した方が良いというのは相変わらず思っている。
MySQL 8.0ならCloneプラグインもあるしね。

slave1 [localhost] {msandbox} ((none)) > SHOW REPLICA STATUS\G
*************************** 1. row ***************************
             Replica_IO_State: Waiting for source to send event
                  Source_Host: 127.0.0.1
                  Source_User: rsandbox
                  Source_Port: 25440
                Connect_Retry: 60
              Source_Log_File: mysql-bin.000002
          Read_Source_Log_Pos: 586561
               Relay_Log_File: mysql-relay.000002
                Relay_Log_Pos: 315878
        Relay_Source_Log_File: mysql-bin.000002
           Replica_IO_Running: Yes
          Replica_SQL_Running: No
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 1396
                   Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction '00025440-1111-1111-1111-111111111111:758' at master log mysql-bin.000002, end_log_pos 315888. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
                 Skip_Counter: 0
          Exec_Source_Log_Pos: 315662
              Relay_Log_Space: 586983
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Source_SSL_Allowed: No
           Source_SSL_CA_File:
           Source_SSL_CA_Path:
              Source_SSL_Cert:
            Source_SSL_Cipher:
               Source_SSL_Key:
        Seconds_Behind_Source: NULL
Source_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 1396
               Last_SQL_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction '00025440-1111-1111-1111-111111111111:758' at master log mysql-bin.000002, end_log_pos 315888. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
  Replicate_Ignore_Server_Ids:
             Source_Server_Id: 1
                  Source_UUID: 00025440-1111-1111-1111-111111111111
             Source_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
    Replica_SQL_Running_State:
           Source_Retry_Count: 86400
                  Source_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp: 230311 12:03:58
               Source_SSL_Crl:
           Source_SSL_Crlpath:
           Retrieved_Gtid_Set: 00025440-1111-1111-1111-111111111111:1-1406
            Executed_Gtid_Set: 00025440-1111-1111-1111-111111111111:1-757
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name:
           Source_TLS_Version:
       Source_public_key_path:
        Get_Source_public_key: 0
            Network_Namespace:
1 row in set (0.00 sec)

たとえばこんなの。
00025440-1111-1111-1111-111111111111:758 のイベントが「本当にスキップしてよいものなのかどうか」をよく確認した上でスキップするには、

ドキュメントにも紹介されている手順

SET SESSION gtid_next = '00025440-1111-1111-1111-111111111111:758';
COMMIT;
SET SESSION gtid_next = AUTOMATIC;
START REPLICA sql_thread;

gitd_purgedで直接いじる手順

SET GLOBAL gtid_purged = '+00025440-1111-1111-1111-111111111111:758';
START REPLICA sql_thread;

複数のgtidを一気に飛ばさないといけない場合はきっと後者の方が楽(ただ複数のgtidを本当に飛ばして良いのかなんて調べるのが大変なので、やっぱりCLONEなりなんなりで作り直した方が良いと思うの)

2023/03/03

Foeign Key制約によって暗黙に作成されたINDEX or NOT

TL;DR


(num, val) を持ったテーブルが2つ、numはどちらでもPKE、valはt1でだけUNIQUE KEY。

mysql80 46> SHOW CREATE TABLE t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `num` bigint unsigned NOT NULL AUTO_INCREMENT,
  `val` varchar(32) DEFAULT NULL,
  UNIQUE KEY `num` (`num`),
  UNIQUE KEY `val` (`val`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.00 sec)

mysql80 46> SHOW CREATE TABLE t2\G
*************************** 1. row ***************************
       Table: t2
Create Table: CREATE TABLE `t2` (
  `num` bigint unsigned NOT NULL AUTO_INCREMENT,
  `val` varchar(32) DEFAULT NULL,
  UNIQUE KEY `num` (`num`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.01 sec)

ここでt2にADD FOREIGN KEYすると

mysql80 46> ALTER TABLE t2 ADD FOREIGN KEY (val) REFERENCES t1 (val);
Query OK, 0 rows affected (0.03 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql80 46> SHOW CREATE TABLE t2\G
*************************** 1. row ***************************
       Table: t2
Create Table: CREATE TABLE `t2` (
  `num` bigint unsigned NOT NULL AUTO_INCREMENT,
  `val` varchar(32) DEFAULT NULL,
  UNIQUE KEY `num` (`num`),
  KEY `val` (`val`),
  CONSTRAINT `t2_ibfk_1` FOREIGN KEY (`val`) REFERENCES `t1` (`val`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.00 sec)

KEY val(val) が勝手に追加される。これがFKによって暗黙に作成されたINDEX。

この暗黙のインデックス、「それを左端プレフィックスに持つインデックスが作られると勝手に消える」という性質を持っているらしい。

mysql80 46> ALTER TABLE t2 ADD KEY idx_text(val, num);
Query OK, 0 rows affected (0.01 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql80 46> SHOW CREATE TABLE t2\G
*************************** 1. row ***************************
       Table: t2
Create Table: CREATE TABLE `t2` (
  `num` bigint unsigned NOT NULL AUTO_INCREMENT,
  `val` varchar(32) DEFAULT NULL,
  UNIQUE KEY `num` (`num`),
  KEY `idx_text` (`val`,`num`),
  CONSTRAINT `t2_ibfk_1` FOREIGN KEY (`val`) REFERENCES `t1` (`val`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.00 sec)

最初からインデックス付きで作ったテーブルにFOREIGN KEYを足した場合はこれは起こらない。

mysql80 46> CREATE TABLE t3 (num serial, val varchar(32), KEY(val));
Query OK, 0 rows affected (0.02 sec)

mysql80 46> SHOW CREATE TABLE t3\G
*************************** 1. row ***************************
       Table: t3
Create Table: CREATE TABLE `t3` (
  `num` bigint unsigned NOT NULL AUTO_INCREMENT,
  `val` varchar(32) DEFAULT NULL,
  UNIQUE KEY `num` (`num`),
  KEY `val` (`val`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.00 sec)

mysql80 46> ALTER TABLE t3 ADD FOREIGN KEY (val) REFERENCES t1 (val);
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql80 46> SHOW CREATE TABLE t3\G
*************************** 1. row ***************************
       Table: t3
Create Table: CREATE TABLE `t3` (
  `num` bigint unsigned NOT NULL AUTO_INCREMENT,
  `val` varchar(32) DEFAULT NULL,
  UNIQUE KEY `num` (`num`),
  KEY `val` (`val`),
  CONSTRAINT `t3_ibfk_1` FOREIGN KEY (`val`) REFERENCES `t1` (`val`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.00 sec)

mysql80 46> ALTER TABLE t3 ADD KEY idx_text(val, num);
Query OK, 0 rows affected (0.01 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql80 46> SHOW CREATE TABLE t3\G
*************************** 1. row ***************************
       Table: t3
Create Table: CREATE TABLE `t3` (
  `num` bigint unsigned NOT NULL AUTO_INCREMENT,
  `val` varchar(32) DEFAULT NULL,
  UNIQUE KEY `num` (`num`),
  KEY `val` (`val`),
  KEY `idx_text` (`val`,`num`),
  CONSTRAINT `t3_ibfk_1` FOREIGN KEY (`val`) REFERENCES `t1` (`val`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
1 row in set (0.00 sec)

この区別がつかないかなと思ってたら、ギリギリibd2sdiで読めそうだった。
t2を暗黙のインデックス、t3を明示のインデックスにして

mysql80 46> DROP TABLE t2, t3;
Query OK, 0 rows affected (0.01 sec)

mysql80 46> CREATE TABLE t2 (num serial, val varchar(32));
Query OK, 0 rows affected (0.01 sec)

mysql80 46> CREATE TABLE t3 (num serial, val varchar(32), KEY(val));
Query OK, 0 rows affected (0.02 sec)

mysql80 46> ALTER TABLE t2 ADD FOREIGN KEY (val) REFERENCES t1 (val);
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql80 46> ALTER TABLE t3 ADD FOREIGN KEY (val) REFERENCES t1 (val);
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

ibd2sdiでかじる。

$ ibd2sdi d2/t2.ibd | jq '.[1].object.dd_object.indexes[] | {"name": .name, "is_generated": .is_generated}'
{
  "name": "num",
  "is_generated": false
}
{
  "name": "val",
  "is_generated": true
}

$ ibd2sdi d2/t3.ibd | jq '.[1].object.dd_object.indexes[] | {"name": .name, "is_generated": .is_generated}'
{
  "name": "num",
  "is_generated": false
}
{
  "name": "val",
  "is_generated": false
}

この is_generated がそうっぽい。
これデータディクショナリ周りで追加されてるっぽくて、5.7で調べる方法はわからなかった。どうやって5.7は勝手に消してるんだろう。


(ちなみに information_schema.statistics からは読めない)

mysql80 46> SELECT * FROM information_schema.statistics WHERE table_schema = DATABASE();
+---------------+--------------+------------+------------+--------------+------------+--------------+-------------+-----------+-------------+----------+--------+----------+------------+---------+---------------+------------+------------+
| TABLE_CATALOG | TABLE_SCHEMA | TABLE_NAME | NON_UNIQUE | INDEX_SCHEMA | INDEX_NAME | SEQ_IN_INDEX | COLUMN_NAME | COLLATION | CARDINALITY | SUB_PART | PACKED | NULLABLE | INDEX_TYPE | COMMENT | INDEX_COMMENT | IS_VISIBLE | EXPRESSION |
+---------------+--------------+------------+------------+--------------+------------+--------------+-------------+-----------+-------------+----------+--------+----------+------------+---------+---------------+------------+------------+
| def           | d2           | t1         |          0 | d2           | num        |            1 | num         | A         |           0 |     NULL |   NULL |          | BTREE      |         |               | YES        | NULL       |
| def           | d2           | t1         |          0 | d2           | val        |            1 | val         | A         |           0 |     NULL |   NULL | YES      | BTREE      |         |               | YES        | NULL       |
| def           | d2           | t2         |          0 | d2           | num        |            1 | num         | A         |           0 |     NULL |   NULL |          | BTREE      |         |               | YES        | NULL       |
| def           | d2           | t2         |          1 | d2           | val        |            1 | val         | A         |           0 |     NULL |   NULL | YES      | BTREE      |         |               | YES        | NULL       |
| def           | d2           | t3         |          0 | d2           | num        |            1 | num         | A         |           0 |     NULL |   NULL |          | BTREE      |         |               | YES        | NULL       |
| def           | d2           | t3         |          1 | d2           | val        |            1 | val         | A         |           0 |     NULL |   NULL | YES      | BTREE      |         |               | YES        | NULL       |
+---------------+--------------+------------+------------+--------------+------------+--------------+-------------+-----------+-------------+----------+--------+----------+------------+---------+---------------+------------+------------+
6 rows in set (0.00 sec)

(デバッグビルドを使えばデータディクショナリでも確認できそう)

mysql80 8> SELECT @@version;
+--------------+
| @@version    |
+--------------+
| 8.0.32-debug |
+--------------+
1 row in set (0.00 sec)

mysql80 8> SET SESSION debug='+d,skip_dd_table_access_check';
Query OK, 0 rows affected (0.00 sec)

mysql80 8> SELECT schemata.name, tables.name, indexes.name, indexes.options, indexes.se_private_data, indexes.is_generated, indexes.is_visible, indexes.hidden FROM indexes JOIN tables ON indexes.table_id = tables.id JOIN schemata ON tables.schema_id = schemata.id WHERE schemata.name = 'd2';
+------+------+------+----------+------------------------------------------------------+--------------+------------+--------+
| name | name | name | options  | se_private_data                                      | is_generated | is_visible | hidden |
+------+------+------+----------+------------------------------------------------------+--------------+------------+--------+
| d2   | t1   | num  | flags=0; | id=172;root=4;space_id=20;table_id=1081;trx_id=3348; |            0 |          1 |      0 |
| d2   | t1   | val  | flags=0; | id=174;root=5;space_id=20;table_id=1081;trx_id=3366; |            0 |          1 |      0 |
| d2   | t2   | num  | flags=0; | id=191;root=4;space_id=29;table_id=1090;trx_id=3553; |            0 |          1 |      0 |
| d2   | t2   | val  | flags=0; | id=192;root=5;space_id=29;table_id=1090;trx_id=3553; |            1 |          1 |      0 |
| d2   | t3   | num  | flags=0; | id=193;root=4;space_id=30;table_id=1091;trx_id=3583; |            0 |          1 |      0 |
| d2   | t3   | val  | flags=0; | id=194;root=5;space_id=30;table_id=1091;trx_id=3583; |            0 |          1 |      0 |
+------+------+------+----------+------------------------------------------------------+--------------+------------+--------+
6 rows in set (0.00 sec)

2023/02/20

テンポラリーテーブルがストレージを埋め尽くした時のエラー番号の違い on MySQL 8.0.32

TL;DR

  • TempTableストレージエンジンがDisk落ちした時とInnoDB Temporary tableで「同じストレージあふれ」でも微妙にエラー内容が違う

    • 前者は ERROR 14 (HY000): Can't change size of file (OS errno 28 - No space left on device) , エラーログ出力なし

    • 後者は ERROR 1114 (HY000): The table '#sqlXXXXX' is full でエラーログ出力もあり

    • ちなみにMyISAMは ERROR 126 (HY000): Incorrect key file for table '/mytmp/#sqlXXXXX.MYI'; try to repair it 、これ少なくとも5.7からは変わってない


実験用に100MBくらいのファイルにxfsを作ってマウントする。


$ dd if=/dev/zero of=./mytmp bs=1M count=100

$ mkfs -t xfs ./mytmp

$ sudo mkdir /mytmp
$ sudo mount /home/yoku0825/mytmp /mytmp

$ sudo chown -R yoku0825. /mytmp   ### mysqldをyoku0825ユーザーで動かすので
$ mkdir /mytmp/innodb_temp   ### innodb_temp_tablespaces_dirはあらかじめディレクトリがないと転ける

my.cnfで tmpdir (MyISAM, TempTableストレージエンジンが使う)とinnodb_temp_tablespaces_dir/mytmp を割り当てて再起動。

$ vim /etc/my.cnf
[mysqld]
tmpdir= /mytmp
innodb_temp_tablespaces_dir=/mytmp/innodb_temp  ### このディレクトリは自動で作ってくれないので、自分でmkdirしないと起動が転ける

さっさと溢れさせたいのでダミーデータを入れて少しでもテンポラリー領域を使ったらあふれるようにセット。

$ dd if=/dev/zero of=/mytmp/dummy bs=1M count=90   ### さっさと溢れさせたいのでさらにダミー

$ df -h /mytmp
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0       97M   96M  676K 100% /mytmp

$ du -sh /mytmp/*
90M     /mytmp/dummy
800K    /mytmp/innodb_temp

実験1、TempTable on Disk。Diskに落とすために temptable_max_ram を小さくする。

mysql80 8> SHOW VARIABLES LIKE '%temp%';
+-----------------------------+-----------------------+
| Variable_name               | Value                 |
+-----------------------------+-----------------------+
| avoid_temporal_upgrade      | OFF                   |
| innodb_temp_data_file_path  | ibtmp1:12M:autoextend |
| innodb_temp_tablespaces_dir | /mytmp/innodb_temp    |
| show_old_temporals          | OFF                   |
| temptable_max_mmap          | 1073741824            |
| temptable_max_ram           | 1073741824            |
| temptable_use_mmap          | ON                    |
+-----------------------------+-----------------------+
7 rows in set (0.01 sec)

mysql80 8> SHOW VARIABLES LIKE '%tmp%';
+---------------------------------+-----------+
| Variable_name                   | Value     |
+---------------------------------+-----------+
| default_tmp_storage_engine      | InnoDB    |
| innodb_tmpdir                   |           |
| internal_tmp_mem_storage_engine | TempTable |
| replica_load_tmpdir             | /mytmp    |
| slave_load_tmpdir               | /mytmp    |
| tmp_table_size                  | 16777216  |
| tmpdir                          | /mytmp    |
+---------------------------------+-----------+
7 rows in set (0.01 sec)

mysql80 9> SET GLOBAL temptable_max_ram = 2 * 1024 * 1024;
Query OK, 0 rows affected (0.01 sec)

mysql80 9> SELECT @@temptable_max_ram, @@tmp_table_size;  -- tmp_table_sizeの方が小さいとInnoDBに落ちてしまう
+---------------------+------------------+
| @@temptable_max_ram | @@tmp_table_size |
+---------------------+------------------+
|             2097152 |         16777216 |
+---------------------+------------------+
1 row in set (0.00 sec)

TempTableストレージエンジンはユーザー定義テンポラリーテーブル ( CREATE TEMPORARY TABLE ) としては使えないので、 WITH RECURSIVE (必ずテンポラリーテーブルを作る) で代用。

mysql80 9> SET SESSION cte_max_recursion_depth = 10000000;
Query OK, 0 rows affected (0.00 sec)

mysql80 9> WITH RECURSIVE v AS (SELECT 1 AS n UNION ALL SELECT n + 1 FROM v WHERE n <= 1999999), v2 AS (SELECT n, MD5(n) AS m FROM v) SELECT n, m, md5(m) AS o FROM v2 ORDER BY RAND() LIMIT 1;
ERROR 14 (HY000): Can't change size of file (OS errno 28 - No space left on device)

### エラーログには出力なし

実験2、InnoDB Temporary。暗黙の一時テーブル( SELECT がバックグラウンドで作るやつ ) も ユーザー定義テンポラリーテーブル ( CREATE TEMPORARY TABLE ) もどちらも同じ .ibt ファイルを使う。

はずなんだけど、なんかエラーが違った。

### 暗黙のテンポラリーテーブル版
mysql80 7> SET SESSION tmp_table_size = 1024;
Query OK, 0 rows affected (0.00 sec)

mysql80 7> SELECT @@temptable_max_ram, @@tmp_table_size;  -- tmp_table_sizeを超えるとTempTableからInnoDBに落ちる
+---------------------+------------------+
| @@temptable_max_ram | @@tmp_table_size |
+---------------------+------------------+
|             2097152 |             1024 |
+---------------------+------------------+
1 row in set (0.00 sec)

mysql80 7> WITH RECURSIVE v AS (SELECT 1 AS n UNION ALL SELECT n + 1 FROM v WHERE n <= 1999999), v2 AS (SELECT n, MD5(n) AS m FROM v) SELECT n, m, md5(m) AS o FROM v2 ORDER BY RAND() LIMIT 1;
ERROR 1146 (42S02): Table './mytmp/#sql45cf_8_0' doesn't exist

### doesn't existって言われた…
### エラーログには出力なし

↑ちなみにdummyファイルを消して、一度実行してからもう一度dummyファイルを作って、もっかいクエリすると↓と同じ table is full になった。テンポラリーテーブルを作る前の下処理っぽいところで失敗してストレージエンジンまで落ちてなかったっぽい。


2023-02-20T14:48:05.879945+09:00 9 [Warning] [MY-012145] [InnoDB] Error while writing 1048576 zeroes to /mytmp/innodb_temp/temp_10.ibt starting at offset 10485760

2023-02-20T14:48:05.880278+09:00 9 [ERROR] [MY-013132] [Server] The table '/mytmp/#sql54e5_9_3' is full!     <--- ここがibtファイルのパスじゃなくて tmpdir/内部名 になるの罠い



### ユーザー定義テンポラリーテーブル版
mysql80 8> CREATE TEMPORARY TABLE d1.tt1 (num int, val varchar(32)) Engine = InnoDB;
Query OK, 0 rows affected (0.00 sec)

mysql80 8> LOAD DATA INFILE '/home/yoku0825/md5' INTO TABLE d1.tt1;
ERROR 1114 (HY000): The table 'tt1' is full

### エラーログ
2023-02-20T14:32:23.733251+09:00 8 [ERROR] [MY-012144] [InnoDB] posix_fallocate(): Failed to preallocate data for file /mytmp/innodb_temp/temp_9.ibt, desired size 425984 bytes. Operating system error number 28. Check that the disk is not full or a disk quota exceeded. Make sure the file system supports this function. Refer to your operating system documentation for operating system error code information.
2023-02-20T14:32:23.733494+09:00 8 [Warning] [MY-012638] [InnoDB] Retry attempts for writing partial data failed.
2023-02-20T14:32:23.733538+09:00 8 [ERROR] [MY-012639] [InnoDB] Write to file /mytmp/innodb_temp/temp_9.ibt failed at offset 622592, 425984 bytes should have been written, only 0 were written. Operating system error number 28. Check that your OS and file system support files of this size. Check also that the disk is not full or a disk quota exceeded.
2023-02-20T14:32:23.733572+09:00 8 [ERROR] [MY-012640] [InnoDB] Error number 28 means 'No space left on device'
2023-02-20T14:32:23.733589+09:00 8 [Note] [MY-012641] [InnoDB] Refer to your operating system documentation for operating system error code information.
2023-02-20T14:32:23.733603+09:00 8 [Warning] [MY-012145] [InnoDB] Error while writing 425984 zeroes to /mytmp/innodb_temp/temp_9.ibt starting at offset 622592
..
2023-02-20T14:32:28.431025+09:00 8 [ERROR] [MY-013132] [Server] The table 'tt1' is full!

実験3、MyISAM版 (8.0.32では既に internal_tmp_disk_storage_engine が選べないから単に実験)

mysql80 9> CREATE TEMPORARY TABLE d1.tt1 (num int, val varchar(32)) Engine = MyISAM;
Query OK, 0 rows affected (0.00 sec)

mysql80 9> LOAD DATA INFILE '/home/yoku0825/md5' INTO TABLE d1.tt1;
ERROR 126 (HY000): Incorrect key file for table '/mytmp/#sql45cf_9_0.MYI'; try to repair it

### エラーログ
2023-02-20T14:36:08.272683+09:00 9 [ERROR] [MY-013134] [Server] Incorrect key file for table '/mytmp/#sql45cf_9_0.MYI'; try to repair it
2023-02-20T14:36:08.272746+09:00 9 [ERROR] [MY-010239] [Server] Got an error from unknown thread, /home/yoku0825/mysql-8.0.32/storage/myisam/mi_write.cc:194

見慣れたやつが出てきた。