MySQL Connector/Jにおける大量INSERTのチューニング - SH2の日記
ピンポイントチューニング講座です。まずは結果から。 このグラフは、以下のテーブルに50,000レコードINSERTしたときの処理時間を示したものです。性能に70倍以上もの差が出ているのはなぜか、見ていきたいと思います。 CREATE TABLE `loadtest` ( `id` int(11) NOT NULL, `data` varchar(100) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 方法1 ベースライン conn = DriverManager.getConnection(JDBC_URL, JDBC_USER, JDBC_PASS); pstmt = conn.prepareStatement("insert into loadtest (id, data) values (?
MySQL InnoDBの介在する大規模サービスにおけるID生成戦略について - Qiita
はじめに このページでは、MySQL InnoDBの介在する大規模サービスにおいて考慮すべきインサート性能の問題と、ID生成戦略として、ゆるやかに増える64bit(8byte)の整数値を使う方法と、UUIDを問題を回避して用いる方法について説明します。 100万行以上でおこるインサート性能問題 MySQL InnoDBで大規模サービスを設計/運用している方なら周知の事実かもしれませんが、MySQLのInnoDBには、int(4byte)よりも大きなサイズのカラムにインデックスが貼られたテーブルに、カーディナリティの高いランダムなデータを入れてインサートをしようとすると100万行以上で急激にインサート性能が落ちるという問題があります。 MySQL InnoDB Primary Key Choice: GUID/UUID vs Integer Insert Performance 、というサイ
MySQL InnoDB memcached pluginを使ってみようとしてやめた話 - なんかかきたい
追記 MySQL 5.7.19か20あたりで取り込まれたパッチにより以下の問題は発生しなくなりました。つまりはバグでした。 InnoDB memcached pluginはMySQL 5.6から搭載された機能で、Memcacheプロトコルを使ってInnoDBにデータを読み書きできる便利機能です。 簡単なプロトコルなためSQLより高速に動作する点、InnoDBに記録できる点、MySQLのレプリケーションが利用できる点など、 うまく使えば便利な仕組みですが、結論を先に書いてしまうと使えなかったという話をします。 使えなかった理由 MySQL memcached pluginを使ったInnoDBへのインターフェイスが使えなかった理由はクラッシュが多発するためです。 高速な動作、レプリケーション機能などはうまく動作しているのですが、 しばらく動作させていると get 操作の際に SIGABRT と
InnoDBで行ロック/テーブルロックになる条件を調べた #mysqlcasual Advent Calendar 2013 - あおうさ＠日記
はじめに この記事は、MySQL Casual Advent Calendar 2013 7日目の記事です。 〜 Casual に記事を書けばええんやでヽ(´ー｀)ノ 〜 私がMySQLで えっ？！ っと思った下記エントリーの挙動が何故そうなってしまうのかを書きたいと思います。 InnoDBで行ロック/テーブルロックになる条件 MyISAM はテーブルロック、InnoDB は行ロックが掛かるというのは有名な話じゃないかと。 ただ、最近知ったのですが、InnoDB だとしても必ずしも行ロックになるわけではなく、テーブルロックになる場合もあるようですね。 ... InnoDB であってもユニーク制約 or インデックスが張られているカラムで検索した場合以外はテーブルロックになってしまうようです。これは注意しないと思わぬところでテーブルロックになってしまって大変なことになりそう！ http://
MySQL 5.7のmysqld --initializeと鶏卵問題 - （ひ）メモ
MySQLのデータディレクトリの初期化にはこれまで mysql_install_db が使われてきましたが、MySQL 5.7からは mysqld --initialize を使うことが推奨されています。 mysqld --initialize は datadir 配下にファイルやサブディレクトリがあるとエラー終了します。 # mysqld --initialize --user=mysql 2016-10-04T11:39:01.313174Z 0 [ERROR] --initialize specified but the data directory has files in it. Aborting. 2016-10-04T11:39:01.313222Z 0 [ERROR] Abortingなので datadir をスッカラカンにして再度実行してみます。my.cnf はこんな内容
MySQLを１〜２時間でスケールアウトする - クックパッド開発者ブログ
最近、Elastic BeanstalkやECSと戦っているSREチームの菅原です。 P5をやりたいのにPS3もPS4も持っていないので指をくわえて羨ましがっている毎日です。 この記事では、突然のアクセス増に備えるために、MySQLのスレーブを１〜２時間でスケールアウトできるようにした話を書きます。 MySQL on EC2 クックパッドは周知の通りAWSを利用していますが、主要なデーターベースについてはAmazon RDSではなくMySQL on EC2を使っています。 これは以下のような理由によるものです。 歴史的な経緯: AWS移行当時、RDSが無かった。また、移行後もしばらくはTritonnを使っていたため、RDSを使うことができなかった オンラインメンテナンスの実現: VPCルートテーブルを使った仮想IPとMHA for MySQLを使ってダウンタイムゼロのマスタDBの切り替えを
私は如何にして詳解 MySQL 5.7を執筆するに至ったか
先日・・・といっても既に先月のことになるのだが、詳解MySQL 5.7 出版記念交流会には多くの方に来て頂いた。台風にも関わらず、とても多くの（60名ほど）の方に足を運んで頂いたのは、本当に嬉しかった。ここで改めてお礼申し上げる。 ありがとうございました！！ さて、交流会のときに使用したスライドを公開したので、興味のある方は見ていただきたい。 少しスライドを補足すると、MySQL 5.7の新機能にスポットを当てた本というのは、やはりニッチだと思う。しかし、MySQL 5.7を使いこなす上で、このようにまとまった情報は必須・・・というか、無いと話にならないだろうと思っていたので、出版するに至ったことは非常にありがたい。よくこんな企画をよく通してくれたなと・・・。G社さんの反応は、至って普通だったと思う。とはいえ、今後もMySQLを使っていこうと考えている人には必ず役に立つ内容だと信じているの
MySQLのチューニングを戦う方へ
本連載もついに最終回となりました。 本連載では、MySQLクエリーチューニングことはじめで予告した通り、「チューニング箇所の洗い出しのテクニック」について説明してきましたが、「チューニングの方法」については一切触れませんでした。 「本連載ではチューニングそのものの方法については詳しく説明しません。それは見出しの通り「銀の弾丸」などはなく、MySQLのパフォーマンスチューニングは計測と改善を繰り返し行っていくべきものだからです。そのため、特定のケースにマッチする改善の手法よりも、繰り返し使われる計測の手法にフォーカスを当てて説明していきます。」 その理由としてこの一文が全てではありますが、今回は参考までに筆者が考えるチューニングの指標を紹介したいと思います。それがあなたの環境に当てはまるかどうかは、これまでに紹介してきたツールなどを利用して計測してみてください。 チューニングの基本方針 基本
CentOS 7 + MySQL 5.7で複数のMySQLインスタンスを起動する - Qiita
CentOS 6以前とMySQL 5.6以前の構成ではmysqld_multiというものを使っていました。 これはMySQLをインストールすると入っているもので、複数のMySQLインスタンスを立ち上げたいときに使用します。 複数のインスタンスを立ち上げたいときとは、例えば本番環境で物理的に別れているDBサーバーを開発環境で再現したり、レプリケーションをテストをしたりするときに使います。 MySQLのオフィシャルサイトで紹介されていた方法があまりに簡単だったので、ここでも紹介します。 以下の方法はMySQL 5.7.13以降でsystemctlを利用するシステムで有効です。 MySQL 5.7で複数インスタンスの起動はできるか もちろんできます。結局引数でdatadirとかpidファイルの場所とか指定すれば、自力でも設定は可能です。 ちなみにMySQL 5.7.13のsystemctlプラッ
MySQLインデックスのお手入れの基本 | Yakst
Percona Database Performance Blogの翻訳。既に運用を始めたデータベースで、インデックスが正しく使われているか、無駄や不足がないかを確認する方法のまとめ記事。クエリをひとつひとつ確認するのではなく、統計情報を元に判断する分かりやすい方法。 このブログ記事では、MySQLインデックスに手入れする基本的なステップについて見ていこうと思います。 データベースは、インデックス次第でハイパフォーマンスにも、役立たずで遅くて大変にもなりうることはご存知でしょう。インデックスは、時々手入れをする価値がある非常に重要なものです。それでは、何をチェックすればよいのでしょうか？順不同ですが、確認すべき点を挙げてみます。 1. 使われていないインデックス sysスキーマで、使われていないインデックスをとても簡単に見つけられます。 schema_unused_indexes ビューを
挿入と参照ロックに疲れ果てた俺たちは - ichirin2501's diary
なかったらINSERTしたいし、あるならロック取りたいやん? from ichirin2501 www.slideshare.net 出来事 @ichirin2501 とりあえず何も考えずこの前のロックの話をSlideshareにあげてくれ！！— 柴崎優季 (@shiba_yu36) 2015, 8月 22 はじめに これは先日の社内勉強会で発表したもので、MySQLで特定の問題を解決したいときのノウハウ話です。特定の問題とは、アプリを書いてると「データがなかったINSERTしたい、あるなら排他ロックしつつ取得したい」という要望があったりします。例えば、あるユーザーアクションで初期値もパラメーターで渡されるケースで、データがないならそのままINSERT、既にデータがあるなら取得して状態に依存して更新処理を行いたい場合などです。見かけのロジックは単純に見えますが、MySQLでこれを実現しよう
MySQLのinnodb_file_per_tableについての検証 - s_tajima:TechBlog
背景 innodb_file_per_tableを有効にしている場合に、 テーブル数が多くなるとMySQLの起動/停止や、innodbのクラッシュリカバリに時間がかかるようになるとの噂を聞いたので、 その辺りを含めた簡単な検証をしてみたメモ。 あまりしっかりとした調査はしていないので参考程度に。 尚、innodb_file_per_tableについての説明は割愛。 検証環境 検証した環境は、 OS: Scientific Linux release 6.1 MySQL: MySQL-server-5.6.17 FileSystem: ext4 実運用サービスの開発機で使用しているデータを使用。 同一のデータをそれぞれinnodb_file_par_tableをon/offした状態でimport。 参考までにデータの規模としては テーブル数: 2232 DBのdumpサイズ(gzipで圧縮)
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だと思っていただろう・
MySQL InnoDBでのロック競合解析 - Qiita
前提 MySQL5.1の場合はInnoDB pluginを有効にする必要があります。 解析方法 information_schemaデータベースにある以下の3テーブルを利用して解析を行います。 INNODB_TRX 現在実行中のトランザクションを表示するテーブル INNODB_LOCKS ロック競合を起こしているトランザクションの情報を表示するテーブル INNODB_LOCK_WAITS どのトランザクションがどのトランザクションを待たせているのかを出力するテーブル ロック競合を表示するSQL select t_b.trx_mysql_thread_id blocking_id, t_w.trx_mysql_thread_id requesting_id, p_b.HOST blocking_host, p_w.HOST requesting_host, l.lock_table lock
tmp_table_size のチューニングとメモリ上に一時テーブルが作れないクエリ - Qiita
Created_tmp_disk_tables の意味 MySQL のチューニングする際に指標とするステータスの一つに Created_tmp_disk_tables というものがあります。 詳しくはもっと詳細な記事を見てくれればいいですが、クエリ実行時にメモリ上に収まりきらなかった一時テーブルを、ディスク上に作成した回数を意味します。 参考:MySQLの「temporary table (一時テーブル)」 と「tmp file(テンポラリファイル)」の違いと「Copying to tmp table」と「copy to tmp table」の違い | 田舎に住みたいエンジニアの日記 そもそも一時テーブルが肥大化するのはテーブルやクエリの設計に問題がある場合もあるので、 まずはクエリ自体を改善して巨大な一時テーブルが作られるのを抑制すべきですが、 大きなデータの集計を定期的に行うなど、要件
最強のDBを求めて、AWSのAuroraとMySQL5.7とGCPのGQLのv1,v2を比較し直してみた - Qiita
もう一度最強のDBを求めて 前回まで MySQL5.7 > Aurora 遅いと噂のGQL > RDS と、上のような結果が出てみたもののどうにも自分で調べておいて検証結果が信用できない。 データ容量と同時接続数を増やしてみてもう一度チャレンジしてみた。 検証方法 sysbench --test=oltp --db-driver=mysql --oltp-table-size=100000000 prepare sysbench --test=oltp --db-driver=mysql --oltp-table-size=100000000 --num-threads=XXX --oltp-read-only=off run 取りあえず手軽に試してみたかったので、sysbenchで実行してみる。 登録データ件数は1億件。容量にして約20GB。 同時接続数を4→8→16→32→64と増やし
ソーシャルゲームのためのMySQL入門 | BLOG - DeNA Engineering
こんにちはこんにちは。最近お腹痛いばっかり言ってることで有名なiwanagaです。 DeNAは外部的にはプラットフォーム的な部分の方がフィーチャーされることが多いですが、実はソーシャルゲームの提供も行っています。怪盗ロワイヤルとか、どこかで聞いたことがあるのではないでしょうか。 僕はDeNAでソーシャルゲームが誕生した辺りからずっとサーバサイドを見てきましたが、そんな運用の中で自分が貯めてきた知見とかTIPSをご紹介したいと思います。 かれこれ10タイトル近くはレビューしたり運用したりしてるため結構言いたいことはいっぱいあるので、小出しにしつつ評判よければ次も書きます。 ソーシャルゲームのためのMySQL入門一覧 ソーシャルゲームのためのMySQL入門 - Technology of DeNA ソーシャルゲームのためのMySQL入門2 - Technology of DeNA 「MySQL
MySQL で採番テーブル - Qiita
LAST_INSERT_ID(expr) を使う方法 公式ドキュメントで紹介されている方法. MySQL 5.6 Reference Manual :: 12.14 Information Functions LAST_INSERT_ID(), LAST_INSERT_ID(expr) If expr is given as an argument to LAST_INSERT_ID(), the value of the argument is returned by the function and is remembered as the next value to be returned by LAST_INSERT_ID(). This can be used to simulate sequences: テーブル準備 採番テーブル create table `seq` ( `i
Mysql5.7 関連資料まとめ(2016-09-18時点) - Qiita
Mysqlをちょっと濃い目に調査することになったので、覚書用にまとめを作成した。 面白そうなものはざったに収集してあるので、MECEになっていないことに注意されたし。 Mysql5.7 新機能・インストール MySQL 5.7の新機能完全リスト https://yakst.com/ja/posts/3037 MySQL 5.7の罠があなたを狙っている http://www.slideshare.net/yoku0825/mysql-57-51945745 MySQL 5.7 をインストールしたら最初に行うセットアップ http://weblabo.oscasierra.net/mysql-57-init-setup/ MySQL 5.7におけるサーバーのデフォルト値の改善 (MySQL Server Blogより) https://yakst.com/ja/posts/2733 MySQL
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLのautocommitとトランザクション分離レベルのメモ - Qiita
