回答:
MySQLの最大メモリ使用量が非常に多く、ハードウェア、お使いの設定に依存し、データベース自体。
ハードウェアは明らかな部分です。RAMが多いほど、高速なディスクftwになります。ただし、月刊または週刊のニュースレターは信じないでください。MySQLはリニアにスケーリングしません。Oracleハードウェア上でもです。それより少しトリッキーです。
結論としては、 MySQLセットアップに推奨されるものについて一般的な経験則はありません。それはすべて、現在の使用法または予測に依存します。
MySQLはその動作を最適化するために無数の変数とスイッチを提供します。問題が発生した場合は、座って（f'ing）マニュアルを読む必要があります。
データベースについて-いくつかの重要な制約：
InnoDB、MyISAM、...）Stackoverflowに関するほとんどのMySQLのヒントでは、5〜8と呼ばれる、いわゆる重要な設定について説明しています。まず、それらすべてが問題になるわけではありません。たとえば、InnoDBに多くのリソースを割り当ててInnoDBを使用しないことは、それらのリソースが無駄になるため、あまり意味がありません。
または、多くの人がmax_connection変数を増やすことを提案します-まあ、彼らがそれに応えるためにMySQLがより多くのリソースを割り当てることを意味することをほとんど知らないmax_connections-必要な場合。より明白な解決策は、DBALのデータベース接続を閉じるか、を下げてwait_timeoutそれらのスレッドを解放することです。
私のドリフトに気づいたら、本当にたくさん読んで、学ぶことがたくさんあります。
テーブルエンジンは非常に重要な決定です。多くの人は早い段階でそれらを忘れて、突然MyISAM、アプリケーション全体をロックしてブロックする30 GBサイズのテーブルと戦っています。
MyISAMが悪いと言うつもりはありませんが、InnoDB微調整してほぼまたはほぼ同じ速さで応答しMyISAM、行ロックをオンにするなどUPDATE、MyISAM書き込み時にテーブル全体をロックすることができます。
MySQLを独自のインフラストラクチャで自由に実行できる場合は、perconaサーバーをチェックアウトすることもできます。これは、FacebookやGoogleなどの企業からの寄稿が多数含まれているため（それらは高速です）、Percona独自のドロップも含まれているためです。の代わりにInnoDB、と呼ばれXtraDBます。
（Ubuntuでの）percona-server（および-client）セットアップの要点を参照してください：http ://gist.github.com/637669
データベースのサイズは非常に重要です。信じられないかもしれませんが、Intarwebsのほとんどの人は、大規模な処理を行わず、強力なMySQLセットアップを作成したことはありませんが、実際には存在しています。一部の人々は「PostgreSQLを使用してください!!! 111」のようなものをトロールして言うでしょうが、今のところそれらを無視しましょう。
肝心なのは、サイズから判断して、ハードウェアに関する決定を行うことです。1 GBのRAMで80 GBのデータベースを高速に実行することはできません。
それはそうではありません。必要なインデックスのみを設定し、使用状況をで確認する必要がありますEXPLAIN。それに加えて、MySQL EXPLAINは本当に制限されていますが、それは始まりです。
これらmy-large.cnfとmy-medium.cnfファイルについて-私はそれらが誰のために書かれたのかも知りません。あなた自身を転がします。
すばらしいスタートはチューニングの入門書です。出力をとります。これはbashスクリプト（Linuxを必要とするでしょうヒント）だSHOW VARIABLESとSHOW STATUS、うまくいけば便利な勧告にそれをラップします。サーバーがしばらく実行されている場合は、それらの基礎となるデータがあるため、推奨事項はより優れています。
ただし、チューニングプライマーはマジックソースではありません。それでも、変更が提案されているすべての変数を確認する必要があります。
私は本当にmysqlperformanceblogをお勧めします。これは、MySQL関連のあらゆる種類のヒントに関する優れたリソースです。また、MySQLだけでなく、適切なハードウェアについて多くの知識があり、AWSのセットアップを推奨しています。これらの担当者は、長年の経験があります。
もちろん、もう1つの優れたリソースはplanet-mysqlです。
tuning primer、それはどのように比較しmysqltunerますか？
次の設定を使用します。
etc/my.cnf
innodb_buffer_pool_size = 384M
key_buffer = 256M
query_cache_size = 1M
query_cache_limit = 128M
thread_cache_size = 8
max_connections = 400
innodb_lock_wait_timeout = 100次の仕様のサーバーの場合：
Dell Server
CPU cores: Two
Processor(s): 1x Dual Xeon
Clock Speed: >= 2.33GHz
RAM: 2 GBytes
Disks: 1×250 GB SATAデータベースのメモリ使用量は複雑なトピックです。MySQLのパフォーマンスのブログには、あなたの質問をカバーするのは良い仕事をして、リストには「予備」メモリに非常非現実的だ多くの理由。
本当にハード制限を課したい場合は可能ですが、組み込み設定がないため、OSレベルで行う必要があります。Linuxではulimitを利用できますが、これを強制するためにMySQLの起動方法を変更する必要があるでしょう。
最善の解決策は、サーバーを調整して、通常のMySQLメモリ設定の組み合わせにより、MySQLインストールによるメモリ使用量が一般的に低くなるようにすることです。もちろん、これはデータベースのパフォーマンスに悪影響を及ぼしますが、調整できる設定には次のものがありますmy.ini。
key_buffer_size
query_cache_size
query_cache_limit
table_cache
max_connections
tmp_table_size
innodb_buffer_pool_size私はそこから始めて、あなたが望む結果を得ることができるかどうかを確認します。MySQLのメモリ設定の調整については、数多くの 記事があります。
編集：
MySQLの新しい5.1.xリリースでは一部の変数名が変更されていることに注意してください。
例えば：
table_cache今です：
table_open_cachemysqld.exeはRAMで480 MBを使用していました。このパラメーターをmy.iniに追加したことがわかりました
table_definition_cache = 400メモリ使用量を400,000+ kbから105,000kbに削減
で/etc/my.cnf：
[mysqld]
...
performance_schema = 0
table_cache = 0
table_definition_cache = 0
max-connect-errors = 10000
query_cache_size = 0
query_cache_limit = 0
...256MBのメモリを搭載したサーバーで良好な動作。
table_definition_cache= 0なのですか？いくつかの説明がいいでしょう。そして、基本的にクエリをキャッシュしていません...次の場合も同じ効果がありますquery_cache_type = 0:)
docker mysqlコンテナーの最適化を検討している場合は、以下のコマンドが役立つ場合があります。mysql docker containerをデフォルトの480mbから単なる100 mbに実行できました
docker run -d -p 3306：3306 -e MYSQL_DATABASE = test -e MYSQL_ROOT_PASSWORD = tooor -e MYSQL_USER = test -e MYSQL_PASSWORD = test -v / mysql：/ var / lib / mysql --name mysqldb mysql --table_definition_cache = 100 --performance_schema = 0 --default-authentication-plugin = mysql_native_password