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

以上两者之间的上述时间小于5秒。为什么每次调用show index都会有如此大的差异？

这只发生在这张桌子上，我检查了几个更大的桌子，每次访问它们时都显示相同的数字

仅供参考：

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-06 11:55 EST

对 InnoDB 表执行 OPTIMIZE TABLE 是没有用的，因为一旦你这样做来尝试编译索引统计信息，如果 innodb_stats_on_metadata 仍然为 1，它往往会再次被重新读取。我在 2011 年 6 月的 DBA StackExchange 中写过这个。

更新 2012-03-06 11:59 EST

好的，既然您使用的是 MySQL 5.0.77，那么 OPTIMIZE TABLE 对于 InnoDB 中的索引统计信息再生来说只是普通的旧无用处。

OPTIMIZE TABLE 和 ANALYZE TABLE 仅适用于 MyISAM。

于 2012-03-06T16:47:39.310 回答
0

MySQL 通过从索引中随机抽取页面来确定索引的基数。页面具有不同的记录数和分布。

对于基数不变的索引，索引很可能适合单个页面，或者页面分布均匀（例如，来自优化表）。

如果计数变化很大，您可以考虑优化表以重新分配记录。这将帮助 MySQL 选择最佳索引。

于 2012-03-06T16:38:55.133 回答