Amazon Web Services ブログ 初めてのPerformance Insights入門 テクニカルソリューションアーキテクトの笹川です。 本記事ではRDS MySQL使用時のPerformance Insightsの使い方についてご紹介させて頂きます。 Performance Insightsを聞いたことがあるけれど何ができるのか分からない、実際にどのように活用すれば良いのかイメージができないという方もいらっしゃるのではないでしょうか。今回は初めてのPerformance Insights入門と題してサンプルのクエリを実行しながらPerformance Insightsの使い方をご紹介していきます。 Performance InsightsとPerformance Schema Performance InsightsではDBの負荷状況がMySQLにログインすることなくAWS

MySQL/Aurora/TiDBロック入門 – 第１回トランザクション分離レベル MySQL InnoDB および AWS Aurora や PingCAP TiDB におけるロックの仕組みやトランザクションの動作を全１１回のシリーズで解説します！ 最初はベースとして重要な MySQL 8.0 InnoDB 前提でユーザー視点でのロックの仕組みを学び、後半第１０回以降では MySQL 互換 DB として人気の高い AWS Aurora や PingCAP TiDB と MySQL InnoDB との違いについて学びます。 １回目の今回はロック機構と切っても切り離せないトランザクションとその分離レベルについて、実際に挙動を確かめながら解説します。ライブ感のある説明も理解に役立ちますので、解説動画も付けてみました。合わせてご覧ください！ ★ 第１回 トランザクション分離レベル ★ 第２回 ロ

Amazon Web Services ブログ 初めてのPerformance Insights入門 – その２ テクニカルソリューションアーキテクトの笹川です。 前回は初めてのPerformance Insights入門と題してPerformance Insightsの基本的な見方や使い方をご紹介させて頂きました。Performance Insightsで何が確認できるのか、待機イベントとは何か、Performance Schemaと何が違うのか、少しでもイメージできるようになって頂けていれば幸いです。 今回は少し進んでPerformance Insightsを使ってデータベースのパフォーマンスチューニングを行ってみましょう。データベースのパフォーマンスチューニングを行ったことがない、どう考えれば良いかわからない、どこから手をつけたら良いのかイメージできない、という方の為に比較的簡単な例

SQL実行の流れ まずはSQLがどのような流れで実行されるのかを見ていきます。 SQL実行の流れは大まかに捉えると以下のようになります。 パーサ パーサでは、ユーザーから送信されたクエリを受け取り、その文法的な正確さを検証します。SQLクエリが正しくフォーマットされているか、必要な構文要素が全て含まれているかをチェックし、例えばFROM句で指定されたテーブルが存在するかどうかも確認します。 文法的なエラーがある場合、例えばカンマの欠落や存在しないテーブルの参照など、クエリはエラーとして返されます。 エラーがない場合は、クエリは「抽象構文木」というデータ構造に変換されます。これにより、データベースはクエリをより効率的に解析し、次の処理ステップに進めることができます。 オプティマイザ SQLクエリがパーサを通過した後、次にクエリの最適化を行うのが「オプティマイザ」です。オプティマイザの主な役割

こんにちは！DBREの福間（fkm_y）です。先月、弊社でデータベースの技術顧問をして頂いてる三谷（mita2）さんに開発本部向けの「MySQL SQLチューニング」勉強会を実施していただきました。 今回はMySQLの得意不得意なことの説明やSQLチューニングの流れ、具体的な事例を元にした対応例、また最近話題のHTAPな製品も紹介していただきとても参考になったのでポイントをおさえてレポートをお伝えします！ 開催背景 本編 MySQL の得意なこと、苦手なこと データベースのチューニング手段と特徴 SQLチューニングの流れ インデックス SQLチューニング例 インデックスフルスキャンとカバーリングインデックス ソート まとめ 当日の資料 さいごに 過去開催されたデータベース勉強会レポート 開催背景 弊社では三谷さんによるデータベース勉強会を定期的に開催しています。数年前にも同じテーマで勉強会

はじめに MySQL(InnoDB)でSQLのパフォーマンスチューニングをするときに役に立つ知識をエッセンスとしてまとめました。結合(JOIN)やB-treeインデックスの探索の仕組み、実行計画の基本的な見方を紹介します。 想定する読者は、SQLのパフォーマンスを改善する必要があるが実行計画をみてもいまいちピンと来ない方です。インデックスの作成の経験や、複合インデックスやカーディナリティの知識があることを前提にしています。目標は、実行計画の内容がよく分からない読者が、実行計画をみただけでクエリが実行される様子をイメージでき、自信を持ってクエリの改善にあたることができるようにすることです。 ストレージエンジンはInnoDBを前提としています。また、インデックスはB-treeインデックスを想定しています。全文検索の転置インデックスや空間検索のR-treeインデックスについては触れません。 イン

