タグ

MySQLに関するatsuizoのブックマーク (338)

  • MySQL でショート/ロングトランザクション実行中のインデックス作成の影響 - ablog

    MySQL (5.7 InnoDB) で番稼働中にインデックス作成すると、対象テーブルにショートトランザクション実行中の場合は並行でできるけど、ロングトランザクションが実行中*1の場合は Waiting for table metadata lock (synch/cond/sql/MDL_context::COND_wait_status) で metadata lock を延々待ち続ける。DML はオブジェクト定義のメタデータに共有ロックを取り、DDL は排他ロックをかけるため、ロングトランザクションが実行中にインデックスを作成すると、そのトランザクションが終了するまで排他ロックを取れず待ち続ける。 環境 Aurora Mysql エンジンバージョン: 5.7.mysql_aurora.2.07.2 検証結果 sysbench を Amazon Linux 2 にインストールする A

    MySQL でショート/ロングトランザクション実行中のインデックス作成の影響 - ablog
    atsuizo
    atsuizo 2020/11/26
    Performance Insightsでの見え方まで書いてあって素晴らしい。なお、Auroraってことなので、mita2さんのこの記事も参考に。 https://mita2db.hateblo.jp/entry/2020/07/20/153139
  • クエリログを使ったAurora MySQLの負荷テスト - クックパッド開発者ブログ

    最近はZX-25Rが気になっている菅原です。4気筒250ccといえば、以前バリオス2に乗っていたんですが、あれもよく回るよいバイクでした。足つきの良さが懐かしいです。 この記事では、クエリログを使ったAurora MySQL負荷テストの話を書きます。 MySQL負荷テスト サービスに使われているデータベースは、Webサーバと比べて自動的なスケールアップ・スケールアウトが簡単ではないためキャパシティプランニングは非常に重要です。サービスへのアクセス増による負荷増大の結果、急激に性能が低下するためなるべく事前にキャパシティを把握しておきたいところです。 クックパッドではサービスのデータベースとして主にAurora MySQLを利用しているのですが、キャパシティを把握するための負荷テストには以前から苦労してきました。 1. シナリオを書くのが大変 サービスで使われているデータベースの負荷テス

    クエリログを使ったAurora MySQLの負荷テスト - クックパッド開発者ブログ
    atsuizo
    atsuizo 2020/10/13
    これは試してみたい。
  • index->lock の競合について 〜ベンチマークはちゃんとチューニングして〜

    他に忘れないうちに書きたいこともあったのですが、世に出るまで書けないので、ソースと関係ない一般的なこと(バージョン5.7以降)を書きます。(書かない方のことは書けるようになる頃には忘れてしまうかも…) index->lockの競合を直して欲しい。という人がいまだに居たりするのです。色々試しましたが、多分殆どの場合は理解不足・チューニング不足です。私自身はindex->lockの競合が不可避なベンチマークに結局会っていません。 特にMySQLとその他のRDBMSを比べる場合にはちゃんと最適化した負荷をかけないとMySQLが悪く見えるのでベンチマークをする際には気をつけて欲しいものです。 5.7で更新・参照並列性を高めるために導入された、index->lockのSXロック(Sロックは可能・SX/Xロックは不可)は、基的にそのindexにpageを追加・削除するような処理をする際に保持されます

  • ISUCON10予選で12位になり本選進出を決めました - Gマイナー志向

    TL;DR ISUCON10の選出場が決定しました。わいわい。 予選12位、最終スコアは2837でした。 毎年素晴らしいコンテストを開催してくださる運営様には、当に頭が下がります。いつもありがとうございます。 選もがんばるぞ! 体制 チーム名 ウー馬場ーイーツ あいこん なまえ やくわり matsuu バリバリ実装する前衛 netmarkjp 司令塔 ishikawa84g SELinuxAppArmorとレギュレーションやコードやDiscordを見るセキュリティ&情報官 今回は3人が同じ場所に集まらずすべてリモート体制としました。 3人だけのDiscordサーバを用意し、Discord上で画面共有と音声チャットで進めています。 方針 毎年同じですが sshで接続してtmux上でvimで直接編集 isuumo配下でgit initを実行するが履歴保存用でbranchは作成しない 毎年

    ISUCON10予選で12位になり本選進出を決めました - Gマイナー志向
    atsuizo
    atsuizo 2020/09/14
    ISUCONでMySQL8.0固有のノウハウやGIS系のチューニングが効くような問題が出てくるとは恐ろしい。
  • Percona Playback で 本番 MySQLに流れているクエリを試験環境でリプレイする - mita2 database life

    データベースのバージョンアップの際、アプリケーションの網羅的なテストが可能であれば良いのですが、どうしても難しいケースがあります。 そのような場合、リプレイツールで番環境に流れているクエリを、試験環境でリプレイ(再現)し、動作確認を取る方法もあります。 リプレイツールを探す MySQL の クエリ リプレイができるツールを探してみました。 Percona Tookit に pt-log-player というツールが含まれていたのですが、いつのまにか、なくなってました。。。 2013年にリリースされた、percona tookit 2.2 で削除されてしまったようです。 We removed pt-query-advisor, pt-tcp-model, pt-trend, and pt-log-player. Granted, no tool is ever really gone: i

    Percona Playback で 本番 MySQLに流れているクエリを試験環境でリプレイする - mita2 database life
    atsuizo
    atsuizo 2020/08/30
    これは便利そう。リプレイ元がgeneral_logかslow_query_logでいいっていうのがいい。
  • Amazon Aurora レプリカ では metadata lock 待ちが発生しない - mita2 database life

    Amazon Aurora のレプリカは Vanilla MySQL のレプリケーションとは違った仕組みで実現されている。 マスターとレプリカは同じディスクボリュームを参照しており、マスターでの更新はほぼ即時レプリカに反映される。 DB クラスターボリュームは DB クラスターのデータの複数のコピーで構成されます。ただし、クラスターボリュームのデータは、DB クラスターのプライマリインスタンスおよび Aurora レプリカの 1 つの論理ボリュームとして表されます。この結果、すべての Aurora レプリカは、最短のレプリカラグでクエリの結果として同じデータを返します。 レプリカラグは、通常はプライマリインスタンスが更新を書き込んだ後、100 ミリ秒未満です。https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide

    Amazon Aurora レプリカ では metadata lock 待ちが発生しない - mita2 database life
    atsuizo
    atsuizo 2020/07/20
    これは試したことがなかった!
  • Innodb Deep Talk #2 でお話したスライド

    Innodb Deep Talk #2 でお話したスライドです。 主旨は後半のチューニングの話かと。Read less

    Innodb Deep Talk #2 でお話したスライド
  • performance_schema.events_statements_historyを使って直近に実行されたクエリを見る - kenken0807_DBメモ

    さくっと、直近で実行されたクエリの情報がみたいです。 それにはperformance_schema.events_statements_historyテーブルを使います。 performance_schema.events_statements_historyはスレッドごとにperformance_schema_events_statements_history_size(default 10)で指定した個数分のステートメントを格納します。 MySQL5.7以降であればデフォルトONです。 以下のようなSQLを実行すればいい感じみれる。 SELECT * FROM ( SELECT THREAD_ID,EVENT_ID, BaseDate - interval (BaseUptime-ROUND(TIMER_START/1000000000000)) second as QUERY_STA

    performance_schema.events_statements_historyを使って直近に実行されたクエリを見る - kenken0807_DBメモ
  • MySQL max_connections は雑に設定しておけば良い - mita2 database life

    MySQL 誕生25周年 らしいです。めでたい! 25年、1つのソフトウェアが継続しているってすごい! max_connections について データベースを使っている開発者から「最大までどれぐらいコネクション数を増やせるのか」という質問を良くもらいます。 最大コネクション数(max_connections) の設定値を超えてしまい、too many connections エラーが出る。 max_connections を見直すとして、「じゃあどこまで大きくしていいのか?」と不安になるのはわかる。 以下の話は、コネクションプールを使っている前提のお話。 単にコネクション数が増えるだけでは、負荷は増加しない 単にコネクション数が増えるだけでは、DBサーバの負荷はあまり変化しない。 特にMySQLはスレッドモデルで実装されており、(プロセスモデルのデータベースと比較して)大量にコネクション

    MySQL max_connections は雑に設定しておけば良い - mita2 database life
    atsuizo
    atsuizo 2020/05/31
    接続してくる側が最大接続数をキャップしてないと、MySQLへの同時処理要求数が爆発してCPU食いすぎて他のサービスまで機能しなくなることがあるのが怖い。
  • MySQL: COUNT(*) は 1 ?? - sakaikの日々雑感~(T)編

    Twitterに書き殴ったのですが、流れてしまうので、一応こちらにもまとめておこうかと。 これって、何を数えているんでしたっけ? mysql> SELECT COUNT(*); +----------+ | COUNT(*) | +----------+ | 1 | +----------+— 坂井 恵(SAKAI Kei) (@sakaik) 2020年5月1日 コトの発端はちょっとした打ち間違いだったのですが、MySQL は FROM 書かなくても演算できます。こんな感じ。 mysql> SELECT 3; +---+ | 3 | +---+ | 3 | +---+ mysql> SELECT SQRT(64); +----------+ | SQRT(64) | +----------+ | 8 | +----------+ ここで、SELECT COUNT(*) とすると何が返って

    MySQL: COUNT(*) は 1 ?? - sakaikの日々雑感~(T)編
    atsuizo
    atsuizo 2020/05/02
    Oracleからやってきた人には割と自然に受け入れられる話だな。なおOracleだとselect * from dualでDUMMY列に"X"という値が入ってるという結果が返ってくる。
  • Using advanced options in MariaDB Connector/J

    atsuizo
    atsuizo 2020/04/13
    本家が「connector/j内のConnectionPoolは正確性と信頼性に問題があるのでHikariCP使うのがいいよ」って言っている資料。
  • MySQLのfilesortは何ソートで行われているのか - $shibayu36->blog;

    最近、CourseraのArgorithms, Part1という講義を受けている。そこでソートの講義を受けて、そういえばMySQLのORDER BYでfilesortになったときってどのソートが使われているのだろうと気になってきたので調べてみた。 調べてみると非常に難解で、結局いまいち分からなかったが、今の段階の調べた内容をひとまず書いておく。MySQLのコードを読んだのも初めてで、しかもちゃんと読み解くことができなかったので、情報が間違っている可能性も非常に高い。間違ってたら指摘してもらえるとうれしいです。 調査結果 最初に調査結果を書いておく。たぶんこれは非常に単純化したもので、詳しく見るともっといろいろチューニングされてそう。 sort_buffer_size以内のメモリ量でソートが可能な場合、メモリ内でのみソートされる ソートにsort_buffer_size以上のメモリが必要な場

    MySQLのfilesortは何ソートで行われているのか - $shibayu36->blog;
  • MySQL8でCHAR関数がドキュメントどおりになってない - 41から始めました

    MySQL8でCHAR関数がドキュメントどおりになってない https://dev.mysql.com/doc/refman/5.6/ja/string-functions.html#function_char を読むと、こう書いてある。 CHAR(N,... [USING charset_name]) CHAR() は各 N 引数を整数として解釈し、それらの整数のコード値で指定された文字を構成している文字列を返します。NULL 値はスキップされます。 mysql> SELECT CHAR(77,121,83,81,'76'); -> 'MySQL' mysql> SELECT CHAR(77,77.3,'77.3'); -> 'MMM' MySQL5.7.29の場合 ドキュメントはこちら mysql [localhost:5729] {msandbox} ((none)) > SELEC

    MySQL8でCHAR関数がドキュメントどおりになってない - 41から始めました
    atsuizo
    atsuizo 2020/02/29
    8.0.14で実行したら正しく表示された!mysqlsh 8.0.19新たに入れて8.0.14サーバーにつないでも正しかったので、サーバー側の問題かどこかしらの設定か。
  • MySQLのslow_logは何を計測して出力されるのか - tom__bo’s Blog

    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

    MySQLのslow_logは何を計測して出力されるのか - tom__bo’s Blog
  • MySQL (MariaDB) でハマった仕様 - kamocyc’s blog

    以前,MySQL (正確にはMariaDB) を使った際,いろいろはまったので記載します. 使ったバージョンが古い(MariaDB 10.1.37, MySQL 5.7くらいに相当)なので,最新版では治っているところもいくつかあります. sql_modeをデフォルトの設定で使わない これはよく言われていることですが,sql_modeがデフォルトでは変な値が入ったりエラーになって欲しいところがスルーされたりしてまずいので,適切なsql_modeを設定します. 第18回 MySQL5.7のデフォルトのSQLモードを確認してみる:MySQL道普請便り|gihyo.jp … 技術評論社 MySQLSQLモードをstrictモードで設定する。 - Qiita ただ,MySQL 5.7以降はデフォルト設定が改善されたようです.(でも確認すべきですが) MySQL :: MySQL 8.0 Refer

    MySQL (MariaDB) でハマった仕様 - kamocyc’s blog
    atsuizo
    atsuizo 2020/02/18
    ハマリどころコレクション。よくぞここまでまとめてくれました。
  • MySQL 8.0.18 の実装を読み解きながら簡単なストレージエンジンを自作する - それが僕には楽しかったんです。

    はじめに MySQL をビルドする ストレージエンジンを自作する Example エンジンをベースにする handlerton の作成とインスタンス化 テーブルを作成する 余談・気になったところ テーブルを開く INSERT の実装 ha_tina の存在 テーブルスキャン store_lock の実装 external_lock の実装 rnd_init の実装 info の実装 extra の実装 rnd_next の実装 おわりに はじめに 卒論書くのに飽きてきて何かやりたくなったので急にストレージエンジンを書くことにしてみた。 MySQL のストレージエンジンを実装していく中で、色々できるかなと思っていたけど、やってみると MySQL の内部実装について色々知らないといけないことが多くインデックスとかトランザクションとかそういうところは実装できなかった。 github.com My

    MySQL 8.0.18 の実装を読み解きながら簡単なストレージエンジンを自作する - それが僕には楽しかったんです。
    atsuizo
    atsuizo 2020/01/17
    "卒論書くのに飽きてきて何かやりたくなったので急にストレージエンジンを書くことにしてみた。"すごい動機。こういう人には敵わないと思った。そしてこの学びのプロセスの公開、すごく参考になる。
  • MySQL データベースの負荷対策/パフォーマンスチューニング備忘録 インデックスの基礎〜実践 - Qiita

    TL;DR この記事に書いた事 二分探索木のお話(前提知識) MySQLのInnoDBで利用されているB+木インデックスの構造と特性 (前提知識) MySQLのClusteredIndex,SecondaryIndexについて(前提知識) カーディナリティについて(前提知識) 実際の負荷対策 検出編 スロークエリ 検出編 その他のクエリ割り出しいろいろ クエリ・インデックスの最適化 explainの使い方と詳細 ケース別実践 単純にインデックスがあたっていないケース カーディナリティが低いインデックスが使われているケース 部分的にしかインデックス/複合インデックスがあたっていないケース 複合インデックスの順序誤りでインデックスが適用できていないケース 複合インデックスの最初がrange検索のケース ソートにインデックスが適用できていないケース ソートにインデックスが適用できていないケース(

    MySQL データベースの負荷対策/パフォーマンスチューニング備忘録 インデックスの基礎〜実践 - Qiita
    atsuizo
    atsuizo 2020/01/11
    よくここまでまとめたなあ。とても丁寧な解説。
  • MongoDBであるメリットが無くなってしまったのでMySQLに移行したはなし - KAYAC engineers' blog

    SREチームの長田です。 この記事はTech Kayac Advent Calendar Migration Track 1日目の記事です。 今回はLobiで使用していたMongoDBMySQLに移行したはなしです。 MongoDBを何に使っていたか DAUなどのKPIレポートや、サービスの状況を把握するための各種集計結果を保存するために使っていました。 サービス開始直後はこれらの数字を色々と試行錯誤しながら追加したり、減らしたりしていました。 頻繁な追加削除があるデータ構造を保存するために、スキーマレスなデータベースであるMongoDBはちょうどよかったようです。 (当時スキーマレスデータベースが流行っていたというのもあるでしょう) なぜ移行したのか MongoDBに保存されたドキュメントは、スキーマ管理がされていませんでした。 スキーマレスであることをいいことに、その時時によって様々

    MongoDBであるメリットが無くなってしまったのでMySQLに移行したはなし - KAYAC engineers' blog
    atsuizo
    atsuizo 2019/12/01
    "スキーマレスだからといってスキーマ管理を放棄すると後で痛い目にあうので気をつけましょう"これな。
  • RDSスナップショットを、テスト用にマスクする、CodeBuildとdbtestdataで - Qiita

    番RDSスナップショットをそのままテスト用に使うわけにいかない。個人情報とか業務上の機密とか。マスクします。みなさんどうやってるんですかね。 全体像 こんな流れで作ります。 create RDS Instance Data masking RDS create snapshot RDS instance shutdown この記事では 2. のところを扱います。ほかは手作業。そのうちawscliとCodeBuildで自動化する。 マスク設定ファイルをつくるのに必要な情報を用意する information_schema.tables, columnsを漁る テーブルそのものの要否をふりわける 必要なテーブルについて、マスクすべきカラムを選別する カラムごとに、どんなデータパターンでマスクするか決める マスク設定ファイルをつくる マスクツールは dbtestdata を使います。dbtest

    RDSスナップショットを、テスト用にマスクする、CodeBuildとdbtestdataで - Qiita
  • MySQL SQLオプティマイザのコスト計算アルゴリズム - SH2の日記

    いちいさんにお誘いいただいて、勉強会で発表をすることになりました。 InnoDB Deep Talk #1 : ATND おそらく初見では内容が難しいと思いますので、先に資料を公開しておきます。 プレゼンテーション資料 (PDF) テストデータ生成スクリプト (JdbcRunnerで利用します。) プレゼンテーション資料からリンクしているウェブサイトの一覧です。 MySQL Bugs: #64567: Last_query_cost is not updated when executing an unique key lookup Understanding and Control of MySQL Query Optimizer: Traditional and Novel Tools and Techniques: MySQL Conference & Expo 2009 - O'R

    MySQL SQLオプティマイザのコスト計算アルゴリズム - SH2の日記