[B! mysql][tuning] tyoro1210のブックマーク

MySQLのテーブルオープン、クローズとテーブルキャッシュのチューニング | VPSサーバーでWebサイト公開　備忘録　~Linux、MySQLからAJAXまで

MySQLのテーブルオープン、クローズとテーブルキャッシュのチューニングについてまとめました。 ※目次をクリックすると目次の下部にコンテンツが表示されます。1．クライアント接続とマルチスレッド、セッション、ファイルディスクリプタ2．MySQLのテーブルキャッシュの概要3．テーブルキャッシュの設定値、チューニング・MySQLはマルチスレッド化されているため、多数のクライアントが同時に同じテーブルに対してクエリーを使用すること出来る。複数クライアントセッションが同一テーブルに対して異なる状態を持つことに伴う問題を少しでも少なくするため、テーブルはセッションごとに別々に開かれる。これはメモリーの消費を増やすが、一般にパフォーマンスは向上する。・MyISAMテーブルの場合は、テーブルを開いたそれぞれのクライアントにデータファイルに対するファイル記述子が必要になる。これに対し、インデ

tyoro1210 2016/01/26

table_open_cache

mysql
tuning

リンク

MySQLのメモリ設定の勘所 – sawara.me

MySQLサーバーをダウンさせた夜は数知れず。その度にmy.cnfの設定を見なおしてみてはトライし、治ったと思いきや突然のダウン。サーバーがダウンしてしまう原因は何かと聞かれれば、﹁メモリです﹂と断言しましょう。メモリ設定は諸刃の剣。パフォーマンスを最大に引き出すこともできればそれと引き換えにサーバーをダウンさせてしまうこともできるんです。今回はMySQLのメモリの設定の勘所というかたちで紹介しようと思います。グローバルバッファとスレッドバッファメモリの設定についてまず﹁グローバルバッファ﹂と﹁スレッドバッファ﹂について理解しておくことが大事です。バッファとは一時的な記憶領域・つまりはメモリの領域のことなのですが。グローバルバッファ MySQLで使用する全体的なメモリ使用量を計算するにはグローバルバッファ + (スレッドバッファ × コネクション数) = メモリ使用量と

tyoro1210 2016/01/26

リンク

クエリキャッシュは切ったほうがいいんじゃなイカ？ : DSAS開発者の部屋

KLab Advent Calendar 2011 「DSAS for Social を支える技術」の2日目は、昨日に引き続き、MySQLを骨までしゃぶるためのテクニックです。ソーシャルゲームは一般サイトよりもDBへの更新クエリの割合が多くなりがちです。更新クエリが多いMySQLでは、通常は有益なクエリキャッシュが無益どころか有害になります。そもそもキャッシュヒット率が低い。20%以下なんてこともザラにあるしかもクエリキャッシュの更新はグローバルなロックを取得するからです。特に後者は問題です。ただの参照クエリもクエリキャッシュを更新する上に、更新クエリはクエリキャッシュの全エントリをチェックして、更新したテーブルに影響がありそうな全キャッシュをdiscardしていくためです。たとえばユーザーの行動力のようなパラメータを格納した参照も更新も多いテーブルでクエリキャッシュが有効になって

tyoro1210 2016/01/26

リンク

MySQL Cache メモ - Qiita

メモと言う名のコピペちょっと古い、5.1 だけど日本語ドキュメントがそこしか無かったのと、英語読む気力ないけど、とりあえずめも動作とかごにょごにょクエリキャッシュは、SELECT SQL_CALC_FOUND_ROWS ... のクエリで動作し、後続する SELECT FOUND_ROWS() クエリで返る値を格納します。FOUND_ROWS() は前のクエリがキャッシュからフェッチしていても、正確な値を返します。これは、検索したレコードの数をキャッシュで保管しているためです。SELECT FOUND_ROWS() クエリ自体はキャッシュの対象ではありません。クエリをキャッシュする設定である場合、その結果 (クライアントに送信したデータ) を、結果の読み出し中に、クエリキャッシュに格納します。そのため、データの扱いは、ひとまとめではありません。つまり、クエリキャッシュで、デー

tyoro1210 2016/01/26

クエリキャッシュ『キャッシュしない条件』

リンク

MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.8 InnoDB の構成

このセクションでは、InnoDB の初期化、起動、および InnoDB ストレージエンジンのさまざまなコンポーネントと機能の構成情報と手順について説明します。 InnoDB テーブルのデータベース操作の最適化の詳細は、セクション8.5﹁InnoDB テーブルの最適化﹂を参照してください。

tyoro1210 2016/01/26

mysql
tuning

リンク

[ThinkIT] はじめてのMySQLチューニング第3回：max_connectionsとthread_cacheのチューニングを行う (1/3)

前回﹁第2回‥負荷によるベンチマークを試す﹂の測定結果では、測定途中でmax_connectionsに達してしまい、計画していた測定を完了することができませんでした。そこでmax_connectionsを増やして、再度測定してみましょう。 max_connectionsを増やすには2通りの手段があります。まず﹁/etc/my.cnf﹂に設定を追記する方法です。設定値は450に変更します。

