LOGILESS TECH BLOG vol.2 ~RollbackSegmentHistoryListLengthの増加によるMySQL(Aurora)のパフォーマンス劣化とトランザクション分離レベル~ 先日発売となった、星野源さんのエッセイ集「いのちの車窓から 2」をちょっと贅沢して物理本で購入して何周かしつつ、特に「喜劇」のエピソードが最高すぎて、余韻に浸りながら楽曲を聞き直しつつ、自分も源さんに恥じない良い仕事がしたいなと、改めて背筋を正して仕事に取り組んでいる今日この頃です。 さて、前回の記事ではドキュメントの話を長々と書いたので、今回は、技術寄りのネタをサラッと紹介したいと思います。 お題はタイトルにある通り、RollbackSegmentHistoryListLengthなんですが、私自身、このメトリクスに起因する障害は別の職場でも経験してて、２回目なのですが、前回の対応時に
この記事は、LayerX Tech Advent Calendar 2024 の7日目の記事です。 tech.layerx.co.jp こんにちは。バクラクビジネスカード開発チーム エンジニアの iwamatsu です。 何か書くことないかな〜と頭を悩ませていたところ、見たことのない不思議なデッドロックに出くわしたので、今回はそれについて書こうと思います。 実行環境 バージョン: MySQL 8.0.39 ストレージエンジン: InnoDB トランザクション分離レベル: REPEATABLE READ 発生した事象 以下のようなユーザーテーブルがあるとします。 CREATE TABLE `users` ( `id` INT NOT NULL, `name` VARCHAR(255) NOT NULL, `lucky_color` VARCHAR(255) NOT NULL, PRIMARY
はじめに みなさんこんにちはメリークリスマス🎄 ついにアドベントカレンダー最終日！！！ 現在SODAでwebエンジニアをしているtoshikiです。(3記事目で謎の自己紹介) CTOからflexispotのデスクを譲り受ける代わりにテックブログ3記事執筆するという約束を果たすべく、SODAのAdvent Calendar 2023で3枠担当することになり、この記事をもって無事プレゼントの配達が完了しました🎅(sorenani) 今日はクリスマス当日ということで、自分自身理解が曖昧だったMySQLのストレージエンジンであるInnoDBのロック周りの挙動をMySQLの公式ドキュメントを読みつつ調査してまとめてみました。 この記事でわかるInnoDBのロックの種類 共有ロックと排他ロック インテンションロック ギャップロック ネクストキーロック 検証環境 MySQLのVersion mysq
When you buy PlanetScale, you’re getting the technology and database expertise that ran and scaled YouTube, the internet’s #2 site, and the team that scaled GitHub to over 100M users globally.– Todd Berman @Attentive PerformancePlanetScale Metal allows you to run your database on the fastest servers available in the cloud. Our blazing fast NVMe drives unlock unlimited IOPS and drastically lower la
はじめに アドバイザリーロックとは、並列処理で排他的に操作を行うためのロックの一種です。しかし、インターネット上のアドバイザリーロック解説記事は抽象的な情報が多く、わかりにくく感じました。そこで、この記事では具体的な例や図を交えながら MySQL のロック関数を使ってアドバイザリーロックを実現する例を紹介します。 MySQL のロック関数 アドバイザリーロックはファイルロックのようなシンプルな方法でも実現できます。しかし、ここでは MySQL がサポートしているロック関数 GET_LOCK, RELEASE_LOCK を使って実現します。これらのロック関数は、データベースと密接に結びつくトランザクションや、行ロックなどとは異なり、特定の行や特定のテーブルと結びつくことはありません。 ロック関数はとてもシンプルです。GET_LOCK でロックを取り RELEASE_LOCK でロックを解放し
こんにちは。スマートバンクのサーバーサイドエンジニアをやっておりますid:moznionです。 すっかり秋めいてきましたね。秋といえばMySQL*1、ということで今回は先日解消した「MySQLのロックに起因するブロックタイムアウト」のトラブルシューティングついて記していきたいと思います。 事の発端 ある時を境にSentryに ActiveRecord::LockWaitTimeout というエラーがしばしば報告されるようになっていました。 SentryにActiveRecord::LockWaitTimeoutが上がってきている様子 Mysql2::Error::TimeoutError: Lock wait timeout exceeded という文言から、MySQL上でロックを取っている他のクエリにブロックされ、そのブロックが長時間に渡ったため自クエリがタイムアウトしてabortしてし
こちらに引き続き、以前サポートされた機能の再発掘です。MySQL 8.0.1 でサポートされた機能なので CHECK 制約よりも古いです（笑）。 ※配布開始 1 周年を迎えた「MySQL 8.0 の薄い本」を、8.0.20 対応版改訂を機にリニューアルし、実行例を増やすための記事です。はい。 「MySQL 8.0 の薄い本」を作って配っている話 NOWAIT / SKIP LOCKEDの使いどころ トランザクション内で、 テーブルにある行の情報を取得する その行に対して更新を掛ける 場合には、 SELECT ... FOR UPDATEでロックを獲得する （取得した情報を加工するなどして）UPDATEする という流れになりますが、他のトランザクションが先に当該行のロックを獲得していた場合、 先行して行ロックを獲得したトランザクションがロックを開放する ロックがタイムアウトする まで待たされ
運営元のロゴ Copyright © 2007-2025 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
MySQL/Aurora/TiDBロック入門 – 第３回ロック読取りも SELECT は止められない【解説動画付】 MySQL とその互換 DB のロックの挙動を紹介する入門シリーズ、第３回は第２回で紹介したロックモニターを使って、業務ではよく使われているロック読取りについて解説します。 ロック読取りは、ゲームのバックエンドサーバーなど「同時に多数の処理をこなすけど、データとしての一貫性も重要」な場合に必須となるテクニックです。既に使っているという方も復習を兼ねてぜひご覧ください！ ★ 第１回 トランザクション分離レベル ★ 第２回 ロックモニターの読み方 ★ 第３回 ロック読取りも SELECT は止められない ★ 第４回 INSERT を止めるインテンションロック ★ 第５回 WHERE 条件と違うロック読取り ★ 第６回 performance_schema ★ 第７回ギャップロック
はじめに こんにちは、バックエンドエンジニアのSakiです！バックエンドでPHPを書いたり、PHPという言語そのもののメンテナーもしています。 この度、注文データダウンロードAppのパフォーマンスをアップさせるため、とても入念にデータベースまわりの処理を見直しました。その中でも特に速度に関わってくる「index」についての考え方をまとめたいと思います。 この記事はMySQL（InnoDB）についての記事であり、他のRDBについては当てはまらない場合もあるということにご注意ください。 indexとは何か、おさらい ご存知の方ももちろん多いと思いますが、indexについておさらいさせてください。 indexとは辞書でいうところの目次に相当するもので、目的のデータをいち早く検索するために重要なものです。もし辞書に目次が存在しなかった場合、目的の情報を探すのにとても苦労するだろうというのは想像しや
MySQL/Aurora/TiDBロック入門 – 第１回トランザクション分離レベル MySQL InnoDB および AWS Aurora や PingCAP TiDB におけるロックの仕組みやトランザクションの動作を全１１回のシリーズで解説します！ 最初はベースとして重要な MySQL 8.0 InnoDB 前提でユーザー視点でのロックの仕組みを学び、後半第１０回以降では MySQL 互換 DB として人気の高い AWS Aurora や PingCAP TiDB と MySQL InnoDB との違いについて学びます。 １回目の今回はロック機構と切っても切り離せないトランザクションとその分離レベルについて、実際に挙動を確かめながら解説します。ライブ感のある説明も理解に役立ちますので、解説動画も付けてみました。合わせてご覧ください！ ★ 第１回 トランザクション分離レベル ★ 第２回 ロ
初めてのPerformance Insights入門 – その3 | Amazon Web Services
Amazon Web Services ブログ 初めてのPerformance Insights入門 – その3 テクニカルソリューションアーキテクトの笹川です。 前回は初めてのPerformance Insights入門 – その2 と題してPerformance Insightsと拡張モニタリングを使ってデータベースのパフォーマンスチューニングを行ってみました。パフォーマンスチューニングをする際に何を手がかりにどう確認していくのか、少しでもイメージを掴んで頂けていたら幸いです。今回も引き続き、色々なシナリオを検討しながらPerformance Insightsを使ってパフォーマンスチューニングを行ってみたいと思います。 検証環境と注意事項 本記事では下記の環境で検証を行なっていきます。 RDS MySQL8.0.23 db.m3.medium (1vCPU, メモリ3.75GiB) プ
初めてのPerformance Insights入門 – その２ | Amazon Web Services
Amazon Web Services ブログ 初めてのPerformance Insights入門 – その２ テクニカルソリューションアーキテクトの笹川です。 前回は初めてのPerformance Insights入門と題してPerformance Insightsの基本的な見方や使い方をご紹介させて頂きました。Performance Insightsで何が確認できるのか、待機イベントとは何か、Performance Schemaと何が違うのか、少しでもイメージできるようになって頂けていれば幸いです。 今回は少し進んでPerformance Insightsを使ってデータベースのパフォーマンスチューニングを行ってみましょう。データベースのパフォーマンスチューニングを行ったことがない、どう考えれば良いかわからない、どこから手をつけたら良いのかイメージできない、という方の為に比較的簡単な例
こんにちは！DBREの福間（fkm_y）です。先月、弊社でデータベースの技術顧問をして頂いてる三谷（mita2）さんに開発本部向けの「MySQL SQLチューニング」勉強会を実施していただきました。 今回はMySQLの得意不得意なことの説明やSQLチューニングの流れ、具体的な事例を元にした対応例、また最近話題のHTAPな製品も紹介していただきとても参考になったのでポイントをおさえてレポートをお伝えします！ 開催背景 本編 MySQL の得意なこと、苦手なこと データベースのチューニング手段と特徴 SQLチューニングの流れ インデックス SQLチューニング例 インデックスフルスキャンとカバーリングインデックス ソート まとめ 当日の資料 さいごに 過去開催されたデータベース勉強会レポート 開催背景 弊社では三谷さんによるデータベース勉強会を定期的に開催しています。数年前にも同じテーマで勉強会
MySQLのCOUNTを速くする（？）SQL1本ノック その1
この記事は MySQL Casual Advent Calendar 2016 の19日目の記事です。 「MySQLのCOUNTが遅いなー」って言うと、「トリガーでサマリーテーブル作ったら？」と言われること、多くありませんか？ 特に @soudai1025 に言われる率が高い気がしています（個人の感想です） 個人的にはトリガーよりは同じトランザクションの中でカウンターテーブル（サマリーテーブルと違うもののつもりで言ってるけど、世の中でいうサマリーテーブルの中にはこの形式が含まれるかも知れない）をUPDATEする方が好き（だって、トリガーはブラックボックスになるんだもの）なんですが、頭の体操ということでトリガーで組んでみましょう。 サンプルテーブルはこんな感じ。 mysql57> SHOW CREATE TABLE game_score\G *************************
MySQLの抽出条件の指定方法としてIN句とFIND_IN_SET関数というものがあります。 その具体的な使用方法をご紹介します。 サンプルとしてテーブル「sample」を用意します。 mysql> select * from `sample`; +----+--------+------+ | id | name | type | +----+--------+------+ | 1 | 赤井 | 1 | | 2 | 井田 | 2 | | 3 | 宇野 | 3 | | 4 | 江崎 | 1 | | 5 | 奥本 | 2 | +----+--------+------+ 例えば、idが1・2・4のデータを取得したいとき、 IN句を使うとこのように抽出することができます。 SELECT * FROM sample WHERE id IN (1, 2, 4); 結果は以下のようになります。 +
はじめに MySQL(InnoDB)でSQLのパフォーマンスチューニングをするときに役に立つ知識をエッセンスとしてまとめました。結合(JOIN)やB-treeインデックスの探索の仕組み、実行計画の基本的な見方を紹介します。 想定する読者は、SQLのパフォーマンスを改善する必要があるが実行計画をみてもいまいちピンと来ない方です。インデックスの作成の経験や、複合インデックスやカーディナリティの知識があることを前提にしています。目標は、実行計画の内容がよく分からない読者が、実行計画をみただけでクエリが実行される様子をイメージでき、自信を持ってクエリの改善にあたることができるようにすることです。 ストレージエンジンはInnoDBを前提としています。また、インデックスはB-treeインデックスを想定しています。全文検索の転置インデックスや空間検索のR-treeインデックスについては触れません。 イン
1. インデックス MySQLで利用可能なインデックスは一部を除き、B-Treeインデックスと呼ばれる構造でできてます。Bツリーインデックスは、ブランチノード(ブランチ), リーフノード(リーフ)で構成されており、ルートノードから数ステップで目的のデータに到達することができます。 データの格納とアクセス方法 クラスタインデックス MySQLのInnoDBストレージエンジンでは、すべてのテーブルは主キー（PRIMARY KEY）によるクラスタインデックスを持ちます。クラスタインデックスとは、データ行が主キーの値によって物理的に順序付けられた状態のことを指します。このため、主キーによる検索は非常に高速です。 セカンダリインデックス セカンダリインデックスは、クラスタインデックス以外のすべてのインデックスを指します。セカンダリインデックスのリーフページ（最下層のインデックスページ）には、インデッ
エンジニアの小張です。多くのデータを扱うアプリケーションにとって、ユーザーが求めるデータを返すまでの速さは生命線とも言えます。 試行錯誤を重ねデータの蓄積量が増えれば増えるほど、アプリケーションが使いづらくなってしまったら、悲しいですよね。。。 今回はそんなレスポンス速度向上に必須の知識であるインデックスについて、構造からおさらいしていきたいと思います。 インデックスとは、 データベース上でのSELECT、WHEREなどの操作による データの集計・検索の高速化に貢献する技術の1つです。 ここでは、MySQLで使用されるInnoDBのインデックスについて説明します。 B+木(B+Tree)について MySQLのInnoDBエンジンで使われるインデックスは、B+木というデータ構造で実装されています。 InnoDBのインデックスは、以下の種類があります。 クラスタインデックス セカンダリインデッ
クエリの抽出結果を並び替える（ソート）にはORDER BY句を使用します。MySQLではこのソートは高コストな処理のため、ソートするカラムに対してインデックスを貼ることが定石です。たとえば、以下のように 作成された記事に対して最新順に10件の取得クエリがあったとします。 mysql> SELECT * FROM article ORDER BY created_at DESC LIMIT 10; この場合は、created_atにインデックスを貼ることでソート処理を排除することができます。というのも、インデックスはすでにソート済のデータが格納されているので、先頭から順番に辿れば良いだけなのです。 さらに、MySQL 8.0とそれ以降からはDESCENDING INDEX機能が追加されたので、今回の場合はそちらを使用すると、より効果的に処理されます。また、インデックスを使用したソート処理はy
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
