Help us understand the problem. What is going on with this article?
今回は「pt-query-digest」を使用して、チューニングしたいSQLがスローログに記録されている場合の調査方法について説明します。 pt-query-digestとは pt-query-digestはPercona社が開発・配布するMySQL用のユーティリティーキットで、「Percona Toolkit」の1つです。最新ドキュメント(2016/3/22現在)はこちらにあります。pt-query-digestの基本的な使い方は「スローログをノーマライズ・集計し、人間が判断しやすい形式で出力させる」です。基本的にはスローログ用と考えますが、スローログ以外にもジェネラルログやバイナリーログ(mysqlbinlogコマンドの出力を入力する)、パケットキャプチャー(tcpdumpコマンドの出力を入力する)などが利用可能です。 Percona Toolkitのインストール まずはPercona
【MySQL5.6以上】Webエンジニア向け!メンテなしで500万件レコード入りのテーブルにINDEXを張る実行時間の目安RailsMySQLActiveRecordInnoDB レコード数が増えていくと、INDEXを張りたくなりますよね。 INDEXのあり/なしでレスポンスが大きく変わります。 でも、「サービスを止めたくない!」 そんなWebエンジニアの方のために、メンテなしでテーブルにINDEXを張る方法を・・・。 答えは簡単。 データベースを「MySQL5.6以上」にすることです。 MySQL5.6からオンラインでのDDLが可能となりました。 つまり、「オンラインでINDEXを張ること」ができます!! 意外と知られていない・・・?! 参考: CREATE INDEX、ADD INDEX項目 MySQL 5.6 リファレンスマニュアル 14.11.1 オンライン DDL の概要 検証環
7. ストレージエンジンによる テーブルスキャンの例 ha_tina::store_lock ha_tina::external_lock ha_tina::info ha_tina::rnd_init ha_tina::extra - ENUM HA_EXTRA_CACHE Cache record in HA_rrnd() ha_tina::rnd_next ha_tina::rnd_next ha_tina::rnd_next ha_tina::rnd_next ha_tina::rnd_next ha_tina::rnd_next ha_tina::rnd_next ha_tina::rnd_next ha_tina::rnd_next ha_tina::extra - ENUM HA_EXTRA_NO_CACHE End caching of records (def) ha_t
Uber-migrated-pg-to-mysql.md Why Uber Engineering Switched from Postgres to MySQL - Uber Engineering Blog のまとめ Posgresqlだと pgは追記型なので少しの更新でも多くのdiskへのwriteがおきる カラムを一つ更新しただけで多くのindexの書き換えが起こる よって、replicationはWALを送るので更新が多いとWALが大量に送られる repcliationでは物理的なdiskの変更を送る DC間でレプリするときつい bugがあってreplica間でMVCCの不整合が起きる masterとreplica同じdisk上のデータ構成を共有するのでupgradeがつらい cache readはsyscallとosのpage cache経由なので重い 1コネクション1プロセス
Percona Data Performance Blogの翻訳。Percona CEOのPeter Zaitevによる、MySQLのメモリー使用量をどのように決めるべきか、またそれを決める時に気にするべきことは何かについてのまとめ。 この記事では、最適なMySQLのメモリー使用量を設定するためのベストプラクティスを扱おうと思います。 使用できるメモリーのリソースをどのように使うか正しく設定するのは、MySQLを最適なパフォーマンスでかつ安定して使うために最も重要なことのひとつです。MySQL 5.7では、デフォルトの設定では非常に少ない量のメモリしか使いません。デフォルトのままにしておくのは、最も良くないことのひとつでしょう。しかし、不適切に設定してしまうと、パフォーマンスを更に悪くする(あるいはクラッシュする)ことにもなりかねません。 MySQLのメモリ使用量を設定するにあたっての最初
2016 - 06 - 20 Dockerで開発環境のMySQLと同じデータを手軽にローカル環境でも利用する Docker MySQL DevOps Microservicesを運用していると、サービス毎にDBを持つことになってどうしても扱うDBや スキーマ が多くなってしまいます。 開発環境の MySQL ( AWS ならRDS)に直接接続するならまだしも、DBはローカルにもって好き勝手に使ったり、汚したりスクラップしたりしたいですよね。 というわけで、Dockerを使ってカジュアルにその環境を作ってみました。 やりたいこと やりたいことを以下の図のような感じ。 docker runで MySQL のコンテナを起動する コンテナ起動時に任意のRDSから ダン プを取得し、コンテナ内の MySQL にリストアする(もちろんRDSでも AWS でもなくて良い) 使う 再度docker run
MySQL は分散DBの夢を見るか、Google F1 論文を実装した TiDB を使ってみた こんにちは、インフラエンジニアの nobuh です 分散DBという夢 クラウドのデータベース界隈では昨年くらいから MySQL 互換のクラウドでのデータベース、Amazon Aurora や Google Cloud SQL がホットな話題だと思います。 それはデータベースの黎明期から研究の場では分散データベースというのが大きな研究分野になっていて、RDBMS でありながらもスケールアウトが可能で耐障害性もあり、そして実用的な速度で稼働できるデータベースというのがデータベースエンジニアの約束の地、最後の楽園となっているからです。またその分散データベースが MySQL 互換で WordPress も動けばもう最高です。 Google Cloud SQL の元となっているらしい Google の F
前回の MySQL/MariaDBとTransactdのInnoDBロック制御詳細 その1 - BizStationブログ では、InnoDBのロックの詳細について説明しました。 今回は、TransactdのトランザクションにおいてInnoDBのロックをどう扱うかを説明します。Transactdは、InnoDBロックを自在に操って同時実行性を高めることができます。 ロック制御は、マルチスレッドプログラミングとmutex lockなどの制御とよく似ています。これらを扱ったことがあるようでしたら、Transactdのロック制御はとてもやり易く感じると思います。 書き込みにおけるパフォーマンスの確保には、ロックを最小限にし同時実行性を高めることが不可欠です。ミッションクリティカルなアプリケーションもパフォーマンスの良いものにしましょう。 Transactdのロック制御 TransactdのAPI
個人的にDBからデータを引っ張るときに必要なカラムのみを指定するのが嫌い。 カラム指定すると 検索条件が同じなのに、 必要なカラムが異なるだけで複数のAPIを実装し、 使う側は適切なAPIを選択しなければならない。 APIの命名にも苦労するし、そもそもDAOが肥大化する可能性があるのがイヤ。 命名も実装も上手くやれば問題ないんだろーけど、実際はそーもいかない気が・・・。 ということで、 必要なカラムのみ指定するのが正しいとは思うけど、 SELECT * で全カラム引っ張りたい。 でも、無駄なカラムを引っ張るとパフォーマンスが気になる。 ということで、検証してみた。 結論から言うと、結構変わるかもしれない。 以下がテスト環境。 CentOS 6.5 MySQL 5.5 メモリ:500MB(buffer_poolに384MB割り当て) 以下が今回のテストテーブル int型のカラムを30個用意し
MySQLいっぱい生み出して使い分けがしたかったので調べた。 今はまだコンテナが死ぬとデータも死ぬ仕組みなので、主にDaoあたりのユニットテストで一時的なデータ入れるためのDBとして使っておる。 うまくいくまで悩んだりもしたので、やり方だけメモしておく! ちなみにMac OS X El CapitanでVirtualBox使って動かしているよ!! ✬やってみること MySQLをDocker上で動かす hogeデータベースを作る hoge.usersテーブルを作る dukeユーザを作り、hogeに実行権限を付与する ✬インストール ✏VirtualBox, Docker Machine, Docker Toolboxをインストール $ brew cask install virtualbox $ brew install docker-machine $ brew cask install
B-treeがMySQLで使用されている背景から、B-treeインデックスの構造、そしてそれに基づいたインデックスの使用方法の入門編です。以下の流れに沿ってまとめていきます。 インデックスってなに? B-treeってなんでインデックスに使われているの? B-treeインデックスの構造 インデックスの使用方法 ※ 勉強をかねてまとめていることもあり、間違っている箇所がございましたら教えていただけると嬉しいです。 インデックスってなに? 全体の内容の中から特定部分を探すために使用する、本の索引のような概念のことです。これを用いることで、検索を高速化することができます。 特定の項目が本のどこに載っているかを確認するために索引を調べることで、全ページを順に調べなくても、その項目が登場するページ番号がわかる MySQLのストレージエンジンでも、インデックスが同様の方法で利用されており、インデックスの
GitBucketがMySQL、PostgreSQL対応したのでマイグレーションのテストをMySQLやPostgreSQLで実行できるようにしたいなぁと思って方法を考えています。 テスト用のDBを立てたりDockerを使ったりするのが一般的な方法なのではないかと思いますが、Javaで利用可能な組み込みMySQLなんていうものも存在するようなので試してみました(以前@makingに教えてもらいました)。 github.com 使い方はとても簡単で、Mavenの依存関係を追加して <dependency> <groupId>com.wix</groupId> <artifactId>wix-embedded-mysql</artifactId> <version>1.0.3</version> <scope>test</scope> </dependency> こんな感じで使えます。 Mysq
新しいアプリケーションの機能を実装する際に、ローカルや開発者向けのデータベースにアクセスして、プログラムを実装する前に何度かSQLをためしに実行することもあるかと思います。その際に、補完機能や以前実行したSQLの検索機能等がある場合とない場合では、作業の効率が変わってきます。 そこで、今回は補完や検索機能など、多くの便利な機能をもつmycliというクライアントについて紹介をしていきます。 デモンストレーション環境 今回は5.7.12を第5回 Dockerで複数バージョンのMySQLを開発環境に用意するで作成した環境で実行して確認していきます。また、今回使用するデータは「第2回 MySQLにはじめてのデータを入れてみる」で紹介をしている郵便番号のテーブルを用いて紹介を行います。 mycliのインストール ここではMySQLのクライアントの1つであるmycliを紹介します。mycliは自動補完
某所というかまぁFacebookでなのですが。 接続数が多くて「too many connections」エラーが発生する場合。 PHPのプログラム(バッチファイル)側として何か対応すべきことや、 注意すべきことなどありますでしょうか? という、大変に有意義で結構質問のありそうなあたりをいただいたので。 せっかくなので、Blogネタで書かせていただきました。 さて早速。 とりあえず直線的に状況を考えると、このエラーメッセージは「なんか接続数多すぎてさばけないヨ!」っていうMySQLからのクレームです。 悲鳴、って読み替えてもOK。 先に対象外である「PHP以外の角度からの」解法としては ・max_connections を増やして、もっと沢山接続できるようにする って方法があります。 あんまり無茶な数値にすると「DBサーバが落ちる」とかいう悲劇に直結しますので、サーバのリソースをしっかり監
いちいさんにお誘いいただいて、勉強会で発表をすることになりました。 InnoDB Deep Talk #1 : ATND おそらく初見では内容が難しいと思いますので、先に資料を公開しておきます。 プレゼンテーション資料 (PDF) テストデータ生成スクリプト (JdbcRunnerで利用します。) プレゼンテーション資料からリンクしているウェブサイトの一覧です。 MySQL Bugs: #64567: Last_query_cost is not updated when executing an unique key lookup Understanding and Control of MySQL Query Optimizer: Traditional and Novel Tools and Techniques: MySQL Conference & Expo 2009 - O'R
今回のエントリは以前かいた SQL のアンチパターン「ナイーブツリー」に関する記事の続き。 blog.amedama.jp 再帰クエリをサポートしていない RDBMS で再帰的な構造を表現するための解決策のひとつ経路列挙モデルを扱う。 使った環境は次の通り。 $ sw_vers ProductName: Mac OS X ProductVersion: 10.11.4 BuildVersion: 15E65 $ mysql --version mysql Ver 14.14 Distrib 5.7.12, for osx10.11 (x86_64) using EditLine wrapper 下準備 まずは下準備として MySQL にデータベースを作るところまで。 今回使ったのは Mac OS X なので MySQL は Homebrew でインストールする。 $ brew instal
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く