はてなブックマーク

この記事は Lancers（ランサーズ） Advent Calendar 2020 6日目のエントリーです。 バックエンドエンジニア＆DBRE の まみー です。 僕は MySQL が大好きです。 普段 ORM 任せでクエリを意識しないことも多い昨今。 だからこそクエリ 1 とインデックス 2 くらいはわかる僕らでありたいと思うんですが、思ってたんと違うインデックスが選択されることありますよね。 じゃあ理由を明確にして本質を知った上で対応しよう。 というわけでインデックス選択の根拠をオプティマイザが算出するコストから検証してみます。 オプティマイザトレースの使い方をサクッと知りたい方は コチラ からご覧ください。 条件 単一テーブル 複合インデックス 1番目で ID で絞り込み 2番目で前方一致 LIKE 検索 実例 3 として、TODO管理情報を ユーザーID キーワード前方一致 で検索

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 2017/12/04 追記 レプリケーションの手順に誤りがあります。 無停止で前日のdumpからスレーブを作って同期をとった、から ↓↓↓↓↓↓↓↓↓ メンテナンスモードでマスターへの更新を止めた状態でdumpをとり、スレーブを作って同期 その後にメンテナンスモードをオフして、マスターへの更新を再開 という内容に更新予定です。 設定当時はよくわかっておらず、最初は更新を止めずに雑にレプリケーションしていました。 結果、複数のレコードを喪失したままレプリケーションが実行されていたので、やり直しています。 はじめに my.cnf のチューニ

花粉真っ盛り。 もれなく花粉症MAXな日々を過ごしております。 まみーです。 前回のエントリーからの続きになります。 MySQLパフォーマンスチューニング -my.cnfの見直し- 今回は、前回の設定結果の中から、クエリキャッシュの効き具合を測定・検証していきます。 概要 my.cnf に設定した内容のうち、クエリキャッシュについて検証します。 前回の設定変更から1週間経過した時点での値の比較となります。 目的 設定されていなかったクエリキャッシュが適切に効いているのかを検証し、設定が妥当かどうか判断します。 問題点 サービスの運用上、以下の問題点があります。 変更できない テーブル構成 リクエストごとに増え続ける ログレコード 必要な リアルタイム検索機能 状況 クエリキャッシュ設定前の状況は以下でした。 リアルタイム検索を 複数実行するとサーバーが落ちる 1プロセスでも 応答に30秒

※RDSは使っていません。 負荷を見てみる DBサーバーの負荷状況を見てみます。 当時の監視ツールの画像がないのですが、以下の状況でした。 LA(Load Average)が突き抜けている リクエスト数は「常識的に考えて」それほどでもない メモリの使用量にあまり変化がない swapはしていない ストレージ容量を結構食っている WEBサーバーから見れば、処理待ちのままプロセスが処理されていない典型的なパターンだったと思います。 DBサーバーとしては、LAに対し、メモリの使用量があっていないように思われました。 仮説 上記の状態から、仮説を立てます。 スロークエリ が頻発しているのではないか メモリ が正しく割り当てられていないのではないか 各種ログ の設定が適切ではないのではないか 仮説を検証することで、対策をしていきます。 設定を見直す 上記の仮説の設定は、MySQLの設定ファイルである「