はじめての MySQL で100万件のデータを管理する時に行ったチューニングまとめ
MySQL の勉強をせずにフレームワーク等で SQL を書かずに Web サイトを構築していました。データ数も2万件程度でしたので、そこまで困ることはありませんでしたが、今回100万弱の商品データを扱う機会ができたので、MySQL のチューニングや発行する SQL について見直す機会がありました。 この記事では MySQL を高速化するのに行った対策など勉強したものを自分用にメモしておきました。 条件式で比較するカラムにインデックスを使用して高速化 商品コードで存在しない商品を見つけて、商品をDBに登録するという処理を行っている場合、4万件超えたころから処理に2秒以上かかるようになってきます。12万件超えた頃には10秒程度かかるようになってしまいましたが、商品コードのフィールドに対してカラムインデックスを貼ることで0.2秒に短縮することができました。 MySQL のリファレンスにも以下のよ
DBサーバーの負荷分散
MySQLアクセスを負荷分散する ユーザーからのアクセス数が非常に多いWebサイトにおいて、MySQLのSLAVEサーバーを複数台並べて負荷分散させるということがよく行われています。ただ、Webアクセスの負荷分散は一般的なテーマなのでいろいろなところで語られているのに対し、DBアクセスの負荷分散というテーマは一般的でないのかあまり語られていないように感じます。 DBアクセスを負荷分散するにあたって一番荒っぽい方法は、Webサーバー上のプログラムの中でどのSLAVEサーバーに接続するかをランダムで決める方法です。ランダムと言っても長時間アクセスしているとほぼ接続先が均等化されるので、一見この方法でも問題ないように見えます。しかしこの方法だと、接続しに行こうとしたSLAVEサーバーが高負荷もしくはサービス停止中であっても構わず接続しに行ってしまうという問題があります。 このような問題を解決する
MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店
MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
［新バージョン］MySQL 5.1 InnoDBの性能評価――バージョン5.0からの劇的な性能向上を計測する | gihyo.jp
性能評価結果 DBT-1によるバージョン5.0と5.1の評価結果は、図1のとおりです。 MySQL 5.0のInnoDBでは、仮想ユーザ数6,000程度で理論値を若干下回り、以降そのまま飽和状態に達していることがわかります。 それに対してMySQL 5.1のInnoDBでは、仮想ユーザ数が12,000を過ぎるまでDBT-1の理論値どおりのスループットを示し、以降微小ながらも上昇を続け、仮想ユーザ数16,000あたりで飽和状態（上限）に達したことが読み取れます。 図1 DBT-1のベンチマーク結果 ※ MySQL 5.0の測定において、仮想ユーザ数14,000と16,000のデータを採取した際、システムのリソース限界のためDBT-1自体が途中でエラーになってしまっていました。ですので、仮想ユーザ数14,000と16,000のデータについては参考値扱いとしてご覧ください。 リソースの使用状況
MySQLの状態がリアルタイムでわかるMySQL用topコマンド「mytop」と「innotop」
サーバのチューニングをする上でかなりやっかいなのがデータベース系。特にログファイルの量が膨大になると後から中身を見て問題を分析するのも一苦労という場合が。そんなときにこのMySQL用topコマンド「mytop」を使えば一体何が起きているのかがすぐにわかるので問題点の把握が容易になります。ベンチマークするときに併用すればかなり効率が良くなるのではないかと。 インストールと使い方は以下の通り。 まずは「mytop」から。以下が公式サイト。 mytop - a top clone for MySQL http://jeremy.zawodny.com/mysql/mytop/ マニュアルは以下にあります。 mytop - display MySQL server performance info like `top' インストールするにはSSHなどを使ってrootでログイン後、wgetでファイル
[MySQL] 4. SQLお試し記録 Transaction isolation levelの実験 (MySQL/WindowsXP)
■ MySQL雑記録 ■ 4. SQLお試し記録 Transaction isolation levelの実験 [前] [はい、次] ● トランザクション隔離レベル(＝トランザクション遮断レベル) 参考リンク http://dev.mysql.com/doc/mysql/en/COMMIT.html http://dev.mysql.com/doc/mysql/en/SET_TRANSACTION.html 前回までと同じように、ＰＣ上でコマンドプロンプトの窓を２つ開き、 それぞれ独立してSQLを投入するという環境での説明になります。 Transactionの最中で、他窓のcommitに影響されたくない場合は、 start transaction と入れてtransaction開始直後に、 set transaction isolation
【MySQLウォッチ】第25回 チューニングの指標，ベンチマークのノウハウ：ITpro
誰もが，データベースができるだけ高速で動くことを望む。そのために様々なテクニックを駆使してチューニングを試みる。 チューニングの結果を確認するには，何かしらの指標が必要となる。「体感的に向上した」というのは，まったく当てにならない。正確に性能を把握してこそ，効率的なチューニングが行えるのだ。今回は，ベンチマークについて紹介する。 MySQLのベンチマーク方法 ベンチマークには，２つの方向性がある。一つ目は，決まった処理を通じて，MySQLサーバーの処理速度を計測するものだ。これは，手順が決まっているため，それほど準備は必要ない。また，常に同じ処理を行うので，MySQLサーバーの基本的な処理能力を測るのに適している。 2つ目は，作成したデータベースの処理スピードを計測するものだ。一つ目も重要であるが，結局は，作成したデータベースが高速で動作するかが重要である。さらに，同時アクセス数やデータ量
［MySQLウォッチ］第38回 インデックスの劣化と再生
データベースは，大量のデータを格納して目的に合わせて処理するのが役割である。処理を高速化する機能として，インデックスが用意されている。インデックスは，あらかじめ検索やソート対象となる列のデータを処理しやすいように別管理するものだ。インデックスを使いこなせるかどうかで，データベース処理の良し悪し決まるといっても過言ではない。しかし，インデックスいつまでも高速ではない。その効果が，色褪せる時がやってくるのだ。 インデックスの効用 まずは，肩慣らしにインデックスの効用を確認する。テーブル「pono」は，日本郵政グループの日本郵便事業株式会社が提供している郵便番号データを格納したテーブルだ。 図1●テスト用のテーブル「pono」 mysql> show create table pono \G *************************** 1. row *****************
MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.6.1.5 MyISAM から InnoDB へのテーブルの変換
信頼性とスケーラビリティを向上させるために InnoDB に変換する MyISAM テーブルがある場合は、変換する前に次のガイドラインとヒントを確認してください。 以前のバージョンの MySQL で作成されたパーティション化された MyISAM テーブルは、MySQL 8.0 と互換性がありません。 このようなテーブルは、パーティション化を削除するか、InnoDB に変換して、アップグレード前に準備する必要があります。 詳細は、セクション24.6.2「ストレージエンジンに関連するパーティショニング制限」を参照してください。 MyISAM テーブルから移行するときに、結果をキャッシュする際に必要でなくなったメモリーが解放されるように、key_buffer_size 構成オプションの値を小さくします。 InnoDB テーブル用のキャッシュメモリー割り当てと同様の役割を担う innodb_buf
embomaコラム
株式会社えむぼま CTO 高見禎成 ■swapさせずに最大プロセス数にせよ！ WWWサーバが最大パフォーマンスを出すには 1) SWAPさせないで 2) 最大プロセス数に設定する ことが最大の条件です。 他にapacheのhttpd.confでHostNameLookups offにしてログ記録時の名前解決をなくす等細かい積み重ねはいくつかありますが、最大のポイントは上記2条件でしょう。 ■最大プロセス数は揃えよ！ SWAPさせない最大プロセス数をいくつにするかはこの後見ていきますが、どの値にするにせよapacheとtomcatとDBの最大プロセス数は揃えましょう。 apacheのMaxClietnsは標準で255、tomcatのMaxThreadsは標準で150、MySQLのmax_connectionsは標準で100です。 apacheが2台でMySQL 1台に接続しているなら、MyS
MySQLとオープンソースに捧げる毎日:MySQLの管理など - livedoor Blog（ブログ）
今回も前回に引き続き、ただいま受講中のMySQLトレーニングの実況中継（4日目）。 いつも応援ありがとう！ 【参考】 MySQL Certification Study Guide 今日のトレーニングは、MySQLのログ、トランザクション、バックアップ、レプリケーションについて。 実践に役立ちそうな技から、試験ぐらいでしか使わなそうな技まで、気になったものをトレーニングを受けながらリアルタイムに追記していくので、もし今日の分をまとめて見たいあなたは、18時以降にまたどうぞ。 一般クエリーログをオン（デフォルトはオフのまま）にすると、発行されたクエリーを記録できるが、パフォーマンスが10%ほど低下する。 スロークエリーログを使うと、実行の遅いクエリーやインデックスを使用していないクエリーを記録できる。 基本的にMyISAMの方がselect、insertなどの動作がInnoDBよりも速い。
http://www.interdb.jp/techinfo/mysql/m-2-10.html
[InterDB] [著者HP] [PREVIOUS][UP][NEXT] ■■■■ [ロック] ■2-10■ ロック ■■■■ MySQLはWRITE(書き込み)ロックとREAD(読み出し)ロックの2種類をサポートしていますが、テーブル型毎に`ロック'の挙動が異なります。 以降、使用頻度の高いMyISAM型とInnoDB型のロックについて説明します(【表.2-8】参照)。 表.2-8 テーブル型毎のロックの挙動 ========================================================================================================================= テーブル型 | ロックレベル | デッドロック状態への対処 | 備考 | ===========+================
さくらのレンタルサーバ
レンタルサーバなら「さくらのレンタルサーバ」！ 月額換算でわずか131円、缶ジュース1本分のお値段で使える格安プランから、ビジネスにも使える多機能＆大容量プランまで、 用途と予算に合わせてプランを選べます。 さらにマルチドメイン対応でメールアドレスも無制限。無料ウイルススキャンや無料電話サポートもあるので安心して ご利用いただける共用レンタルサーバサービスです。
MySQL :: MySQL 8.0 リファレンスマニュアル :: 17.2.3 レプリケーションスレッド
バイナリログダンプスレッド. ソースは、レプリカの接続時にバイナリログの内容をレプリカに送信するスレッドを作成します。 このスレッドは、ソース上の SHOW PROCESSLIST の出力で Binlog Dump スレッドとして識別できます。 バイナリログダンプスレッドは、レプリカに送信される各イベントを読み取るために、ソースバイナリログのロックを取得します。 イベントが読み取られるとすぐに、イベントがレプリカに送信される前でもロックが解除されます。 レプリケーション I/O スレッド. レプリカサーバーで START REPLICA | SLAVE ステートメントが発行されると、レプリカは I/O スレッドを作成します。このスレッドはソースに接続し、バイナリログに記録された更新を送信するように要求します。 レプリケーション I/O スレッドは、ソース Binlog Dump スレッドが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
mysql:2153
ムームー太郎のモッサリいこう: ＰＣ アーカイブ
株式会社スタイルズ
mysqlをDBサーバーに使っているのですが、トランザクションを使うためにテーブルを既存のMyIsamエンジンからInnoDBに切り替えたいのですが、その際に典型的な問…
MLog: [mysql 14468] Re: myisamchk