この記事は MySQL闇歴史のカレンダー | Advent Calendar 2022 の2枚目の14日目の記事です。TL;DR

• MySQL 5.6のGA(5.6.10)直後にあったmysqlコマンドラインクライアントのバグの話
  • MySQL Bugs: #68107: mysql client with --default-character-set=ujis crashes が全てだし
  • 日々の覚書: MySQL 5.6.9のmysqlクライアントがujis, sjis, cp932で落ちる(5.6.12で修正) の思い出し

知名度：★☆☆☆☆
(俺の心の)闇度　：★★★★☆
…

TL;DR

• MySQL 5.6とそれ以前のはなし。5.7とそれ以降はこの初期設定は入っていない。

  • MySQL 5.6でもインストール方法によっては存在しないし mysql_secure_installation を使った場合はこの設定は消されるし、MySQL 5.7とそれ以降だろうと5.6からインプレースアップグレードやmysqlスキーマまで含めたフルリストアでアップグレードした場合は設定は残っているだろう

• 昔のMySQLは test というスキーマを mysql_install_db で作ってしまって、しかもこのスキーマは全アカウントに対して(ストアド以外の)読み書き権限がある

  • …

TL;DR

この CREATE TABLE ステートメントは転ける。

mysql57> CREATE TABLE t1 (num INT UNSIGNED NOT NULL, dt DATETIME(3) DEFAULT CURRENT_TIMESTAMP);
ERROR 1067 (42000): Invalid default value for 'dt'

CURRENT_TIMESTAMP関数 が DATETIME(0)型 を返すので、dtカラムの型である DATETIME(3)型 と合わないからだというわけで、

mysql57> CREATE TABLE t1 (num INT UNSIGNED NOT NULL, dt DATETIME(3) DEFAULT CURRENT_TIMESTAMP(3));
Query OK, 0 rows affected (0.01 sec)

mysql57> SHOW CREATE TABLE t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `num` int(10) unsigned NOT NULL,
  `dt` datetime(3) DEFAULT …

日々の覚書: MySQL 5.7のmysql_upgradeは本当にDATETIME型を新しいフォーマットに直してくれるけれど でちょっと触れてるんだけど、DATETIME型（TIME型とTIMESTAMP型もあるけど）には現在2つのフォーマットが合って、

- 5.5とそれ以前のDATETIME型（秒部の小数点数非対応、8バイト、以下 旧DATETIME型）
- 5.6とそれ以降のDATETIME型（秒部の小数点数対応、小数部無しの場合は5バイト、以下DATETIME2型）

で、MySQL 5.7のmysql_upgradeは旧DATETIME型をDATETIME2型にアップグレードしてくれるよ、こいつらはレプリケーションで混ぜるとよろしくないから、これで安心だね、みたいなのが …

Upgrading Directly from MySQL 5.0 to 5.7 using an ‘In Place’ Upgrade | MySQL Server Blog を読んでふと思い立ったので。

MySQL 5.7のmysql_upgradeは古いDATETIME, TIME, TIMESTAMPを新しいDATETIME2, TIME2, TIMESTAMP2に変換してくれるからmysqldumpしてからリストアしなくてもいいんだぜ！ っていうのが趣旨らしい。それは素敵だ。

↓これの12番目
日々の覚書: あなたのMySQL 5.6トレンド力をチェックする15の質問


ざっと見、確かにやってくれてる。worldデータベースを ダウンロード …

MySQL 5.7で標準バンドルされるsysスキーマ。その実態はperformance_schemaやinformation_schemaから「それっぽい」情報を集めているview。

5.7の機能っぽく語られるけど、前身は ps_helper でMySQL 5.5から使える（けど、5.5のperformance_schemaは情報が少なすぎて役に立つ気配がしない。オーバーヘッドもでかいし）

* MySQL 5.7ではperformance_schemaもだいぶオーバーヘッド落ち着いてきたみたいだし、デフォルトのまま取り敢えず有効にしておいた方がいい。ウチはMySQL 5.6から有効にしてる。
* CPUバウンドの場合確かにオーバーヘッドが見えるけど、I/Oネックになる場合は全然気にならない程度のオーバーヘッドだから、自信がある時だけOFFにする方がいいと思う。 …

オンラインで色々なDDL処理が出来るのは、サービス提供側も、利用者も、DBAとしても
非常に便利な機能かと思います。MySQLは4.1からUnicode対応していたので、
10年弱程利用してますが、Online DDLが利用可能になるまでは、
夜中のユーザーが少ない時間にテーブル定義を変更していたりする事も多々ありました。
MySQL5.6以降のオンラインDDLはそういったメンテナンス対応の方には、非常に便利で有難い機能かと思います。

オンライン処理可能かどうかは、14.11.1. オンライン DDL の概要で確認する事が出来ます。
手元で簡単に確認したい場合は、以下のオプションで処理を指定して確認する事が可能です。

…

漢(オトコ)のコンピュータ道: なぜMySQLのサブクエリは遅いのか。

この記事は 2009/3/25 に書かれたもののようである。
2009年3月といえばMySQL 5.1がGAになってわずか半年、MySQL 6.0.10-alphaがリリースされた頃で、MariaDBもまだ姿を見せていない頃だ。


時は流れて2015年、MySQL 5.6がGAになって早2年半、5.7のGAﾏﾀﾞｧ-? (･∀･ )っ/凵⌒☆ﾁﾝﾁﾝ

な頃なので、もういい加減誰か言ってくれてもいいんじゃないかと思う。


もうMySQL(5.6)は不要にINをEXISTSに書き換えたりしないんだよって

mysql51> EXPLAIN SELECT * FROM Country WHERE Continent = 'Asia' AND Code IN
    -> (SELECT CountryCode FROM City WHERE Population …

メリークリスマス！！やあ、良い子のみんな！！サンタクロース・・・ではなく、ヒゲモジャギークからのクリスマスプレゼントだよ！！

というわけで、MySQL Casual Advent Calendarの25日目である。今朝Advent Calendarを覗いてみると、本日分のエントリーが無かったので、急遽書くことにした。Advent Calendar最後の日、クリスマスを飾る記事のテーマはGTIDだ。

前回の投稿では、MySQL 5.6の目玉機能として、レプリケーションがクラッシュセーフになったことを挙げた。レプリケーションまわりで言えば、もうひとつ外せない目玉機能がある。それがGTID（Global Transaction ID）である。

GTIDは良くも悪くもレプリケーションの運用を変化させる。GTIDを使うことによって得られる最大のメリットは、CHANGE MASTER TOで