こんにちは、 @kz_morita です。 今回は実際にであった MySQL の Deadlock と調査した内容を備忘録として残していきます。 エラー内容の確認 以下のようなサーバーエラーが発生していました。 java.sql.SQLTransactionRollbackException: (conn=100000) Deadlock found when trying to get lock; try restarting transaction Scala を用いているので java のエラーが出てますが、deadlock が起きていることがエラーログからわかりました。 SHOW ENGINE INNODB STATUS を確認 次にどのクエリで deadlock が発生しているのを特定するために、MySQL の SHOW ENGINE INNODB STATUS を確認します。

この記事は、MySQL Casual Advent Calendar 2017の20日目の記事です。 煽り気味のタイトルですがみなさん SHOW ENGINE INNODB STATUS 読んでますか？ SHOW ENGINE INNODB STATUS \G 見づらいのなんとかならんのか。— そーだい@初代ALF (@soudai1025) 2016年12月20日 わかる。でもMySQLの振る舞いを知る中でSHOW ENGINE INNODB STATUSを読まざる得ない場面はそこそこあります。 どんな時に必要になるのでしょうか？ そこでSHOW ENGINE INNODB STATUSにまつわる話を書きます。 SHOW ENGINE INNODB STATUS をまず読みやすくする まず末尾に \G を付けましょう。 これで3倍読みやすくなります。 次に pager less -S を

データベースとテーブルの作成 テスト用のデータベースtestdbを作成し、パフォーマンスチューニングを検証するためのcompanyおよびpersonテーブルを定義します。 CREATE DATABASE testdb; USE testdb; CREATE TABLE company ( company_id INT AUTO_INCREMENT PRIMARY KEY, company_name VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE person ( person_id INT AUTO_INCREMENT PRIMARY KEY, company_id INT, person_name VARCHAR(255) NOT NULL, email VARCH

はじめに 医療系クラウドサービスを提供している会社で働いている2kaiです。 2022年7月に入ってから新型コロナウイルス感染爆発に伴い、患者及び医療スタッフの利用数が急増し、ピーク時間帯のデータベースCPU使用率がWriter、Reader共に監視の閾値を度々超えてくるという状態になりました。 と、思った次の日には100%に届くスパイクまで発生したために、急遽サービス無停止でスケールアップを実施しました。 現時点での月間アクセス数は1億リクエストを超えるくらいです（正確には感染爆発の前月の集計値になります）。 作業時間帯（22時頃）のアクセス数は850/min。 システム概要 Ruby on Rails in awsで構成された、恐らく一般的なモノリスアプリケーションです。 アプリケーションはWeb、Worker、Batchから構成 Ruby on Railsで実装し、WriterとRe

それほどDBに詳しくないアプリエンジニアが何かトラブった時にすぐさま行動して問題把握できるようになる情報を列挙しておきます。 開発時、障害時の対処療法やちょっとした定期監視方法などを対象にしています。 抜本的な対策などはインフラエンジニアさんにお任せしたほうがいいと思います。 DBはいろんな意味でこわいんでできれば触りたくないです＞＜ 事前確認 MySQLサーバーのシステム設定値を確認しておく 以下のようにサーバーのシステム設定値を確認できます。 mysql> SHOW GLOBAL VARIABLES; # ワイルドカード(%)を用いた絞り込み mysql> SHOW GLOBAL VARIABLES LIKE 'performance_schema%'

気づいたら9月でs(ry（段々ここで言うネタが切れてきた） 今さら言うことではないのですが、MySQLでSHOW (FULL) PROCESSLISTをしたいときに気を付けたいポイントをば。 さて、MySQLサーバーの監視や調査などでSHOW PROCESSLISTを叩くことは多いのではないのでしょうか。 今回は、今さら言うことではないSHOW PROCESSLISTをするときに気を付けたいことを書いていきます。 PROCESS権限がないとすべてのスレッドを確認できない performance_schema.threadsテーブルを参照するほうが負荷は低い p_s.threasからshow processlistと同じ情報を取得する まとめ おまけ PROCESS権限がないとすべてのスレッドを確認できない 社内DBAなどであれば、このあたりを特に意識する必要はないと思います。 しかし、例え

タイムライン的なものをSELECTだけで実装しようと思った時に、Nested LoopなクエリでUsing temporary; Using filesortが出るようなそこそこ遅いクエリになる。その時にMySQLがインデックスをどう辿っているかを知りたかったので調べてみた。MySQLバージョンは8.0.33。 あまり自信はないので、もし間違った話をしていたら教えて欲しい。 どのようなクエリを検証するか タイムラインの取得ができるような、ユーザー・フォロー関係・投稿の3つのテーブルを作る。スキーマは次の通り。 CREATE TABLE users ( id INTEGER PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL ); CREATE TABLE follows ( id INTEGER PRIMARY KEY AUTO_I