ANALYZE [NO_WRITE_TO_BINLOG | LOCAL]
TABLE tbl_name [, tbl_name] ...
ANALYZE TABLE
执行键分布分析并存储指定表的分布。对于MyISAM
表,此语句等效于使用myisamchk --analyze。
ANALYZE TABLE
适用于
InnoDB
、NDB
和
MyISAM
表格。它不适用于视图。
ANALYZE TABLE
支持分区表,可以ALTER TABLE ...
ANALYZE PARTITION
用来分析一个或多个分区;有关详细信息,请参阅第 13.1.7 节,“ALTER TABLE 语句”和
第 19.3.4 节,“分区的维护”。
在分析过程中,表被 和 的读锁
InnoDB
锁定MyISAM
。
ANALYZE TABLE
从表定义缓存中删除表,这需要刷新锁。如果有长时间运行的语句或事务仍在使用该表,则后续语句和事务必须等待这些操作完成才能释放刷新锁。因为ANALYZE TABLE
它本身通常很快完成,所以涉及同一个表的延迟事务或语句可能并不明显是由于剩余的刷新锁。
默认情况下,服务器将ANALYZE
TABLE
语句写入二进制日志,以便它们复制到副本。要禁止记录日志,请指定可选
NO_WRITE_TO_BINLOG
关键字或其别名
LOCAL
。
ANALYZE TABLE
返回一个结果集,其列如下表所示。
柱子 | 价值 |
---|---|
Table |
表名 |
Op |
总是analyze |
Msg_type |
status , error ,
info ,note 或
warning |
Msg_text |
信息性消息 |
如果自上次键分布分析以来该表未发生变化,则不会再次分析该表。
MySQL 使用存储的键分布来决定表连接顺序以连接常量以外的东西。此外,在决定将哪些索引用于查询中的特定表时,可以使用键分布。
要检查存储的密钥分布基数,请使用
SHOW INDEX
语句或
INFORMATION_SCHEMA
STATISTICS
表。请参阅
第 13.7.5.23 节,“SHOW INDEX 语句”和
第 21.3.22 节,“INFORMATION_SCHEMA STATISTICS 表”。
对于InnoDB
表,
ANALYZE TABLE
通过对每个索引树执行随机潜水并相应地更新索引基数估计来确定索引基数。因为这些只是估计值,重复运行
ANALYZE TABLE
可能会产生不同的数字。这使得表格ANALYZE
TABLE
速度很快InnoDB
但不是 100% 准确,因为它没有考虑所有行。
您可以
通过启用使收集
的统计信息ANALYZE TABLE
更精确、更稳定
innodb_stats_persistent
,如第 14.8.11.1 节“配置持久优化器统计参数”中所述。启用后,在
对索引列数据进行重大更改后innodb_stats_persistent
运行很重要ANALYZE
TABLE
,因为不会定期重新计算统计信息(例如在服务器重启后)。
如果innodb_stats_persistent
启用,您可以通过修改
innodb_stats_persistent_sample_pages
系统变量来更改随机潜水次数。如果
innodb_stats_persistent
禁用,请
innodb_stats_transient_sample_pages
改为修改。
有关键分布分析的更多信息
InnoDB
,请参阅
第 14.8.11.1 节,“配置持久优化器统计参数”和
第 14.8.11.3 节,“估计 InnoDB 表的分析表复杂性”。
MySQL 在连接优化中使用索引基数估计。如果连接未以正确的方式优化,请尝试运行
ANALYZE TABLE
. 在少数情况下,ANALYZE TABLE
您的特定表不能产生足够好的值,您可以使用FORCE INDEX
查询来强制使用特定索引,或设置
max_seeks_for_key
系统变量以确保 MySQL 更喜欢索引查找而不是表扫描。请参阅第 B.3.5 节,“与优化器相关的问题”。
ANALYZE TABLE
从表中清除表统计信息
INFORMATION_SCHEMA.INNODB_SYS_TABLESTATS
并将STATS_INITIALIZED
列设置为Uninitialized
。下次访问表时会再次收集统计信息。
仅在 MySQL 5.6.11 中,
gtid_next
必须
AUTOMATIC
在发出此语句之前设置为。(错误#16062608、错误#16715809、错误#69045)