MySQL 5.7.6から入ったgenerated column、STOREDで作るとデータ領域に計算後の結果が格納されてインデックスも貼れるようになるというシロモノだったのが、5.7.8ではVIRTUALで作るとデータ領域には計算後の結果が格納されないけど *インデックスは計算後の値を使って貼れるようになった* 

日々の覚書: MySQL 5.7.6のgenerated columnは関数インデックスの夢を見るか

InnoDB: InnoDB now supports secondary indexes on virtual generated columns. A secondary index on a virtual generated column stores the column's generated values within the records of the index. Such indexes can be scanned and searched more efficiently than virtual generated columns, which are computed “on the fly” when rows are read.
…

TL;DR

MySQL 5.7.8には、mysqlpumpなるmysqldumpの後継バックアップクライアントが同梱されている。インデックスの遅延ロードや進捗の出力、パラレルでのダンプなど魅力的な拡張機能が入っている。

ただし、mysqlpumpの方は「全テーブルがInnoDB」「master_info_repository= TABLE」「relay_log_info_repository= TABLE」「gtid_mode= ONの場合にはMySQL 5.7.5以降であること(OFFの場合はこの制約は入らない)」「パラレルでバックアップする場合は更新を自分で止めておかなくてはならない」であることを前提に作られているため、それを満たさない場合は  …

TL;DR

MySQL 5.7.8には、mysqlpumpなるmysqldumpの後継バックアップクライアントが同梱されている。インデックスの遅延ロードや進捗の出力、パラレルでのダンプなど魅力的な拡張機能が入っている。

ただし、mysqlpumpの方は「全テーブルがInnoDB」「master_info_repository= TABLE」「relay_log_info_repository= TABLE」「gtid_mode= ONの場合にはMySQL 5.7.5以降であること(OFFの場合はこの制約は入らない)」「パラレルでバックアップする場合は更新を自分で止めておかなくてはならない」であることを前提に作られているため、それを満たさない場合は  …

STRICT_TRANS_TABLESが暗黙のデフォルトになったことが俺の中で有名なMySQL 5.7ですが、MySQL 5.7.8でまたちょっと変更になるらしい。

MySQL :: MySQL 5.7 Reference Manual :: 5.1.7 Server SQL Modes


5.7.4から5.7.7の間までは、STRICT_{TRANS|ALL}_TABLESは "5.6までのSTRICT_{TRANS|ALL}_TABLES" + "ERROR_FOR_DIVISION_BY_ZERO" + "NO_ZERO_DATE" + "NO_ZERO_IN_DATE" でした。
これが5.7.8からもとに戻ります。STRICT_TRANS_TABLESは5.6までのSTRICT_TRANS_TABLESと同じ効果を持つようになり、同時に暗黙のデフォルトにERROR_FOR_DIVISION_BY_ZERO
, NO_ZERO_DATE, NO_ZERO_IN_DATEが追加されて、動作としては5.7.7までと同じです。


…

昨日の 日々の覚書: MySQL 5.7では迂闊にperformance_schemaをOFFするとSHOW STATUSが使えない の派生バージョン。

MySQL 5.7.8以降、show_compatibility_56= 0が暗黙のデフォルトになり、SHOW VARIABLESとかはinformation_schemaではなくperformance_schemaを見に行くようになる。performance_schema.*_variablesテーブルにSELECT権限がないとSHOW VARIABLESは転ける。

さて…レプリケーションスレーブを作ろうと思った時、どんな権限を持ったユーザーを作るか。
俺ならこうだ。

mysql> CREATE USER replicator;
Query OK, 0 rows affected (0.07 …

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

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

…

動作は5.7.7で確認していて、 5.7.8で暗黙のデフォルトがOFFになるって書いてある のでやってみた。

MySQL 5.7.6から show_compatibility_56 というサーバー変数が追加されている。

SHOW {GLOBAL|SESSION} STATUS, SHOW {GLOBAL|SESSION} VARIABLES は今まで内部的にinformation_schemaのテーブルを叩いていた。これをperformance_schemaのテーブルを叩くように変えるのがこのパラメーター。

ONだとinformation_schemaから、OFFだとperformance_schemaから情報を取ってくる。

mysql57> SELECT @@version;
+--------------+
| …

MySQLのmysqlbinlogコマンドでは、MySQL5.6からリモートにあるバイナリーログを読み取る事が可能になりましたが、SSLを利用した通信の暗号化はサポートされておりませんでした。

次期メジャーバージョンのMySQL5.7では、ここら辺も機能拡張されておりmysqlbinlogコマンドを利用して、リモートのバイナリーログを読み込み場合にもSSLを利用した通信の暗号化を行う事が出来るようになりました。
Firewall、セキュリティ機器、セグメント分割された環境で、何処まで必要になるかは状況次第ですが、
リモートサーバーが自然災害対策の為に、自分でインフラを準備する必要が無いPublicクラウド上にある場合などに通信の暗号化が出来ると安心ですね。
…

TL;DR

kamipo traditionalですら完全に防ぎきれないアレがあるので、そこを気にするなら出来る限りさっさとMyISAMからInnoDBに引っ越しましょう。


これらの記事を読んだ人向けです。

ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々

Javaでkamipo traditionalを有効にする - その手の平は尻もつかめるさ

アプリでミスって不正なデータが入るくらいだった500になったほうがマシ。というのが個人的な考えです。
+激しく同意+


さて、激しく同意したところで、kamipo …

innodb_stats_on_metadata=1でディスク容量激増とCPU負荷が発生 | DEVLAB を読んだ誰か（忘れた）に「innodb_stats_on_metadata= 0だと統計情報ズレない？ 手でANALYZE TABLEしないといけないの？」って聞かれて答えたメモ（だと思う）

そもそも8ページとか20ページじゃ全然足りないじゃんというのはここでいう「問題なく」の中には含まれない。

innodb_stats_on_metadataは *メタデータにアクセス(=information_schema, SHOW TABLE STATUSなど)* した時に統計情報を再作成するかどうかのフラグで、データが大量に更新された時の統計情報の再作成は ここらへん …