Ultimate Guide to Improving MySQL Query Performance
MySQL is certainly a powerful open source database management system, but even the most robust engine struggles when queries take an eternity to execute. For DBAs and developers, improving MySQL query performance is an ongoing goal. Efficient query performance is crucial for ensuring the smooth operation and optimal user experience of applications powered by MySQL databases. When businesses rely h
準同期レプリケーションで、でかいテーブルをDROP TABLEした時の死にポイント on 5.7.34
準同期レプリケーションで、でかいテーブルをDROP TABLEした時の死にポイント on 5.7.34 TL;DR dict_sys のmutexを取るのでDDL系は死ぬし新しくテーブルキャッシュを作れないのでテーブルキャッシュが枯渇すると死ぬ ROLLBACK も dict_sys のmutexを取るので死ぬ。 COMMIT はできる。 実はGroup Replicationまたは準同期レプリケーションを使っていると、更新系DMLの中に dict_sys を使う処理が追加されるのでこっちはいきなりDMLが刺さる。 試したのは5.7.34だけ。他のバージョンの動作は知らない。この動作は単純にunlink中のmutexの話なので、バッファプールの大小にはよらない。【2022/08/01 11:21】この実験は単純にunlinkを遅延させて測っているだけなので、バッファプールの大小はまた別の問
知って得するInnoDBセカンダリインデックス活用術！
InnoDBはクラスタインデックスという構造になっている。今日はクラスタインデックスがどういうことかということを、皆さんに理解して頂きたい。もっとも理解して頂きたいポイントは「セカンダリインデックスのリーフノードには主キーの値が含まれている」ということだ。 主キーの構造InnoDBの主キーは次の図のように「データが主キーのリーフノードに含まれる」という構造になっている。このような構造をクラスタインデックスという。 このような構造になっていることには利点と欠点があるが、大きな利点は主キーの値で検索をすると非常に高速だということだ。主キーのリーフノードにたどり着いたときには、既にデータのフェッチも完了している。データとインデックスが別々に格納されているタイプのストレージエンジンでは、インデックスからデータの位置を読み取って、その後データファイルからデータをフェッチする。このように二段階の操作が
ソシャゲエンジニアの自分が開発に必須だなと思った知識（MySQL編） - Qiita
この記事の目的 自分は、とある会社様の元でソシャゲの API 開発をさせていただいています。 ソシャゲは、リリース時やイベント時などに集中アクセスされやすく、負荷軽減の知識がない状態で開発を行ってしまうと、運用時に緊急メンテ祭りになりやすいジャンルかなと思っています。 これまで培ってきた MySQL の知識ですが、脳内メモリ量の関係上、暗記できないのでメモしておこうというのが主目的です。 ここ数年ほどソシャゲ開発しかしていないため、偏っている感がある内容ですのでご注意ください。 概要 ストレージエンジンは InnoDB。メインで扱っている MySQL バージョンは 5.6。 記事の内容ですが、これらのキーワードを見て、おおよそ分かる方は読む必要はないかと思います。 インデックス系 クラスタインデックス カバリングインデックス EXPLAIN で注意するべき値 トランザクション系 MVCC
MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.3.1 MySQL のインデックスの使用の仕組み
インデックスは特定のカラム値のある行をすばやく見つけるために使用されます。 インデックスがないと、MySQL は関連する行を見つけるために、先頭行から始めてテーブル全体を読み取る必要があります。 テーブルが大きいほど、このコストが大きくなります。 テーブルに問題のカラムのインデックスが含まれている場合、MySQL はすべてのデータを調べる必要なく、データファイルの途中のシークする位置をすばやく特定できます。 これはすべての行を順次読み取るよりはるかに高速です。 ほとんどの MySQL インデックス (PRIMARY KEY、UNIQUE、INDEX、および FULLTEXT) は B ツリーに格納されます。 例外: 空間データ型のインデックスは R ツリーを使用します。MEMORY テーブルはハッシュインデックスもサポートします。InnoDB は FULLTEXT インデックスの逆のリスト
[MySQL Workbench] VISUAL EXPLAIN でインデックスの挙動を確認する
Lookup: where col = 1 のような等価比較 VISUAL EXPLAIN でインデックスの挙動を確かめる（本題） 本題です。青→赤の順にコストが大きいことだけ分かっていれば、詳細に見方を覚えなくても使えます。 今回使うのは下の2つのテーブルです。どのユーザがコンバージョンしたかを持っておく cv テーブルと、それが紐付く広告の ad テーブルです。 今回実験のためにざっくり作成したデータについて下に列挙します。 インデックスは簡単のためこの時点で PRIMARY KEY のみ cv は約100万件、 ad は約4000件 cv の status と ad の type はそれぞれ10種類で偏りなし 時刻を保存するカラムは UNIX TIME でここ一ヶ月のデータを格納 ER 図はせっかくなので MySQL Workbench で出力しました。 Workbench は外部キ
![[MySQL Workbench] VISUAL EXPLAIN でインデックスの挙動を確認する](https://cdn-ak-scissors.b.st-hatena.com/image/square/c361eb0b9ed35a0934d2f7c1e008d4330adf3c7c/height=288;version=1;width=512/https%3A%2F%2Fvos.line-scdn.net%2Flandpress-content-v2_1761%2F1666852622685.png%3FupdatedAt%3D1666852623000)
RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
MySQLのexplainとかについてしらべたときのメモ - Qiita
namespace :insert do task do: :environment do carriers = ['a', 'b', 'c'] (1..1000000).each do |i| u = User.create(name: "name#{i}", carrier: carriers[rand(3)]) u.created_at = DateTime.now - rand(365*24*3600).second u.save end end end レコード数: 100万件 carrier(簡単のためにとりあえず"a","b","c"の3種類を取るということにした) created_atはとりあえず現在から一年以内とした(DateTime.now - rand(365*24*3600).second) 結果 クエリ select carrier, date(created_a
Using filesort
去年ソートに関する記事を書いたが、今日はその続きである。 MySQLでEXPLAIN SELECT...を実行するとExtraフィールドでよく見かける「Using filesort」という文字列。Filesortって一体なんだろう？と思ったことはないだろうか。単刀直入に言ってFilesortの正体はクイックソートである。 クエリにORDER BYが含まれる場合、MySQLはある程度の大きさまでは全てメモリ内でクイックソートを処理する。ある程度の大きさとはsort_buffer_sizeであり、これはセッションごとに変更可能である。ソートに必要なメモリがsort_buffer_sizeより大きくなると、テンポラリファイル（テンポラリテーブルではない）が作成され、メモリとファイルを併用してクイックソートが実行される。 Filesortは全てのソート処理において実行されるわけではない。前回の記事
オトコのソートテクニック2008
今日は仕事納めだったので、一年の締めくくりとしてMySQLにおけるソートの話でもしようと思う。 インデックスを利用しないクエリで最もよく見かけるもののひとつは、ORDER BYを用いたソート処理だろう。もし、ソート処理においてインデックスを用いることが出来れば、MySQLは結果を抽出してから結果行をソートするのではなく、インデックス順に行を取り出せば良いので高速にソート処理することが可能になる。特に、LIMIT句やWHERE句を用いて行の絞り込みを行う場合は効果が絶大である。しかし、ひとたびインデックスを利用できない状況に直面すると、たちまちテーブルスキャンが発生して性能が劣化してしまう。 例えば、100万行のレコードを格納したt1というテーブルがあるとする。そのテーブルに対して以下のようなクエリを実行した場合を考えよう。 mysql> SELECT col1, col2 ... colx
[MySQL]WHERE句とORDER BY句の両方が使われている場合のINDEX
INDEXを追加することでWHERE句でのレコードの絞り込みが速くなることは、SQLを少しでも学んだことのある人なら当たり前に知っていることだと思う。 システムを運用していく期間が長くなればなるほどレコード数は膨大になり、WHERE句で絞り込んだとしても結果として返されるレコード数が多くなってしまうこともある。 単純に絞り込んだ結果を並び順関係なく出力させる場合は問題ないが、WEBシステムやアプリなどでは、登録された日付が近いもの順でソートしたい場合や、IDが若い順でソートしたい場合など、出力結果をソートしたい場合が多々ある。 そんな時はクエリにORDER BY句を記述することで対処することがあると思うが、実はこのORDER BY句によるソートがボトルネックの原因になってしまうことがある。 WHERE句で指定しているカラムにINDEXが張ってある場合以前の記事で利用したsampleテーブル
![[MySQL]WHERE句とORDER BY句の両方が使われている場合のINDEX](https://cdn-ak-scissors.b.st-hatena.com/image/square/2f5ca69a1238ee65350cee5bf801c4b58342fe81/height=288;version=1;width=512/https%3A%2F%2Fdaybydaypg.com%2Fwp-content%2Fuploads%2F2017%2F08%2Fmysql.png)
大きめのテーブルにカラムやインデックスを追加する際の注意 - LukeSilvia’s diary
先日大きめ(といっても500万行くらい)のテーブルにインデックス付きのカラムを追加しようとして痛い目にあったので調査。 大きめのテーブルにカラムやインデックスを追加するとどうなるか 今回は単純に、「ALTER TABLE 〜 」で追加しようとしました。追加するカラムは3つで、 varchar(255) インデックスなし varchar(255) ↓のdate 型カラムとマルチカラムインデックスの形式のユニークインデックスあり date インデックスあり SQL を実行し、状況を「SHOW PROCESSLIST」で監視していたら、1つ目のカラム追加で次のような状態に… 最初にState が「copy to tmp table」状態になり、次の状態に遷移するまで1時間かかる 次にState が「Repair with keycache」状態になり、完了までに1時間かかる 次のカラム追加に対す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
