4

反復1：

mysql> show table status LIKE "mybigusertable";
+-----------------+--------+---------+------------+---------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+--------------------------+
| Name            | Engine | Version | Row_format | Rows    | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time         | Update_time | Check_time | Collation       | Checksum | Create_options | Comment                  |
+-----------------+--------+---------+------------+---------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+--------------------------+
| mybigusertable | InnoDB |      10 | Compact    | 3089655 |           1686 |  5209325568 |               0 |    797671424 |         0 |        3154997 | 2011-12-04 03:46:43 | NULL        | NULL       | utf8_unicode_ci |     NULL |                | InnoDB free: 13775872 kB | 
+-----------------+--------+---------+------------+---------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-----------------+----------+----------------+--------------------------+

mysql> show index from mybigusertable;
+-----------------+------------+-----------------+--------------+--------------------+-----------+-------------+----------+--------+------+------------+---------+
| Table           | Non_unique | Key_name        | Seq_in_index | Column_name        | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+-----------------+------------+-----------------+--------------+--------------------+-----------+-------------+----------+--------+------+------------+---------+
| mybigusertable |          0 | PRIMARY         |            1 | someid         | A         |     3402091 |     NULL | NULL   |      | BTREE

反復2

mysql> show index from mybigusertable;
+-----------------+------------+-----------------+--------------+--------------------+-----------+-------------+----------+--------+------+------------+---------+
| Table           | Non_unique | Key_name        | Seq_in_index | Column_name        | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+-----------------+------------+-----------------+--------------+--------------------+-----------+-------------+----------+--------+------+------------+---------+
| mybigusertable |          0 | PRIMARY         |            1 | someid         | A         |     2811954 |     NULL | NULL   |      | BTREE

上記の2つの間の上記の時間は5秒未満でした。ショーインデックスが呼び出されるたびに、なぜこのような劇的な違いがあるのですか？

これはこのテーブルでのみ発生します。いくつかの大きなテーブルをチェックしたところ、アクセスするたびに同じ番号が表示されます。

参考までに、テーブルを頼りに：

mysql> select count(*) from mybigusertable;
+----------+
| count(*) |
+----------+
|  3109320 | 
+----------+
1 row in set (4 min 34.00 sec)

いくつかの質問：

  1. カーディナリティがそれほど変化するのはなぜですか？それは本当に重要ですか？
  2. オプティマイズテーブルはどれほど重要ですか？そしてそれはクエリをより速くしますか？
4

2 に答える 2

1

問題は、InnoDBのテーブルメタデータの処理方法に起因すると思います。

InnoDBは、カーディナリティを推測するインデックスに飛び込むことを伴う、何らかの形式の検索深度近似（ optimizer_search_depthによって指定される）を使用する傾向があります。

innodb_stats_on_metadataをオフに設定してみてください

SET GLOBAL innodb_stats_on_metadata = 0;

これにより、メタデータの読み取りが少し速くなり、クエリ実行プランが安定します。

更新2012-03-0611:55EST

InnoDBテーブルに対してOPTIMIZETABLEを実行しても、インデックス統計をコンパイルしようとすると、innodb_stats_on_metadataがまだ1の場合、再度読み取られる傾向があるため、役に立ちません。これについては、 2011年6月にDBAStackExchangeで書きました。

更新2012-03-0611:59EST

OK MySQL 5.0.77を使用しているので、OPTIMIZE TABLEは、InnoDBでのインデックス統計の再生成にはまったく役に立たないものです。

OPTIMIZETABLEとANALYZETABLEは、MyISAMでのみ完全に機能します。

于 2012-03-06T16:47:39.310 に答える
0

MySQLは、インデックスからランダムなページをサンプリングすることにより、インデックスのカーディナリティを決定します。ページにはさまざまなレコード数と分布があります。

カーディナリティが変更されないインデックスの場合、インデックスが1つのページに収まるか、ページが均等に分散されている可能性があります（たとえば、最適化テーブルから）。

カウントが大きく異なる場合は、テーブルを最適化してレコードを再配布することを検討してください。これは、MySQLが最適なインデックスを選択するのに役立ちます。

于 2012-03-06T16:38:55.133 に答える