TL;DR
MySQL 5.6とそれ以前のはなし。5.7とそれ以降はこの初期設定は入っていない。
昔のMySQLは test というスキーマを
mysql_install_db
で作ってしまって、しかもこのスキーマは全アカウントに対して(ストアド以外の)読み書き権限がある
…
TL;DR
NOT NULL にしようとすると出る
SHOW WARNINGS を拾ってエラーにしている
pt-online-schema-change
--null-to-not-null でいける
UPDATE t1 SET val = ? WHERE val IS NULL
でNULLを排除してからpt-online-schema-changeすればいいんじゃないかな
日々の覚書: INSERT IGNORE INTOがNOT NULL DEFAULTを裏切る の続き。
pt-oscは INSERT …
MySQL で max_allowed_packet
を超過した場合にどうなるんだっけ…と思って試してみた結果。
サーバーの max_allowed_packet をクエリが超過した場合
MySQL 5.6
サーバー起動
% docker run --name mysql56 -e MYSQL_ALLOW_EMPTY_PASSWORD=yes -d mysql:5.6 --max-allowed-packet=100000
クライアントは原因がわからないけど切断される
% ruby -e 'puts "set @a="+"1"*1000000' | docker exec -i mysql56 mysql ERROR 2006 (HY000) at line 1: MySQL server has gone away
サーバー側はログ出力なし
% docker logs mysql56 ...
MySQL 5.7
サーバー起動
% docker run --name mysql57 -e MYSQL_ALLOW_EMPTY_PASSWORD=yes -d mysql:5.7 --max-allowed-packet=100000
クライアントは原因がわからないけど切断される
% ruby -e 'puts "set @a="+"1"*1000000' | docker exec -i …[さらに読む]
とりあえず8.0.26で実験する。
INSERT IGNORE INTO
といえば、キー重複エラーを握りつぶして複数のINSERTを「先勝ち」であるかのように振る舞わせるのに使われることが多いやつ。
mysql80 10> CREATE TABLE t2 (pk int PRIMARY KEY);
Query OK, 0 rows affected (0.02 sec)
mysql80 10> INSERT INTO t2 VALUES (1);
Query OK, 1 row affected (0.01 sec)
mysql80 10> INSERT INTO t2 VALUES (1);
ERROR 1062 (23000): Duplicate entry '1' for key 't2.PRIMARY'
mysql80 10> INSERT IGNORE INTO t2 VALUES (1);
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql80 10> SELECT * FROM t2;
+----+
| pk |
+----+
| 1 |
+----+
1 row in set (0.00 sec)
あるいは、あたかも sql_mode= STRICT_TRANS_TABLES …
サクッと書けるネタだったので、久々に書きました。
リリースノートを読んでて気になった
MySQL8.0.26のリリースノートのServer Administrationの箇所にこうあった。
Setting the session value of the innodb_strict_mode system variable is now a restricted operation and the session user must have privileges sufficient to set restricted session variables. For information about the privileges required to set restricted session variables, see System Variable Privileges. (Bug #32944980)
なになに、「システム変数 innodb_strict_mode のセッション値を設定することは、（より）制限された操作に変更され、セッション …
[さらに読む]TL;DR
dict_sys
のmutexを取るのでDDL系は死ぬし新しくテーブルキャッシュを作れないのでテーブルキャッシュが枯渇すると死ぬ
ROLLBACK も dict_sys のmutexを取るので死ぬ。
COMMIT はできる。
dict_sys を使う処理が追加されるのでこっちはいきなりDMLが刺さる。
まず、「でかいテーブルをDROP」のためにでっかいテーブルを作るのも大変なので、単純に unlink …