tyoro1210 2016/01/26

mysql
tuning

リンク

MySQLTunerでMySQLのチューニングを診断する方法

https://github.com/rackerhacker/MySQLTuner-perl MySQLTunerはMySQLのチューニングを診断してくれるアプリケーションです。基本的なパフォーマンスチューニングのヒントをわかりやすく表示してくれます。 MySQLのチューニング設定に不安な方や、はじめてMySQLをさわる方は試してみると良いでしょう。ライセンスはGNU GPLで無料で使えます。検証環境 CentOS 6.3(64bit) MySQL 5.5.28 MySQL 5.5をインストール MySQL 5.5をインストールします。 # wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm # wget http://ftp.jaist.ac.jp/pub/Linux/Fedora/epel/6/x86

tyoro1210 2016/01/26

リンク

インデックスを使った高速化について(ORDERD BYにインデクスが使われない例) - LukeSilvia’s diary

今回は、MySQLの高速化のメモ - @luke_silvia.diaryの方法に従ってクエリの高速化をした際に、MySQLのインデックスについて分かったことを書いておきます。高速化対象のクエリ今回高速化したいクエリは、以下のようなもの。 SELECT users.*, students.school, workers.school FROM users LEFT JOIN students ON users.id = students.user_id LEFT JOIN workers ON users.id = workers.user_id WHERE (users.status= 1 AND ((kind = 0 AND students.school = 'test') OR (kind = 1 AND workers.school = 'test'))) ORDER BY

tyoro1210 2016/01/21

mysql
tuning

リンク

MySQL とメモリに関するまとめ - LukeSilvia’s diary

前回のエントリーデータベースを用いたセッションデータ管理についてで、MySQL とメモリの関係について良く分からない部分があると書きました。実はここに関する理解はかなり曖昧な部分があって、調査して追記します。とくにメモリ利用量について。mysqldのプロセスが利用できるメモリの上限が、32bitOSの場合は3G 程度ということは、innodb_buffer_pool_size もこの制限を受け、これについての警告が、先に紹介したリファレンスマニュアルのものという理解だけどいいのだろうかというのが1つ。2つ目は、この理解があっているとすると、4G 以上のクラスのメモリをつんだサーバをDB サーバとして利用する場合、64 bitOSでないとリソースの有効活用ができないか。それとも、先に書いたとおり、OSレベルのキャッシュとして利用できるから、結果としてデータファイルを読み込む

tyoro1210 2016/01/21

リンク

[ThinkIT] 第6回：query_cache_sizeの違いによるパフォーマンス比較 (1/3)

MySQLサーバには、MySQLクライアントからのクエリとその実行結果をキャッシュし、次回から同じ内容のクエリが要求された場合にキャッシュから応答する、クエリキャッシュという仕組みがあります。キャッシュから応答させることによってデータベースへアクセスする負荷を軽減し、また応答速度自体の向上も狙ったものです。デフォルト状態ではクエリキャッシュを使用しない設定になっています。以下のように現在の「クエリキャッシュに使用するメモリ量の最大値」であるquery_cache_sizeを確認してください。

tyoro1210 2016/01/21

mysql
tuning

リンク

オトコのソートテクニック2008

今日は仕事納めだったので、一年の締めくくりとしてMySQLにおけるソートの話でもしようと思う。インデックスを利用しないクエリで最もよく見かけるもののひとつは、ORDER BYを用いたソート処理だろう。もし、ソート処理においてインデックスを用いることが出来れば、MySQLは結果を抽出してから結果行をソートするのではなく、インデックス順に行を取り出せば良いので高速にソート処理することが可能になる。特に、LIMIT句やWHERE句を用いて行の絞り込みを行う場合は効果が絶大である。しかし、ひとたびインデックスを利用できない状況に直面すると、たちまちテーブルスキャンが発生して性能が劣化してしまう。例えば、100万行のレコードを格納したt1というテーブルがあるとする。そのテーブルに対して以下のようなクエリを実行した場合を考えよう。 mysql> SELECT col1, col2 ... colx

tyoro1210 2011/01/07

リンク

Using filesort

去年ソートに関する記事を書いたが、今日はその続きである。 MySQLでEXPLAIN SELECT...を実行するとExtraフィールドでよく見かける「Using filesort」という文字列。Filesortって一体なんだろう？と思ったことはないだろうか。単刀直入に言ってFilesortの正体はクイックソートである。クエリにORDER BYが含まれる場合、MySQLはある程度の大きさまでは全てメモリ内でクイックソートを処理する。ある程度の大きさとはsort_buffer_sizeであり、これはセッションごとに変更可能である。ソートに必要なメモリがsort_buffer_sizeより大きくなると、テンポラリファイル（テンポラリテーブルではない）が作成され、メモリとファイルを併用してクイックソートが実行される。 Filesortは全てのソート処理において実行されるわけではない。前回の記事

tyoro1210 2011/01/07

なんか美しくないしもっと整理できないかと思ったけど、サブクエリ内でlimitするしかねぇか。

リンク

なぜMySQLのサブクエリは遅いのか。

よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし