MySQLでNested Loopなクエリはインデックスをどう辿っているか - $shibayu36->blog;
タイムライン的なものを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
1文字でSQLを200倍遅くする方法
こんにちは、19のSysAd班の翠(sappi_red)です。普段はtraQのフロントエンドの保守を行ったりしています。 こんばんは、19のSysAd班のtemmaです。普段は普段どおりのことをしています。この記事の面白い部分はすべて僕が書いています。面白くないところは翠君が書いています。 この記事では、日々パフォーマンスに頭を悩ませる開発者の方のために、ワンタッチで劇遅SQLを200倍高速でキュートなSQLに劇的ビフォーアフターする方法を紹介します。 「おいおいおい、遅くしたくて記事を読み始めたのに話が違うじゃないか💢」と思ってるそこのあなた👈 早くできるということは遅くもできるんですね。 TL;DR ここにテーブルがあります。 CREATE TABLE messages ( id CHAR(36) NOT NULL PRIMARY KEY, text TEXT COLLATE ut
MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な
![MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5e9d48c3c6f38c2d5f71897d98efcb251289d1f9/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2021%2F07%2Fboard-755792_800.jpg)
MySQL で使用するメモリサイズの見積もり - 元RX-7乗りの適当な日々
最近、MySQLのパラメータの調整をする機会があったのですが、特定のパラメータを変更した際に、メモリの消費量にどう影響するのか、というのを調査する際に、インターネッツを彷徨ったところ、サイトによって書いてあることにバラつきがあったので、自分でもまとめてみることにした。 結論から書くと、参考にしたのは以下のオライリーの書籍「MySQLトラブルシューティング」で、記述が一番わかりやすく書かれていた。 このエントリは、この書籍の 「3.9.3 オプションの安全値を計算する」 にて記載がある内容をまとめたものになる。 MySQLトラブルシューティング 作者:Sveta SmirnovaオライリージャパンAmazon 著者について Sveta Smirnova(スヴェータ・スミルノヴァ): Oracle社MySQLサポートグループ・バグ検証グループの主席テクニカルサポートエンジニアとして毎日MySQ
MySQL のレプリケーションから10年間逃げてきた我々が学んだこと8選 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。クラウド運用チームで SRE をしている飯塚です。 今回は、MySQL のレプリケーション機能を約10年もの間ずっと使ってこなかった私たちが、レプリケーションを使った高可用性構成に移行するための取り組みの中で学んだことについて紹介します。 背景 巨大なテーブルへの primary key の付与 トランザクションサイズが大きい場合には tmpdir に注意 mysqldump で絵文字が消えていないか要チェック mysqldump が Error 1412: Table definition has changed... で失敗する mysqldump したデータのリストアが Duplicate entry 'xxx-yyy-PRIMARY-n_diff_pfx01' for key 'PRIMARY' で失敗することがある mysqldump したデータのリストア時のディスク
MySQL データベースの負荷対策/パフォーマンスチューニング備忘録 インデックスの基礎〜実践 - Qiita
TL;DR この記事に書いた事 二分探索木のお話(前提知識) MySQLのInnoDBで利用されているB+木インデックスの構造と特性 (前提知識) MySQLのClusteredIndex,SecondaryIndexについて(前提知識) カーディナリティについて(前提知識) 実際の負荷対策 検出編 スロークエリ 検出編 その他のクエリ割り出しいろいろ クエリ・インデックスの最適化 explainの使い方と詳細 ケース別実践 単純にインデックスがあたっていないケース カーディナリティが低いインデックスが使われているケース 部分的にしかインデックス/複合インデックスがあたっていないケース 複合インデックスの順序誤りでインデックスが適用できていないケース 複合インデックスの最初がrange検索のケース ソートにインデックスが適用できていないケース ソートにインデックスが適用できていないケース（
ISUCON8 予選問題の解説と講評 : ISUCON公式Blog
予選の問題作成を担当したDeNAのkarupaneruraです。 予選に参加した皆様、お疲れ様でした。 楽しんで頂けましたでしょうか。 お陰様で大きなトラブルもなく無事に予選を終えることができました。 参加者の皆様をはじめとした皆さんのご協力がなければ成し得ないことでした。 ご協力いただいた皆様、ありがとうございました。 課題アプリケーション今回の課題はイベントのチケット予約アプリケーションでした。 ユーザーを作成、またはログインを行うと座席を予約することができます。 座席は抽選で決まる仕組みになっており、ランダムに決まった座席が即座に分かるようになっています。 埋まっている座席は黒く塗りつぶされ、自分の獲得した座席は緑色の字で表示されています。 また、自分の座席をクリックするとキャンセルを行うことができます。 マイページでは自分の最近予約(orキャンセル)した席を5件、最近予約(orキャ
YappoLogs: なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか
なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか ここ最近の大規模サービス関連したデータページング考です。 mysql 5.5.34 で試して記事書いてます。 bigdata テーブルは id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (id) なカラムがある前提です。もちろん InnoDB です。 2014年なんだからCOUNT(*)とかSQL_CALC_FOUND_ROWSとかLIMIT OFFSETのページングはやめようぜ - Togetterまとめが発端にみえるけど、わりと昔から話されてる事なんだけど、「nippondanji SQL_CALC_FOUND_ROWS」でググっても有用な情報ないし文書化されてないからしとく。 ページング処理で使われがちな機能です。 S
モンストのサーバー負荷との戦い 〜あけおめ2018編〜 / bcu_30_server_9
スマホアプリ「モンスターストライク」のサーバー負荷は、年末年始に1年のピークを迎えます。2018年元旦のサーバー負荷に立ち向かうために実施した対策の一例として、データベースサーバー（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
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策｜ハイクラス転職・求人情報サイト AMBI（アンビ）
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ
MySQL 8.0 : クエリーキャッシュのサポート終了 | Yakst
役に立つ場面もある一方、スケーラビリティー上問題があるとされてきたMySQLのクエリーキャッシュが、MySQL 8.0で廃止されることになる。その背景と理由。 免責事項 この記事はMorgan Tocker氏によるMySQL Server Blogの投稿「MySQL 8.0: Retiring Support for the Query Cache」(2017/5/30)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 Reneが昨日、ProxySQLのブログにこう書きました。 MySQLのクエリーキャッシュはパフォーマンスを改善するためにあるが、それは重大なスケーラビリティー上の問題を抱えていて、深刻なボトルネックに簡単になってしまいかねない。 これは、MySQLチーム内でも確かに長い間言われてきたことです。今日の記事の本題に入る前に、少しイントロダクションを書かせて
PostgreSQL and MySQL: Millions of Queries per Second
This blog compares how PostgreSQL and MySQL handle millions of queries per second. Anastasia: Can open source databases cope with millions of queries per second? Many open source advocates would answer “yes.” However, assertions aren’t enough for well-grounded proof. That’s why in this blog post, we share the benchmark testing results from Alexander Korotkov (CEO of Development, Postgres Professio
MySQLインデックスのお手入れの基本 | Yakst
Percona Database Performance Blogの翻訳。既に運用を始めたデータベースで、インデックスが正しく使われているか、無駄や不足がないかを確認する方法のまとめ記事。クエリをひとつひとつ確認するのではなく、統計情報を元に判断する分かりやすい方法。 このブログ記事では、MySQLインデックスに手入れする基本的なステップについて見ていこうと思います。 データベースは、インデックス次第でハイパフォーマンスにも、役立たずで遅くて大変にもなりうることはご存知でしょう。インデックスは、時々手入れをする価値がある非常に重要なものです。それでは、何をチェックすればよいのでしょうか？順不同ですが、確認すべき点を挙げてみます。 1. 使われていないインデックス sysスキーマで、使われていないインデックスをとても簡単に見つけられます。 schema_unused_indexes ビューを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
My sqlで2億件のシリアルデータと格闘した話