警告
スケールやその他のコーナーケースの問題により、MySQL/Mariadbクエリキャッシュは推奨されなくなりました。 アプリケーションでキャッシュが処理されるようにすることを強くお勧めします 代わりにレベル。
ほとんどのLinuxシステムでは、デフォルトでインストールされるMySQLデータベースインスタンスは、安定した動作を保証するために安全な範囲のパラメータに設定されることがよくあります。クエリキャッシュ設定は通常、有効になっていないか、非常に控えめに設定されています。この保守的な結果として、データベースアクセスは、繰り返されるクエリをキャッシュするためにほとんどシステムメモリを使用しません。キャッシュを有効にしてアプリケーションのニーズに合わせて調整することで、ほとんどのアプリケーション、特にMagentoeコマースストアで改善が目に見える形で見られます。
最初のテストでは、開始点として32Mのキャッシュサイズが決定されました。変更する前は、 /etc/my.cnfにあるデータベースキャッシュパラメータ 次のように構成されました：
query_cache_limit 1M query_cache_size 0 query_cache_type ON
変更を加えるには、ファイル /etc/my.cnf 以下のパラメータを含むように編集され、データベースが再起動されました。変更後、データベースは次のことを報告します：
query_cache_limit 2M query_cache_size 32M query_cache_type ON
変更をテストするために、最初にデフォルトのデモ製品データベースがインストールされたMagentoeコマースストアをインストールしました。 siegeを使用してすべての製品のフェッチの時間を計りました。データベースのキャッシュサイズを増やすことで、サイトの応答時間がさらに200ミリ秒短縮されました。この単純な変更は、データベースサブシステムのパラメーターとレイアウトを改善して、Magentoでの使用に合わせて最適化する余地があることを示しています。ただし、Magentoの最適化は、せいぜいトリッキーな作業になる可能性があります。
トラップ！
人気のあるMySQLTunerスクリプト（MySQLパフォーマンスチューニングおよび最適化ガイドで詳しく説明されています）が実行され、スレッド数を変更すると有益であることが示されましたが、この変更によりパフォーマンスが低下しました。 290msで！
箱から出してすぐに、MySQLデータベース構成は優れていますが、大幅に改善される可能性があります。キャッシュを増やすと、すぐに有益な応答が得られました。データベースのパフォーマンスの強化に加えて、頻繁に参照されるデータをキャッシュすることでパフォーマンスを向上させるMemecachedやRedisなどのさまざまなキャッシュテクノロジーもあります。