MySQL :: MySQL 8.0: Retiring Support for the Query Cache
As Rene wrote on the ProxySQL blog yesterday: Although MySQL Query Cache was meant to improve performance, it has serious scalability issues and it can easily become a severe bottleneck. This is indeed something we have observed in the MySQL team for a while. Before we get to the subject of today’s post, let me start with an introduction. Introduction to Query Cache The MySQL query cache is a quer
MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの？」みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
mysqlをdisる会 - Qiita
はじめに やあ （´・ω・｀) ようこそ、バーボンハウスへ。 このmysqlはサービスだから、まずsystemctl start mysqld して落ち着いて欲しい。 うん、「また」なんだ。済まない。 仏の顔もって言うしね、謝って許してもらおうとも思っていない。 でも、このタイトルを見たとき、君は、きっと言葉では言い表せない 「ときめき」みたいなものを感じてくれたと思う。 殺伐とした世の中で、そういう気持ちを忘れないで欲しい そう思って、この記事をかいたんだ じゃあ、注文を聞こうか。 というわけでmysqlをdisります。disるだけなので内容はありません。いいね？ mysql には罠がいっぱい そうなんですよ罠がいっぱいなんですよ奥さん。 いやこれはおそらくmysqlに限った話ではないんですけど例えばこういうの！ MySQLのチューニングなんてしたらパフォーマンス落ちるだけだし、デフォル
Orchestrator at GitHub
EngineeringOrchestrator at GitHubGitHub uses MySQL to store its metadata: Issues, Pull Requests, comments, organizations, notifications and so forth. While git repository data does not need MySQL to exist and persist, GitHub's service… GitHub uses MySQL to store its metadata: Issues, Pull Requests, comments, organizations, notifications and so forth. While git repository data does not need MySQL t
MySQL 8.0.0 Development Milestone Release登場！！
先月、詳解MySQL 5.7を発刊したばかりであるが、MySQL 5.7自体は去年の10月にリリースされたバージョンである。それから約1年弱、MySQLは開発の手を緩めること無く日々改良を重ねている。 そう、MySQL 8.0の登場である。 現在はDevelopment Milestone Release（通称DMR）という状態なので、まだ正式版における機能が固まっている段階ではないという点には注意して欲しい。MySQLの開発プロセスでは、DMRをリリースするごとにその段階で成熟した機能をマージする。DMRを何度かリリースした後に、キリの良いところでリリース候補版となって正式版で追加される機能が一応確定し、その後バグ修正を経て正式版（GA版）がリリースされる予定となっている。詳しくはMySQLのマニュアルを参照して欲しい。 バージョン8.0!!5.7の次は誰もが5.8だと思っていただろう・
MHA for MySQL の概要 - Gosuke Miyashita
MHA for MySQL の導入を検討していて、まずは社内の技術者向けに、MHA for MySQL の概要を伝えようと、主に オフィシャルなドキュメント からポイントを抜粋して社内向けの Wiki に書いてみた。本当なら、オフィシャルドキュメント全体に目を通してもらうのがいいんだけど、英語なので、はじめの一歩としては敷居が高く感じる人もいるだろう、ということで。 特に外に出してまずい情報があるわけでもないので、このブログでも曝しておきます。 MHA の概要 MySQL エキスパートとして世界的にも著名な松信嘉範氏による、MySQL マスターの HA 化を行うためのツール。Perl 製。 最小限のダウンタイムで、データの不整合を防ぎつつ、マスターのフェイルオーバーを行う、というのが主な機能。 また、既に動作している MySQL に影響を与えることなく導入できる。 機能は大きくわけると以下
Amazon RDS for MySQL - Amazon Relational Database Service
Amazon RDS では、DB インスタンス向けに MySQL の複数のバージョンがサポートされています。サポートされているバージョンの詳細については、「Amazon RDS での MySQL のバージョン」を参照してください。 Amazon RDS for MySQL DB インスタンスを作成するには、Amazon RDS の管理ツールまたはインターフェイスを使用します。続いて、次の操作を行います。 インスタンスのサイズの変更 DB インスタンスへの接続の許可 バックアップまたはスナップショットからの作成と復元 マルチ AZ セカンダリの作成 リードレプリカの作成 DB インスタンスのアクティビティとパフォーマンスのモニタリング DB インスタンスでデータを保存したり、またはアクセスするには、標準の MySQL のユーティリティとアプリケーションを使用します。 Amazon RDS f
このRDBについて私は驚くべき闇を見つけたがそこを発表するにはネットは怖すぎる
YAP(achimon)C::Asia Hachioji 2016midの資料です。
雑なMySQLパフォーマンスチューニング
26. EXPLAIN mysql> EXPLAIN SELECT * FROM table_1 a JOIN `table_2` s ON a.user_id=s.`user_id` AND s.site_i d=120 WHERE app_id=8250G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: a type: ref possible_keys: PRIMARY,ix_table_1,ix2_table_2,ix3_table_1,idx_table_1_06,idx_table_1_07,idx_t able_1_09 key: idx_table_1_06 key_len: 4 ref: const rows: 13496 Ext
DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
MySQLでのSlowLogの分析方法 - Qiita
概要 サービス開発/運用中に性能問題が発生した際に、DBのSlowLogを見るのは非常に有効なアプローチです。 SlowLogの出し方はRDBMS毎にやり方がありますが、特にMySQLでは単純に遅いQueryを出力するだけでなく、データが取得しやすいようにSlowLogをサマるためのツールが付属しています。 今回はそのツールmysqldumpslowの使い方を紹介します。 SlowLogから分かること SlowLogが出ていない場合、性能問題の原因がDBではない事。 SlowLogが出ている場合、どのQueryが性能問題を引き起こしているのか。 出力されるQueryの閾値をゼロとして全Queryを出力させると、Query毎の登場頻度も確認可能。 mysqldumpslowの使い方 準備 この手順では以下の物が必要となります。 分析対象のSlowLog リードレプリカを作ってる場合、複数のD
『MySQL初心者に贈るインデックスチューニングのポイントまとめ2014』
サイバーエージェント公式ブログをご覧の皆さんこんばんは、インフラ＆コアテク本部の須藤(@strsk)です。普段はAmebaのソーシャルゲーム全般のインフラを見つつ、日本語ラップの啓蒙をしながら弊社社員を素材にコラ画像をつくったりしています。好きなAAは麻呂です。 はい、というわけで今回はMySQLインデックスチューニングの基本的な流れについてまとめてみました。 ソーシャルゲームは更新も参照もめちゃくちゃ多いです。数秒のレプリケーション遅延も致命的なので適切なテーブル、クエリとインデックス設計が重要です。（何でもそうですけど）インデックスが多くなると更新コストなどが懸念されますが、インデックスが正しく使われていないクエリを放置している方が悪です。そんなこんなで、割と例も偏ったりしてるかもしれませんがあしからず。 前提としてはInnoDBを想定しています。MyISAMはほとんど使っていません。
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
