How to choose the best indexes for MySQL query and database optimization
April 25, 2020September 3, 2020 Tomer Shay @ EverSQL Many of our users, developers and database administrators, keep asking our team about EverSQL's indexing recommendations algorithm. So, we decided to write about it. The first option is to use EverSQL to automatically find indexes that are best for your database. The second option is to read our detailed tutorial below and learn more about index
MySQLレプリケーションあれやこれや
2018/01/26 第2回 オープンソースデータベース比較セミナー https://osscons-database.connpass.com/event/74688/
ProxySQLをつかったRDSの切り替え - so what
ProxySQLとは ProxySQLはMySQL用のL7のプロキシサーバで、プロキシサーバのレイヤでR/W Splittingできたり、クエリの書き換えをできたり、負荷分散などができたりする便利ミドルウェアです。 www.proxysql.com Dropboxの中の人が書いているみたいで、Perconaの推しミドルウェアみたいです。（開発にも関わっているのかな？） あとQiitaにもいくつか記事が上がってます。 https://qiita.com/search?q=ProxySQL 設定の管理が結構独特で、MySQLっぽく振る舞うsqliteで管理されていて、動的にバックエンドのサーバを書き換えたりすることができます。設定まわりの概念的なものは『ProxySQL触ってみた - Qiita』がわかりやすいかも。 動的なバックエンドの切り替え 管理用インターフェースに対して、以下のようなク
MySQLのbinlogを使ってSSPの配信設定反映を40倍速くした話 - GENIEEエンジニアブログ
はじめに こんにちは、R&D本部アドプラットフォーム開発部の村岡です。 九州工業大学の先端情報工学専攻を予定通り修了してジーニーに17卒入社し、現在は主にGenieeSSPの開発を行っています。 以前こちらの記事を書きましたが、今回もMySQL関連の記事となります。 GenieeSSPについて GenieeSSPは、広告配信のレスポンスタイムを短くするために、数十万の広告枠の配信設定をすべてインメモリで保持しています。 全広告枠の配信設定はMySQLに保存されています。配信設定を変更する、つまりDBのデータを変更する方法は、現在の運用では4つあります。 営業担当や、広告運用チームなどが操作画面を使って更新する。 操作画面では対応できない場合などに、エンジニアの運用チームが手作業で更新する。 配信パラメータ最適化のためのバッチが更新する。 リリース時などにエンジニアが権限をもらって更新する（
MySQL InnoDBの領域管理 - Qiita
武蔵野Advent Calendar 2017の20日目の記事です。品川から参加しています。 今日はMySQL InnoDBの領域管理について勉強し、いくつか動作例を見ながらInnoDBに対する理解を深めていきたいと思います。アプリケーション開発者やデータベース管理者の方にとって明日からすぐに使えるノウハウとまではいきませんが、いつか何かの役に立てば幸いです。 まとめ InnoDBにはテーブルスペース、セグメント、エクステント、ページというデータの管理単位があるよ エクステント単位で空き領域が管理されているよ。だけどそれを知ったところであまり役には立たないよ 昇順INSERTが得意でランダムINSERTが苦手なのはよく知られているけれど、実は降順INSERTが得意だよ テーブルスペース、セグメント、エクステント、ページ InnoDBのデータが格納されるファイルのことをテーブルスペースと呼び
なぜあなたは SHOW ENGINE INNODB STATUS を読まないのか - そーだいなるらくがき帳
この記事は、MySQL Casual Advent Calendar 2017の20日目の記事です。 煽り気味のタイトルですがみなさん SHOW ENGINE INNODB STATUS 読んでますか？ SHOW ENGINE INNODB STATUS \G 見づらいのなんとかならんのか。— そーだい@初代ALF (@soudai1025) 2016年12月20日 わかる。でもMySQLの振る舞いを知る中でSHOW ENGINE INNODB STATUSを読まざる得ない場面はそこそこあります。 どんな時に必要になるのでしょうか？ そこでSHOW ENGINE INNODB STATUSにまつわる話を書きます。 SHOW ENGINE INNODB STATUS をまず読みやすくする まず末尾に \G を付けましょう。 これで3倍読みやすくなります。 次に pager less -S を
更新頻度の多いデータのキャッシュ : DSAS開発者の部屋
@methane です。 ISUCON 7 本戦で最大のスコアアップできたポイントが、 status と呼ばれる重い計算の結果となるJSONのキャッシュでした。 近年のISUCONによくある、「更新が成功したら以降のレスポンスにはその更新が反映される必要がある」（以降は「即時反映」と呼びます）タイプの問題だったのですが、今回のように更新頻度の高くかつ即時反映が求められるデータをキャッシュする方法について、より一般的に解説しておきたいと思います。 即時反映が不要な場合 まずは基本として、即時反映が不要な場合のキャッシュ方法からおさらいします。この場合、一番良く使われるのは参照時に計算した結果を Memcached などにキャッシュし、時間で expire する方法です。 このタイプのキャッシュには、参照元が分散している場合（Webサーバーが複数台あるなど）に Thundering Herd
MySQL 5.7のマルチソースレプリケーションを活用する - 無停止でシャーディングを解消 - 猫でもわかるWeb開発・プログラミング
はじめに この記事は ドワンゴ Advent Calendar 2017 - Qiita の15日目の記事です。 昨日の記事は ytanaka さんの Goadを使った負荷試験とパフォーマンス分析手法について - Qiita でした。 自己紹介 ドワンゴでニコニコ動画の開発をしています。 *1 去年もアドベントカレンダー書いてました→ LGTM画像を驚くほど簡単に作れるWebサービスをScalaで作る - Qiita DBすき yoshikyoto (Yoshiyuki Sakamoto) · GitHub うたかた/ヨシキ (@yoshiki_utakata) | Twitter 背景 昔々あるところに、以下のような構成のサーバーがありました Webサーバー（アプリケーションサーバー）とDBサーバーからなる。 DBに入っているデータはユーザーIDでシャーディングされている。*2 どのデー
MySQL(innodb)の分離レベルごとのanomalyについて実験した - tom__bo’s Blog
※ この記事はMySQL Casual Advent Calendar 2017の11日目の記事です。 A critique of ANSI SQL isolation levelsを読んで(読んだブログ)、MySQL(innodb)で分離レベルごとのanomaly(不整合)の発生について実験しました。使ったのはDockerで立てられる 8.0.3-rc-log MySQL Community Sereverです。 ここでは上記の論文であげられているanomalyとid:kumagiさんのブログ(いろんなAnomaly)で知ったread only anomalyが起こるかを分離レベルごとに試してみます。 最初に、それぞれのanomalyについての簡単な説明とkumagiさんのブログで使っている書き方を真似た図、それに対応するプランを整理し、(実行経過は省略してw)結果だけ書きます。 ※ こ
本当はこわいMySQLプロトコル - tmtms のメモ
11/28 に Haskell で MySQL の Xプロトコルを実装したという話が聴ける Club MySQL というイベントがあったので参加してきました。 clubmysql.connpass.com MySQLのプロトコルの話ということで、平日の夜とは言え東京で参加者9人(発表者含む)というマニアックな集まりでした。 自分も1年前に Ruby で MySQL Xプロトコルを実装していたのですが、このツイートを最後に中断していたのでした。 MySQL X Protocol で Collection の追加はできるようになったが、検索がめんどくさい。条件文字列のパースはクライアントで行う必要があるんだな。— とみたまさひろ💎🐬 (@tmtms) 2017年2月20日 今回話を聞いて、無理に謎条件式文字列をパースするんじゃなくて、処理系で書きやすいように書けばいいんだという方式に目から
MySQLのGLOBAL_STATUSとGLOBAL_VARIABLES - なからなLife
今更MySQL5.7を扱うにあたって MySQL5.6とMySQL5.7のパラメータ差分をあらためて見直してたら、「show_compatibility_56」という、プロダクトのアーキ移行期間にありがちな「いかにも」な名前のパラメータがありまして。 これは何？ 「SHOW [GLOBAL] STATUS」や「SHOW [GLOBAL] VARIABLES」という、とてもお世話になるコマンドがあり、その実、テーブルに格納されている値を表示していたわけで、テーブル*1があることから、SELECT文を使うことでSHOWコマンドよりもより柔軟な条件式などを使って参照ができたわけです。 そんなテーブルたち、MySQL5.6まではInformation_Schemaにあったのが、MySQL 5.7からはPerformance_schemaに移動するぞ、ってドキュメントに書いてあります。 その説明のた
ElasticsearchをMySQLと同期しつつ手軽に無停止アップデートする - UUUMエンジニアブログ
nazoです。 Elasticsearchを運用する際に、マスタデータはMySQLで持ちたいという場合にどうやって同期をするかというのが問題になります。また、Elasticsearchはバージョンの互換性が厳しく、別バージョンをクラスタに混ぜることは基本的にできず、さらに辞書の更新などを行う場合はインデックスを全て更新しなくてはいけないなどの運用上の課題があります。 今回は社内向けに使っているElasticsearchを、これらの問題を解決しつつどのように運用するかを考えてみましたので、紹介したいと思います。 簡単に MySQLとElasitcsearchの同期は go-mysql-elasticsearch を使います。 無停止のためのデータコピーは elasticsearch-dump を使います。 MySQLとElasitcsearchの同期 go-mysql-elasticsear
Top 20+ MySQL Best Practices | Envato Tuts+
Database operations often tend to be the main bottleneck for most web applications today. It's not only the DBA's (database administrators) that have to worry about these performance issues. We as programmers need to do our part by structuring tables properly, writing optimized queries and better code. In this article, I'll list some MySQL optimization techniques for programmers. Before we start,
事前にデータ投入をした MySQL Docker イメージを作る場合は /docker-entrypoint-initdb.d を活用すると便利 - kakakakakku blog
事前にデータ投入をした MySQL Docker イメージが必要になり，最初は「Dockerfile で頑張る感じかなぁ...」なんて考えながら調査をしていたら，公式の MySQL Docker イメージに「カスタムスクリプトを実行する機能」が用意されていることを知って，全て解決した．今までも MySQL を Docker で動かす場面はあったけど，今回の機能は知らなくて勉強になった． CI で使うためにマイグレーション実行済の MySQL Docker イメージを用意しても良いし，新メンバーのために開発用の初期データを投入した MySQL Docker イメージを用意しても良いし，ハンズオンイベントのためにテストデータを投入した MySQL Docker イメージを用意しても良いと思う．今回の仕組みを知っておくと便利な場面は多そう． 公式の Dockerfile と docker-ent
MySQLの高可用性構成の展望2017年版(赤ちゃん編) | Yakst
シリーズ第三回目で、「グループレプリケーション」「プロキシ」「分散ストレージ」について紹介している。グループレプリケーションはGaleraとの違いについて、プロキシには幾つかの選択肢があること、分散ストレージではオープンソースのAuroraのようなデーターベースが可能になることなどが述べられている。 この記事は、2017年現在で使用できるMySQLの高可用性ソリューションに焦点を当てたシリーズの第3回目です。 最初の記事では10年以上前から存在していた技術である「長老」を見ました。（訳注：長老編日本語訳）第2回目の記事では「大人」 、つまりより最近の成熟した技術について話しました。（訳注：大人編日本語訳）この記事では、新興のMySQL高可用性ソリューションを紹介します。私がブログで選択した「赤ちゃん」の高可用性ソリューションは、 Group Replication（グループレプリケーション
MySQLのヒストグラム統計 (MySQL Server Blogより) | Yakst
MySQLでもついにヒストグラム統計を利用した実行計画作成がサポートされるようになりました。作成/削除の方法やどのようなときにインデックスと比べて有利か、などについてご案内します。 免責事項 この記事はErik Frøseth氏によるHistogram statistics in MySQL(2017/10/2)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 MySQL 8.0.3では、ヒストグラム統計を作成しオプティマイザがより多くの統計情報を利用できるようにすることができます。このブログ投稿では、どのようにヒストグラム統計を作成し、どのような時に役立つかについて説明しようと思います。 ヒストグラムとは何か クエリーオプティマイザはデータベースの中で、SQLクエリーを可能な限り最も効率の良い実行計画に変換する役割を担っています。 時にはクエリーオプティマイザは最も効
How to Choose the MySQL innodb_log_file_size
In this blog post, I’ll provide some guidance on how to choose the MySQL innodb_log_file_size. Like many database management systems, MySQL uses logs to achieve data durability (when using the default InnoDB storage engine). This ensures that when a transaction is committed, data is not lost in the event of crash or power loss. MySQL’s InnoDB storage engine uses a fixed size (circular) Redo log sp
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
mita2 DB メモ: Percona XtraDB Cluster 5.7 のバグたち（修正済）
https://engineering.mercari.com/entry/2017/12/18/deadlock
高負荷を捌くDBチューニングノウハウを公開！PHPとMySQLの TCP TIME-WAIT チューニング(後編) | さくらのナレッジ
