MySQL 5.1＋InnoDB Plugin 1.0以降でのロック状態確認方法としては、こちらの記事が有名です。 MySQL InnoDBにおけるロック競合の解析手順（SH2の日記／SH2さん） 利用しているのがMySQL 5.6以前だったり、MySQL 5.7を利用していても複数バージョンが混在している環境では同一のクエリで確認できるメリットがありますので、今でもこれを使われている方が多いのではないかと思います（MySQL Casual Advent Calendar 2017の20日目でも、@soudai1025さんがビューの作成を勧められていました）。 なぜあなたは SHOW ENGINE INNODB STATUS を読まないのか（そーだいなるらくがき帳／そーだいさん） 一方、MySQL 5.7では、sysスキーマにロック状態確認ができるビューとして**sys.innodb_lo

そのため、binlog_formatの設定を合わせるため問題が起こったのsourceサーバーをSTATEMENTにして対処したところ、今度は更新処理で以下のようなエラーが出ていました。 ERROR 1665 (HY000): Cannot execute statement: impossible to write to binary log since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine limited to row-based logging. InnoDB is limited to row-logging when transaction isolation level is READ COMMITTED or READ UNCOMMITTED.これによりsourceに書き込む

I have a query to check mysql users list for create new user. IF (SELECT EXISTS(SELECT 1 FROM `mysql`.`user` WHERE `user` = '{{ title }}')) = 0 THEN CREATE USER '{{ title }}'@'localhost' IDENTIFIED BY '{{ password }}' END IF; But i get this error: ERROR 1064 (42000) at line 3: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax

こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。先日親知らずを抜歯した時、つらすぎたので MySQL の JOIN のことを考えて心の平静を保っていました。 サイボウズの製品のひとつである kintone はニーズに応じて自由に業務アプリのようなものを手軽に作ることができ、データの検索条件やソート条件も細かくカスタマイズ可能で、様々なレベルでのアクセス権も設定可能という非常に便利なツールです。 しかしその機能を支える裏側では複雑なクエリが発行され、MySQL に多大な負荷をかけています。サイボウズのクラウドには数十テラバイトに登る MySQL データがあり、数千万件オーダーのテーブルを複数 JOIN するクエリが毎秒のように実行されるという、エンジニア魂が滾る環境です。 現在サイボウズでは性能改善に力を入れており、僕もその業務に従事しています。例えば2018年

散々、書かれていることで、何度もでてくる話なので、自分用にまとめ。 文字コード まずMySQLの文字コードですが絵文字のみでなく、JIS X 0213の第3・4水準漢字の 一部にUTF8 4バイト文字があり（まぁまず使われないと思いますが）、 MySQLの文字コードはこれからはutf8mb4一択のようです。 charsetは、サーバ、クライアント、サーバー/クライアント感の接続、データベース、、テーブル、カラムで個別に指定でき、 問題を起こさないようにするには、すべて揃えたほうが無難であります。 character_set_server=utf8mb4 character_set_client=utf8mb4 character_set_connection=utf8mb4 character_set_database=utf8mb4 character_set_results=utf8m

行ロックと「LOG: process 12345 still waiting for ShareLock on transaction 710 afte...Masahiko Sawada

今更だけど MySQL 5.6 ではオンラインDDLの機能が追加されている。今日はこのオンラインDDLについて勉強したことを書いてみる。 MySQL のマニュアル MySQL :: MySQL 5.6 Reference Manual :: 14.11 InnoDB and Online DDL にいろいろ書いてある。いまから書くことはこのマニュアルから得た知識が元になっている。 DDL てなによ？ データではなく、テーブル自身を操作するためのSQL文のこと。CREATE, ALTER, DROP, TRUNCATEなど。オンラインDDLではCREATE INDEX, DROP INDEX, ALTER TABLEに適用される。 http://dev.mysql.com/doc/refman/5.6/en/glossary.html#glos_ddl 5.1 までの ALTER TABLE

