deleted_atにインデックスを雑に貼ったら本番DBが死んだ
RDSが朝のピーク時間帯にI/Oスパイクで応答不能になりました。前日夜にリリースしたdeleted_atへの単独インデックスが原因です。stagingのEXPLAINでは複合インデックスが正しく選択されていたので、レビューでは検出できていません。 根っこにあるのはMySQL 8.0 innodb_stats_methodのデフォルト値nulls_equalと、IS NULLに対するコスト計算の噛み合わせです。8.0系で現在も未修正のバグに類する挙動で、NULL多数カラムへの単独インデックスがトリガーになります。 テーブルとクエリ 問題が起きたのはチケット管理SaaSのticketsテーブルです。ソフトデリートでdeleted_atを持つよくある設計です。 CREATE TABLE tickets ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, w
MySQLが好きな私が、今はPostgreSQLを勧めたい理由
私はMySQLが好きです。長く使ってきましたし、オンプレミスでの運用もやってきました。 しかし現職に来てからは、PostgreSQLを使う機会が増えました。最初は正直かなり抵抗感がありました。ずっとMySQLを使ってきたので、慣れの問題もありますし、PostgreSQLに対して必要以上に構えていたところもあったと思います。 ただ、実際に使っていくうちに、PostgreSQLの良さが少しずつ見えてきました。最近では、新規開発でどちらを選ぶかと聞かれたら、PostgreSQLを選びたいと思うようになっています。 私はMySQLを長く使ってきたので、昔のMySQLの雑さも知っています。ただ同時に、今でも昔の印象だけでMySQLを語るのは不正確だとも思っています。sql_modeをきちんと設定すれば危ない挙動の多くは避けられますし、MySQL 8でかなり多くの機能が入りました。 また、今回はオンプ
それでも外部キー制約は必要ない / #fk_night でしゃべってきました
11年ぶりに外部キーNightが帰ってきます。 (前回のイベントはこちら: https://connpass.com/event/11463/) この11... 外部キーに対する思いをたくさん聞けて大変に楽しい会でした。自分も言いそびれたり、盛り込めなかった内容がたくさんあるので、ここで補足しようと思います。 何が言いたかったの 外部キー制約は運用上の障壁になるだけでなく、整合性を守る仕組みとしては力不足すぎる。システム全体のことを考えたとき、不変条件はアプリケーションにエンコードせざるを得ないのだから、そちらに寄せるほうが合理的。 でした。 一定の害が存在することについては、会の中でも認められていたように思います。スキーマの変更を阻害するだとか、パーティショニングできなくなるとか、特にMySQLでは性能劣化が大きいとか、そういうやつです。懇親会でも「トレードオフとして受け入れられる」とい
MySQLの速度改善に役立つチェックリスト6項目
MySQLの速度を改善するために確認すべき項目として、以下の6つが挙げられます。 グローバルバッファのサイズは適切か スレッドバッファのサイズは適切か クエリは適切か インデックスを適切に設定できているか 適切なストレージエンジンを選択しているか チューニングツールを活用しているか下記ではそれぞれの項目について解説します。 グローバルバッファのサイズは適切かグローバルバッファとは、MySQLサーバー全体に適用されるバッファのことです。 一般的に、データアクセスの際に都度データベースにアクセスするよりもバッファから読み込む方が早いため、バッファを用意することがMySQLの速度改善に繋がります。 しかし、この値を大きく設定しすぎると、サーバー本体の空きメモリが不足する可能性があるため一概に大きい値に設定すれば良いというわけではありません。 代表的なグローバルバッファの項目は以下の通りです。 変
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
Amazon Aurora MySQL データベース設定のベストプラクティス | Amazon Web Services
Amazon Web Services ブログ Amazon Aurora MySQL データベース設定のベストプラクティス AWS クラウドで新しい Amazon Aurora MySQL インスタンスを移行または起動した後、以下の質問のうち 1 つ以上を自問したことはありますか? 「次のステップは? どうすれば、最適に動作させることができるでしょうか?」 「既存のパラメータを変更する方が良いでしょうか?」 「どのパラメータを変更すれば良いでしょうか?」 自問したことがあるなら、何をすべきか（そして、何をすべきでないか）について、このブログ記事がガイダンスを提供できることを願っています。 この記事では、MySQL との互換性を持つ Amazon Aurora の設定パラメータについて説明、明確化し、推奨事項を提供します。こうしたデータベースパラメータとその値は、AWS クラウドで新しく作
Repro で遭遇した Aurora MySQL にまつわるトラブル 5 選 - Repro Tech Blog
こんにちは、Platform Team の荒引 (@a_bicky) です。前回は続・何でも屋になっている SRE 的なチームから責務を分離するまでの道のり 〜新設チームでオンコール体制を構築するまで〜という話を書いたんですが、今回は Repro の運用に 7 年以上携わる中で私が遭遇して印象的だった Aurora MySQL 絡みのトラブルについて紹介します。 Aurora MySQL が詰まってデータ処理のスループットが下がるとか、API のレスポンスが遅くなるとか、ALTER TABLE する度にアプリケーションエラーが発生するとか、胃が痛くなる胸が熱くなる話が多いので、Aurora MySQL を利用していなくても楽しんでいただけるのではないかと思います。Aurora MySQL を利用している方であれば参考になる情報もあるでしょうし、通常の MySQL にも適用可能な話もあります
Ultimate Guide to Improving MySQL Query Performance
Have you ever waited far too long for a MySQL query to finish and wondered if there’s a better way? If you manage a MySQL database or build apps that depend on one, you know how slow queries can grind everything to a halt. Users get frustrated, response times creep up, and suddenly you’re dealing with support tickets instead of focusing on new features. Maybe you’re seeing queries that used to fly
explainだけじゃわからない！MySQLのindexの考え方 - BASEプロダクトチームブログ
はじめに こんにちは、バックエンドエンジニアのSakiです！バックエンドでPHPを書いたり、PHPという言語そのもののメンテナーもしています。 この度、注文データダウンロードAppのパフォーマンスをアップさせるため、とても入念にデータベースまわりの処理を見直しました。その中でも特に速度に関わってくる「index」についての考え方をまとめたいと思います。 この記事はMySQL（InnoDB）についての記事であり、他のRDBについては当てはまらない場合もあるということにご注意ください。 indexとは何か、おさらい ご存知の方ももちろん多いと思いますが、indexについておさらいさせてください。 indexとは辞書でいうところの目次に相当するもので、目的のデータをいち早く検索するために重要なものです。もし辞書に目次が存在しなかった場合、目的の情報を探すのにとても苦労するだろうというのは想像しや
Performance Schemaの仕組みと活用法の紹介 - freee Developers Hub
メリークリスマス！！freee Developers Advent Calendar 2022 25日目担当のid:shallow1729です！昨日はtdtdsさんでfreee特有の風土病：エンジニアの症例と寛解についてでした！ 僕からはMySQLのPerformance Schemaという機能の仕組みの解説とfreeeでの活用についての紹介をします。 前置き Performance SchemaはMySQLで実行されるトランザクションやクエリなどの実行時の様々な情報を取得してくれる機能です。特に面白いのは後で説明するようにstageやwaitなどのMySQLの実装レベルでのモニタリングを提供してくれているところで、これを使う事でどのあたりがボトルネックになっているかについて実際のProduction環境のワークロードで分析できる点です。また、最近だと例えばAWSのRDSを用いているとPe
サブクエリの書き方を2万文字弱かけてすべて解説する
これはなに ども、レバテック開発部のもりたです。 今回はSQLのサブクエリについてまとめます。仕事でクエリを書く際、サブクエリは頻出の構文だと思うんですが、同時にサブクエリの書き方を完全に理解しているよという人は案外少ないのではないでしょうか？[1] 実際、MySQLの公式ドキュメントを見ると12ページくらいを割かれており、意外と奥深いのがサブクエリです。使いこなせると便利ですし、何よりちょっとSQLのコツみたいなのがわかって面白いよ、ということで記事にしてみました。 前提 この記事は以下の前提を含んでいます。 環境 MySQL8.0系 読者の知識 なんとなくサブクエリが書ける けど相関サブクエリとかになると「あーっ」つってGoogle meetを閉じてしまうくらいのレベル感 記事のボリューム 18,000文字 おれの卒論が20,000文字だった マサカリ 間違ってたら投げてくれ〜〜 それ
MySQLのSQLクエリチューニングの要所を掴む勉強会を開催しました！ - ANDPAD Tech Blog
こんにちは！DBREの福間（fkm_y）です。先月、弊社でデータベースの技術顧問をして頂いてる三谷（mita2）さんに開発本部向けの「MySQL SQLチューニング」勉強会を実施していただきました。 今回はMySQLの得意不得意なことの説明やSQLチューニングの流れ、具体的な事例を元にした対応例、また最近話題のHTAPな製品も紹介していただきとても参考になったのでポイントをおさえてレポートをお伝えします！ 開催背景 本編 MySQL の得意なこと、苦手なこと データベースのチューニング手段と特徴 SQLチューニングの流れ インデックス SQLチューニング例 インデックスフルスキャンとカバーリングインデックス ソート まとめ 当日の資料 さいごに 過去開催されたデータベース勉強会レポート 開催背景 弊社では三谷さんによるデータベース勉強会を定期的に開催しています。数年前にも同じテーマで勉強会
MySQLでIn句に大量の要素を渡すとまずい理由
概要 MySQLでIN句を使用する時はIN句に渡す要素数に注意する必要があるとよく先輩エンジニアの方から聞いていたのですが、実際に大量の要素を渡すと何がまずいのかはっきり分かっていなかったので調べてみました。 この記事で伝えたいこと MySQLでIn句に大量の要素を渡すとまずい理由 まずい状況を回避するために気をつけるべきポイント 先に結論 MySQLでIN句に大量の要素を渡すとインデックスを貼っていたカラムだとしてもフルスキャンが発生しスロークエリになる可能性があります。 フルスキャンが発生してしまう条件はテーブルに設定してあるインデックスの内容とrange_optimizer_max_mem_size の設定値に依存しており、MySQL8でデフォルトの設定値 & シンプルなテーブルであってもおおよそ数万件の要素数をIN句に渡すとフルスキャンが発生する可能性があると考えられます。 検証環
MySQL(InnoDB)のSQLパフォーマンスチューニングのエッセンス
はじめに MySQL(InnoDB)でSQLのパフォーマンスチューニングをするときに役に立つ知識をエッセンスとしてまとめました。結合(JOIN)やB-treeインデックスの探索の仕組み、実行計画の基本的な見方を紹介します。 想定する読者は、SQLのパフォーマンスを改善する必要があるが実行計画をみてもいまいちピンと来ない方です。インデックスの作成の経験や、複合インデックスやカーディナリティの知識があることを前提にしています。目標は、実行計画の内容がよく分からない読者が、実行計画をみただけでクエリが実行される様子をイメージでき、自信を持ってクエリの改善にあたることができるようにすることです。 ストレージエンジンはInnoDBを前提としています。また、インデックスはB-treeインデックスを想定しています。全文検索の転置インデックスや空間検索のR-treeインデックスについては触れません。 イン
毎日本番DBをダンプして、ローカルと開発環境で利用して生産性を上げてる話
シードデータで動作確認して大丈夫だったのに、本番反映してみたら想定してなかった挙動・エラーが出た😱そんな経験はありませんか。 恥ずかしながら私は今までに何回もありました。機能開発だけじゃなくバッチやマイグレーションなんかでも発生しがちなコレ。またはシードデータで動作確認できても、本番データでも通用するか検証ができないままプルリクを作る、なんていうこともあると思います。今回はこちらを無くす試みをしたお話です。 「もう本番DBで開発しちゃえばいいじゃない」の問題点 この課題を解決するには、極論すると本番DBで開発するしかないのですが、そうなると言うまでもなく以下の問題が出てきます。 レビュー通過してないコードが本番に影響を与える トライ＆エラーができない 個人情報をはじめとするセンシティブな情報が開発者の端末に漏れる データ量が多すぎてローカルに持ってこれない しかし言い換えると、これらをク
Docker containerからhostのMySQLに接続する
container同士やhostからmysql containerの接続は簡単ですが、逆にcontainerからhostにアクセスする時に色々詰まったので、書き残しておきます。 参考記事 https://xyk.hatenablog.com/entry/2013/11/08/142548 参考記事 https://sam-ngu.medium.com/connecting-to-docker-host-mysql-from-docker-container-linux-ubuntu-766e526542fd 環境 Ubuntu 20 MySQL 5.7 Docker 20.10.11 docker-compose.yml version: '3' services: app: # 省略 networks: app_net: ipv4_address: 172.28.1.5 # <- 固定I
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データベースでユニークキーにUUIDを使うメリットは何ですか？連番やタイムスタンプまたは複合などではいけないのでしょうか？どうも視認性が悪く使いにくく感じますし連番でも衝突しない気もします。
RDS for MySQLでスロークエリログを出力させる - Qiita
MySQL: インデックスなき派生テーブルをなくしてクエリ速度を改善 - Qiita
mysqldumpで特定のプリフィックスがあるテーブルを除外しようと思ったら、意外と深かった。 - Qiita
