MySQL 永続統計の詳細な説明

1. 永続的な統計情報の重要性:

統計は、MySQL が実行プランを生成するためのガイドとして使用されます。実行プランの精度は、SQL 実行の効率に直接影響します。

以前の統計は消えているので、SQL ステートメントが来ると、MySQL は統計を収集し、SQL ステートメントの実行を生成します。

プラン。 MySQL をシャットダウンするときに統計を保存できる場合は、起動時に再度統計を収集する必要はありません。

効率の向上に役立ちます。

第二に、統計情報の正確さも同様に重要です。

最初のセクションでは、持続的な統計の重要性について説明しました。統計は有用で正確であるという前提があります。統計自体が

これは時代遅れです。たとえば、テーブルに 100 行しかないときに統計が計算される場合、テーブル全体のスキャンの方がコストが低くなることがよくあります。

ウールの布！現在、テーブルの行数は100万に達しています。このような古い統計情報はパフォーマンスに悪影響を及ぼすため、統計情報の適時性も重要です。

も同様に重要です。では、MySQL はいつ統計を自動的に更新するのでしょうか?デフォルトでは、データの 10% が変更されるとテーブルが更新されます。

3. MySQL による統計情報の処理:

MySQL には上記の両方の問題に対する解決策があり、どちらも簡単な設定で解決できます。

1. MySQLで統計情報を保持するかどうかは、innodb_stats_persistentパラメータで制御できます。

2. 統計情報の適時性に関しては、MySQLはinnodb_stats_auto_recalcパラメータを使用して、統計情報を自動的に更新するかどうかを制御します。

3. 統計情報の正確性を保つため、MySQLはinnodb_stats_persistent_sample_pagesパラメータを通じて更新を制御します。

統計情報のサンプリングに使用されるサンプルページの数。

4. 統計を手動で更新します。

MySQLはanalyze tableステートメントを使用して手動で統計を更新します。

5. テーブルの統計がいつ更新されるかを確認します。

MySQL は、mysql.innodb_table_stats と mysql.innodb_index_stats の 2 つのテーブルに統計を記録します。

mysql.innodb_table_stats はテーブルごとに統計を記録します。

mysql> innodb_table_stats から * を選択します。
+---------------+----------------------------+---------------------+--------+-----------------------+--------------------------+
| データベース名 | テーブル名 | 最終更新日 | n 行 | クラスター化インデックス サイズ | その他のインデックス サイズの合計 |
+---------------+----------------------------+---------------------+--------+-----------------------+--------------------------+
| fdb | auth_group | 2017-08-10 14:36:40 | 0 | 1 | 1 |
| fdb | auth_group_permissions | 2017-08-10 14:36:41 | 0 | 1 | 2 |
| fdb | auth_permission | 2017-08-10 14:36:41 | 30 | 1 | 1 |
| fdb | auth_user | 2017-08-10 14:36:41 | 0 | 1 | 1 |
| fdb | auth_user_groups | 2017-08-10 14:36:41 | 0 | 1 | 2 |
| fdb | auth_user_user_permissions | 2017-08-10 14:36:41 | 0 | 1 | 2 |
| fdb | cninfo_company | 2017-08-10 14:36:58 | 4996 | 161 | 6 |
| fdb | csindex_indexdetail | 2017-09-17 14:04:27 | 0 | 1 | 0 |
| fdb | csindex_indexoverview | 2017-09-01 12:44:18 | 11 | 1 | 0 |
| fdb | django_admin_log | 2017-08-10 14:36:47 | 0 | 1 | 2 |
| fdb | django_content_type | 2017-08-10 14:36:47 | 10 | 1 | 1 |
| fdb | django_migrations | 2017-09-04 14:04:09 | 37 | 1 | 0 |
| fdb | django_session | 2017-08-10 14:36:47 | 0 | 1 | 1 |
| fdb | glod_glodprice | 2017-08-10 14:36:48 | 2271 | 10 | 0 |
| fdb | pbc_moneysupply | 2017-08-10 14:37:08 | 78 | 1 | 0 |
| fdb | shibor_shiborrate | 2017-08-10 14:37:18 | 2711 | 14 | 0 |
| fdb | sse_marketoverview | 2017-08-15 16:06:12 | 0 | 1 | 0 |
| mysql | gtid_executed | 2017-09-06 11:02:14 | 2 | 1 | 0 |
| sys | sys_config | 2017-08-10 12:19:06 | 6 | 1 | 0 |
| tempdb | 人 | 2017-09-14 11:18:15 | 1 | 1 | 0 |
| tmp | t | 2017-08-15 11:06:18 | 2 | 1 | 0 |
+---------------+----------------------------+---------------------+--------+-----------------------+--------------------------+
セット内の行数は 21 です (0.00 秒)

各列の意味:

database_name テーブルが配置されているデータベースの名前

table_name テーブル名

last_update 最終更新時刻

n_rows テーブル内の行数

clustered_index_size 主キーのサイズ

sum_of_other_index_sizes すべてのセカンダリインデックスのサイズ

6. テーブル分析プロセスに関する経験:

explan ステートメントを使用して SQL 実行プランを表示すると、プランが正確ではないことがわかります。これは主に、統計情報が古くなっていることが原因です。

実行プランを再生成するために analyze table を実行する必要がある場合もありますが、実行プランを再生成しても無駄であることがわかる場合もあります。

SQL はまだ正しく動作しません。最も可能性の高い原因は、実行プランを生成するときのサンプルページの数が少なすぎることです。

このパラメータの値は大きすぎないようにしてください。大きすぎると、分析テーブルステートメントの実行が完了するまでに長い時間がかかります。