レプリケーションはMySQLで最もよく使われる機能のひとつだ。レプリケーションは基本的に非同期でデータの複製を行う仕組みになっているのだが、非同期故にどうしても逃れられない問題がある。そのひとつが今回のテーマ、遅延である。というと、MySQLのレプリケーションはすぐに遅延が生じてしまうように感じてしまうかも知れないが、そのようなことはない。ほとんどの場合は即座にスレーブの更新が行われる。 なぜ遅延は発生するのか、どのように遅延が起きていることを調べるのか、どのように回避するのかということを本エントリでは解説したい。うまく遅延と付き合って、MySQLのレプリケーションをより快適に運用してもらえればと思う。 そもそも遅延とは何かMySQLのレプリケーションは非同期で行われる。これは準同期でも同じであり、スレーブにおいて更新が起きるのはマスターよりも一瞬遅れてしまう。これは非同期であるが故に逃れ

MySQL Casual Advent Calendar 2016 - Qiita 12日目の記事です。 まさかの3回目。もうムリ。。。 JOIN ON句で結合条件ではなく絞込条件を書くことができることを、知らなかったのです。 具体的な名称がわからない＆検索にもヒットしにくいので、勝手に名前をつけました。 「JOINに直値」 わかりにくいと思うので、サンプルSQL書きます。 SELECT tbl_a.col1,tbl_b.col1 FROM tbl_a INNER JOIN tbl_b ON tbl_a.col1 = tbl_b.col1 AND tbl_a.col2 = 0; JOINでは一般的に「表A JOIN 表B... ON 表A.列 = 表B.列」と書いて表同士を結合するための条件を書きますが、ここに、一方の表の絞り込み条件を書けるんです。 SQLの教科書的な書籍ではまず見かけま

この記事は Mackerel プラグインアドベントカレンダー(全部CRE） の20日目です。 qiita.com soudai.hatenablog.com それでは20日目は mackerel-plugin-mysql 第二弾、InnoDBの監視です。 mackerel-plugin-mysqlはRDBMSとして広く使われているMySQL専用のプラグインです。 第一弾はこちら。 soudai.hatenablog.com インストール方法や使い方、MySQLのデータ取得で使っているSQLは前回説明したので割愛します。 前回はMySQL全般に言える監視の内容でした。 今回はその中でもInnoDBに特化した内容でお送りします。 見れるメトリック それでは各グラフ定義ごとに説明します。 また表に出てくるdiffとはプラグイン上で差分値計算をするかどうかです。 ◯ となっている項目はプラグインで

この記事は Mackerel プラグインアドベントカレンダー(全部CRE） の4日目です。 qiita.com soudai.hatenablog.com それでは4日目は mackerel-plugin-mysql です。 ここではMySQLの細かい説明は割愛します。 mackerel-plugin-mysqlはRDBMSとして広く使われているMySQL専用のプラグインです。 github.com インストールと設定手順 本プラグインはプラグイン集として提供しているパッケージの mackerel-agent-plugins に含まれています。 インストール先は /usr/bin/mackerel-plugin-mysql です。 mackerel-plugin-mysqlは様々な情報を可視化してくれますが、pluginが動作するクライアント側からMySQLに対してアクセス出来る必要があり

slow logの時間は何を計測しているのか？ きっかけ とあるMySQLインスタンスで1Gbのネットワーク帯域を使い切ってレスポンスタイムが悪化していたという話を聞いた。 確かに遅いがlong_query_timeを小さくしてもslow_logは特に出ていなかったため、どのクエリが問題なのかを特定しづらかったらしい。 これを聞いたときはRedisとかインメモリのDBならまだしもMySQLがストレージより先に1GbのNICを使い切ることがあるのかーと驚いた。まあ、100GB以上のメモリも珍しくないので、ほとんどメモリから結果を返していれば1Gb/s以上返すことは難しくなさそうではある。 だが、long_query_timeを小さくしてもslow_logにクエリが出力されなかったという部分は気になった。 具体的にlong_query_timeがどれくらいなのか、同時接続数はどれくらいでQPS

2019/09/26 db tech showcase Tokyo 2019 B8 https://www.db-tech-showcase.com/dbts/tokyo Fixed wrong information in page 48 at 2019/10/02.