数据对分析mysql表统计数据的影响

Question

我有一个MySQL数据库，它似乎会随着时间的推移而变慢。在进行了一些搜索之后，我确定数据库可能需要进行分析。这是因为innodb_stats_on_metadata被设置为OFF，而且我不知道任何定期安排的分析作业正在运行。

以下是我的几个问题：

1. 我如何确定这个数据库需要分析？上一次更新"stat“时，MySQL似乎没有存储，而且这个DB没有打开日志记录。
2. 这个数据库不断地进行插入/更新。我知道在分析过程中，没有什么东西可以写到数据库。这些书面请求会发生什么？他们会排队，还是会被丢弃？
3. mysqlcheck是否有机会破坏数据库？如果是，如何恢复数据？这是一个我不能冒险破坏的生产数据库..。

任何帮助都将不胜感激。

Answer 1

如果禁用innodb_stats_on_metadata，InnoDB仍然定期更新统计数据：

• 在重新启动MySQL服务器后第一次打开表。
• 当表更改1/16行时。
• 当表执行超过20亿行的更新时。
• 当客户端执行SQL语句ANALYZE TABLE <tablename>时。

此外，如果启用了InnoDB持久化统计 (默认情况下启用了它们)，则在更新表中至少10%的行之后更新统计数据。因此，InnoDB保持行更新的运行计数，如果这大于表大小的10%，它将触发一个stats更新。但是，有一个计数器本身不是持久的错误，所以如果mysqld重新启动，它将重置为0。

对于非常大的表(数亿行)，这是我公司中的一个问题。在更新10%的行之前，很可能会重新启动mysqld实例以进行升级或配置更改。所以基本上统计数据从来没有重新计算过！

我们解决了这个问题，方法是每天按计划运行一次服务，在表的随机子集上执行ANALYZE TABLE。所以每个表平均每十天重新分析一次。这是相当低的影响，它足以保持最新的统计数据，至少足够好的查询优化器作出好的选择。

Answer 2

如果您正在为您的表使用InnoDB引擎，那么#1是相关的。如果您正在使用MyISAM，那么#3是相关的。但是..。

您应该“永远”运行ANALYZE TABLE。(有一些例外，但它们非常罕见，所以我会认为问题在其他地方。)

可能的原因之一:您的数据已经增长到大于缓存(buffer_pool)。数据有多大？innodb_buffer_pool_size的价值是什么？你在用InnoDB吗？内存多少？

可能的原因2:有些查询没有完善的索引。设置long_query_time=1；打开慢速日志；等待一天；查看慢速日志中哪些是最慢的；回来征求意见。