MySQL 8.0 の InnoDB の log_sys周り の話
思い出せるうちに思い出せる範囲で… 例によって世に出る頃には全く違うことに取り組んでいるので、忙しくしてると何も書かずに終わってしまうのですが、こんなご時世、年末年始休暇があっても何も用事がなく折角なのですこし書き残します。本来は本家開発者のブログで英語で書くべきなんですが、込み入った話を英語で書く労力をかけるくらいなら次の問題解決にかけたほうがいいので、とりあえず日本語で書き残します… 私がMySQL界を離れている間にリリースされた8.0になってlog_sysのデザインが新しくなり、スケールが良くなったのですが、既存のハードを利用する大半のユーザーには、未だ荒かった実装のせいでデメリットの方が大きかったと思います。2019末くらいには悪い挙動と原因はある程度分かっていましたが、修正リリースは2020後半になってしまいました。 既存のスペックのハードウェアと、CPUコア多数搭載の最新ハード
Aurora MySQL でセッションを kill する方法 - ablog
スレッド ID を確認する。 Id 列がスレッドID mysql> SHOW FULL PROCESSLIST; +----+----------+---------------------+------+---------+------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+----
[MySQL]オプティマイザトレースでインデックス選択根拠を調べる[単一テーブル編] - Qiita
この記事は Lancers（ランサーズ） Advent Calendar 2020 6日目のエントリーです。 バックエンドエンジニア＆DBRE の まみー です。 僕は MySQL が大好きです。 普段 ORM 任せでクエリを意識しないことも多い昨今。 だからこそクエリ 1 とインデックス 2 くらいはわかる僕らでありたいと思うんですが、思ってたんと違うインデックスが選択されることありますよね。 じゃあ理由を明確にして本質を知った上で対応しよう。 というわけでインデックス選択の根拠をオプティマイザが算出するコストから検証してみます。 オプティマイザトレースの使い方をサクッと知りたい方は コチラ からご覧ください。 条件 単一テーブル 複合インデックス 1番目で ID で絞り込み 2番目で前方一致 LIKE 検索 実例 3 として、TODO管理情報を ユーザーID キーワード前方一致 で検索
![[MySQL]オプティマイザトレースでインデックス選択根拠を調べる[単一テーブル編] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/2add9a0dee2df9876dced9d4bb26f7beb5f158bf/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent-calendar-ogp-background-7940cd1c8db80a7ec40711d90f43539e.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCTXlTUUwlNUQlRTMlODIlQUElRTMlODMlOTclRTMlODMlODYlRTMlODIlQTMlRTMlODMlOUUlRTMlODIlQTQlRTMlODIlQjYlRTMlODMlODglRTMlODMlQUMlRTMlODMlQkMlRTMlODIlQjklRTMlODElQTclRTMlODIlQTQlRTMlODMlQjMlRTMlODMlODclRTMlODMlODMlRTMlODIlQUYlRTMlODIlQjklRTklODElQjglRTYlOEElOUUlRTYlQTAlQjklRTYlOEIlQTAlRTMlODIlOTIlRTglQUElQkYlRTMlODElQjklRTMlODIlOEIlNUIlRTUlOEQlOTglRTQlQjglODAlRTMlODMlODYlRTMlODMlQkMlRTMlODMlOTYlRTMlODMlQUIlRTclQjclQTglNUQmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzNBM0MzQyZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPTYzZjI1NGYxYTBhZGE3ZWUwNzE4YmI2NjY5NmZiODhl%26mark-x%3D120%26mark-y%3D96%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9OTcyJnR4dD0lNDBtYW15MTMyNiZ0eHQtY29sb3I9JTIzM0EzQzNDJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9YWQ1OWY5MzljN2Y4MDNmOTIxZTE0YjU4ZGJjZDkzMGI%26blend-x%3D120%26blend-y%3D500%26blend-mode%3Dnormal%26s%3D14848e487eb8b0058aa17af8d0e006d4)
TRUNCATE TABLEがバッファプールを読んでいる - 41から始めました
本エントリはMySQL Advent Calendar 2020 の13日目です。 今日はちょっとだけMySQL8.0にアップグレードしとくと良いよ、というネタです。 TRUNCATEよりもDROPとCREATEのほうが性能が良いか？ はい、MySQL5.7以前まではDROPと&CREATE のほうがTRUNCATE TABLEよりも高速なんです。 なぜならこんなバグが5.7以前にはあるからです。 要約すると、MySQL 5.7以前のInnoDBでは、TRUNCATE TABLEを実行した際、ファイルを再作成する以外にも、バッファプールのスキャンが発生するというものです。 ただし、適応型ハッシュインデックスがOFFの場合には、スキャンは生じません。 このバグ、MySQL8.0で改善されました。 どういうときに困るのか？ 大きなバッファプールを持っていて、TRUNCATE対象のテーブル情報が
MySQL のレプリケーションから10年間逃げてきた我々が学んだこと8選 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。クラウド運用チームで SRE をしている飯塚です。 今回は、MySQL のレプリケーション機能を約10年もの間ずっと使ってこなかった私たちが、レプリケーションを使った高可用性構成に移行するための取り組みの中で学んだことについて紹介します。 背景 巨大なテーブルへの primary key の付与 トランザクションサイズが大きい場合には tmpdir に注意 mysqldump で絵文字が消えていないか要チェック mysqldump が Error 1412: Table definition has changed... で失敗する mysqldump したデータのリストアが Duplicate entry 'xxx-yyy-PRIMARY-n_diff_pfx01' for key 'PRIMARY' で失敗することがある mysqldump したデータのリストア時のディスク
ISUCON10 の振り返りと MySQL の generated columns - Techtouch Developers Blog
バックエンドエンジニアの misu です。最近は塩加減に苦戦しながら、スパイスからカレーを作っています。 この記事について ISUCON 10 の振り返り チーム構成 振り返り generated columns とは 参考 この記事について ISUCON 10 に出場し、予選敗退したのでその振り返りと次回のために MySQL の generated columns について調査したことが書かれています。 ISUCON 10 の振り返り チーム構成 弊社では、僕が ISUCON 出る人いませんか〜と募ったところ、6 人の戦士が手を上げてくれました。僕以外は全員初出場です。 7 人なので、得意な言語でこんなチーム分けになりました。 Go チーム 2 人セットが 2 チーム Node.js チーム 3 人 振り返り 僕は、Go で普段開発しているので、Go で挑んだのですが、社内 3 チームの
MySQL の binlog について調べたメモ - まっしろけっけ
MySQL の binlog について 実際に実行された更新系クエリの情報が記述されていてなんらかの理由によりデータが壊れた際の データ復旧とかにも役にたつ。 binlog の format には以下の 3 種類ある フォーマットの種類 設定値(文字列) 設定値(数字) 備考 ステートメントベース STATEMENT 1 実際に実行された SQL を記録 行ベース ROW 2 実際に変更された行のデータの情報を記録 ミックス MIXED 0 基本的にはステートメントベースと同じで非決定性のクエリの際は行ベースと同じ形式のログを出力する ここら辺は DB server を構築する際にレプリケーションとかを考えると思うので 基本的には理解している内容だと思われます。 今回は binlog の中身を除いて実際にどうなってるの？というところを調べた。 実際にログを出力させて比べる 環境 Mac M
第112回 知っておくと便利になるかもしれない小技 | gihyo.jp
今回はMySQLを利用するうえで、知っていると便利になるかもしれないちょっとした小技をいくつか紹介しようと思います。なお、利用するMySQLのバージョンは8.0.18、OSはCentOS 7を利用しています。 STRAIGHT_JOINの位置 第97回 JOIN_ORDERを使ってJOINの順番を決めるにて、バージョン8.0以降ではJOIN_ORDERヒント句を用いてJOINの順番を決めるやり方と、バージョン5.7とそれ以前ではINNER JOINに限り、STRAIGHT_JOINを用いて駆動表を選択することができることを紹介しました。 みなさんはこのSTRAIGHT_JOINを記述するやり方が複数あるのはご存知でしょうか？ 1つ目の記述は、INNER JOINの記述をSTRAIGHT_JOINに書き直すやり方です。たとえば、第97回で利用した下記クエリを参考にしてみましょう。 mysql
第110回 Invisible Indexesを使って気軽にチューニングを始めてみる | gihyo.jp
使用されず役に立たないインデックスを定義するのは、SQLアンチパターンの1つ「インデックスショットガン」として知られています。使用されていないインデックスを定義するのは、ディスク容量を圧迫して、さらに更新コストも掛かるという良いこと無しな状態です。 ただ実際には、あなたが使用されていないインデックスを見つけたとしても、安易にドロップするのは非常に危険です。ドロップするのは時間がかかりませんが、インデックスを再構築するまでには時間がかかります。 もしも万が一そのインデックスが使用されているクエリが存在するとしたら、その時点から障害につながってしまう可能性があります。ドロップはしたくないけど、使わないようにして影響を確認したい……、今回はそんな時に便利なMySQL 8.0の新機能「Invisible Indexes」を使ってインデックスを外した時の影響を調べてみましょう。 検証環境 今回はDo
dbdeployer
Skip to the content. The end of dbdeployer dbdeployer DBdeployer is a tool that deploys MySQL database servers easily. This is a port of MySQL-Sandbox, originally written in Perl, and re-designed from the ground up in Go. See the features comparison for more detail. Documentation updated for version 1.66.0 (26-Jul-2022 10:30 UTC) Installation Manual installation Installation via script Prerequisit
MySQL 8.0.17でついにCloneプラグインが入った
TL;DR MySQL 8.0.17 でついに俺待望の Cloneプラグイン が追加された CLONE LOCAL DATA DIRECTORY .. で、ローカルファイルシステムにほぼノンブロッキングで物理バックアップを吐き出す CLONE INSTANCE FROM USER@HOST:PORT IDENTIFIED BY 'password' .. でグループレプリケーションの経路を使ってフツーのレプリケーションと同じ3306の経路を使ってインスタンスの丸コピーができるらしい このへんを読んでおくのが良さげ MySQL :: MySQL 8.0 Reference Manual :: 5.6.7 The Clone Plugin MySQL :: MySQL 8.0 Reference Manual :: 5.6.7.13 Clone Plugin Limitations mysql
SQLで羃等にDBスキーマ管理ができるツール「sqldef」を作った - k0kubun's blog
sqldefのリポジトリ github.com これは何か Ridgepoleというツールをご存じでしょうか。 これはRubyのDSLでcreate_tableやadd_index等を書いてスキーマ定義をしておくとそれと実際のスキーマの差異を埋めるために必要なDDLを自動で生成・適用できる便利なツールです。一方、 で言われているように、Ridgepoleを動作させるためにはRubyやActiveRecordといった依存をインストールする必要があり、Railsアプリケーション以外で使う場合には少々面倒なことになります。*1 *2 そこで、Pure Goで書くことでワンバイナリにし、また別言語圏の人でも使いやすいよう、RubyのDSLのかわりに、誰でも知ってるSQLでCREATE TABLEやALTER TABLEを書いて同じことができるようにしたのがsqldefです。 使用例 現時点ではMy
Verifying Query Performance Using ProxySQL
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
MySQLのクエリの良し悪しはrows_examinedで判断する - かみぽわーる
仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL InnoDBのフルテキストインデックスで、ストップワードフィルタを無効にする (in, by, is などで検索できるようにする) - Qiita
MySQL 8.0のnutshellを読んで秘伝のタレをどうこうしようと思っているメモ
[PS-5582] - Percona JIRA
Mysql daemon not releasing deleted temp file
MySQL crashing at about 70k open files
MySQLパフォーマンスチューニングTIPS
