今回はDbeaver をクライアントとして使ってみた。allowPublicKeyREtrieval がFALSEになっている。。。。。これでエラーで接続できなかったので、True にしておいた
参照URL https://donbura.hatenablog.com/entry/20240516_dbeaver_error
1. クエリの実行計画を確認する（EXPLAINの活用）
WordPressでクエリが遅い原因を特定するには、MySQLのEXPLAINコマンドを活用して、クエリの実行計画を確認します。
例えば、WordPressではプラグインやテーマが複雑なクエリを実行していることが多いため、それらのクエリを特定します。
具体例：
EXPLAIN SELECT * FROM wp_posts WHERE post_type = 'post' AND post_status = 'publish';
- 「
type」がALLの場合、フルテーブルスキャンが発生している可能性があり、インデックスの最適化が必要です。
2. スロークエリログの有効化
MySQLのスロークエリログを有効にして、遅いクエリを特定します。
スロークエリログの設定方法：
slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 1
実際にいれてみる
bash-5.1# echo -e "\n[mysqld]\nslow_query_log = 1\nslow_query_log_file = /var/log/mysql/slow.log\nlong_query_time = 1" | tee -a /etc/my.cnf
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
bash-5.1# cat /etc/my.cnf
# For advice on how to change settings please see
# http://dev.mysql.com/doc/refman/9.0/en/server-configuration-defaults.html
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 13. インデックスの確認・最適化
WordPressでは、特に以下のようなテーブル（例：wp_posts, wp_postmeta, wp_options）がパフォーマンスのボトルネックになりやすいです。
頻繁に使用されるクエリのWHERE句やJOIN句に利用されている列にインデックスを追加することで、クエリを高速化できます。
インデックスの追加例：
ALTER TABLE wp_postmeta ADD INDEX meta_key_meta_value (meta_key, meta_value(255));
注意:
- WordPressではデータ量が多いと
wp_postmetaテーブルがパフォーマンスの問題を引き起こすことが多いため、特にこのテーブルの最適化を検討します。
4. wp_optionsテーブルの負荷を軽減する
WordPressではwp_optionsテーブルにキャッシュデータや設定データが保存されます。このテーブルが肥大化すると、クエリが遅くなる原因となります。
対策：
- 不要なオプションデータ（特に
autoloadがyesのもの）を削除します。
SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';
- 不要なプラグインを無効化し、不要なオプションを削除します。
5. プラグイン・テーマの影響を調査する
遅いクエリの多くはプラグインやテーマによって引き起こされることがあります。
具体的な手順：
- プラグインの無効化
すべてのプラグインを無効にし、1つずつ有効化して、どのプラグインが原因となっているか特定します。 - デバッグモードを有効化
WordPressのwp-config.phpでデバッグモードを有効にしまする define('SAVEQUERIES', true); define('WP_DEBUG', true); define('WP_DEBUG_LOG', true);これにより、遅いクエリをデバッグログ（wp-content/debug.log）で確認できます。 ＞＞＞＞WP_DEBUGは有効な手段ではあるが、DBの遅延にのトラシューには使ったことがないな。次回何か機会があったらやってみようと思う。
6. クエリキャッシュの活用 結局これだったのかも。。。
MySQL 5.6ではクエリキャッシュを利用できますが、環境によっては設定が無効になっている場合があります。
設定例：
- MySQL設定ファイル（
my.cnfまたはmy.ini）に以下を追加query_cache_type = 1 query_cache_size = 64M - MySQLを再起動して適用します。
以前顧客のテーブルが大きいときに、一度select * で全文検索したら、そのあとにクエリの速度が改善したのを覚えている。これはキャッシュを利用していたからであろう。ただ、それが本当に原因であったのかについては いまとなっては、検証できない
その時使ったコマンドは SHOW STATUS LIKE ‘Qcache%’; だったと思う＜＜当時もググっていた
Variable_name | Value |
+-------------------------+-------+
| Qcache_hits | 200 |
| Qcache_inserts | 150 |
| Qcache_lowmem_prunes | 10 |
| Qcache_not_cached | 50 |
| Qcache_queries_in_cache | 75 |
| Qcache_total_blocks | 300
Qcache_hits: クエリキャッシュにヒットした回数。
Qcache_inserts: クエリがキャッシュに挿入された回数。
Qcache_not_cached: キャッシュされなかったクエリ数（キャッシュ対象外など）。
Qcache_lowmem_prunes: メモリ不足でキャッシュが削除された回数。Qcache_hits: がビシバシ増加していた。。。。。と記憶している。。。記憶は定かではない。最新のMysql では確かめられないので、時間があるときに確認してみよう
7. キャッシュプラグインの導入
WordPressでは、データベースの負荷を軽減するためにキャッシュプラグインを活用するのも有効です。
おすすめのプラグイン：
- WP Super Cache
- W3 Total Cache
- LiteSpeed Cache（LiteSpeedサーバーを利用している場合）
これらのプラグインを利用することで、ページキャッシュやデータベースクエリのキャッシュを簡単に実現できます。
8. データベースの分割やアーキテクチャの見直し
データが大量に増加している場合、以下の方法を検討します：
- データベースのアーカイブ（古いデータを別テーブルまたは別のデータベースに移動）。
- 読み取り専用クエリをレプリカ（リードレプリカ）で処理するように構成。
9. サーバーのリソースを確認する
オンプレ環境では、サーバーのリソース（CPU、メモリ、ディスクI/O）の確認も重要です。
- リソースが不足している場合、サーバーのアップグレードを検討します。
- ストレージがHDDの場合、SSDに変更することでディスクI/Oを大幅に改善できます。
10. MySQLのアップグレード
MySQL 5.6は古いバージョンのため、MySQL 5.7や8.0へのアップグレードを検討します。これにより、より高度な最適化機能やインデックスアルゴリズムが利用可能になります。
