活久见,为什么SHOW TABLE STATUS总是不更新2

简介: 活久见,为什么SHOW TABLE STATUS总是不更新


那我们再看看文档中关于 IFS.TABLES 的描述吧:


25.36 The INFORMATION_SCHEMA TABLES Table

The TABLES table provides information about tables in databases.

Columns in TABLES that represent table statistics hold cached values. The information_schema_stats_expiry system variable defines the period of time before cached table statistics expire. The default is 86400 seconds (24 hours). If there are no cached statistics or statistics have expired, statistics are retrieved from storage engines when querying table statistics columns. To update cached values at any time for a given table, use ANALYZE TABLE. To always retrieve the latest statistics directly from storage engines, set information_schema_stats_expiry to 0. For more information, see Section 8.2.3, “Optimizing INFORMATION_SCHEMA Queries”.


看到这里,真相基本上呼之欲出了。

IFS.TABLES表中看到的数据是有cache的,默认cache时长是 86400秒(即1天),修改参数 information_schema_stats_expiry 即可调整时长。也就是说,除非cache过期了,或者手动执行 ANALYZE TABLE 更新统计信息,否则不会主动更新。

这个参数(功能)是MySQL 8.0后新增的,所以这个问题在8.0之前的版本不存在。

参数 information_schema_stats_expiry 还影响其 IFS.STATISTICS 表。

此外,该参数还可以在session级动态修改。

我们尝试修改session级配置:



[root@yejr.run]>set session information_schema_stats_expiry = 0;


# 修改完后就可以看到Rows数据变了
[root@yejr.run]>show table status like 'ttxx'\G
1. row **
Name: ttxx
Engine: InnoDB
Version: 10
Row_format: Dynamic
Rows: 795064
Avg_row_length: 57
...

[root@yejr.run]>set session information_schema_stats_expiry = 86400;
# 把session配置改回默认值,尴尬的发现Rows值又恢复成0了
[root@yejr.run] [test]>show table status like 'ttxx'\G
1. row **
Name: ttxx
Engine: InnoDB
Version: 10
Row_format: Dynamic
Rows: 0
...

看来,如果应用程序中有需要读取 table status 概要信息的时候,最好还是先手动执行 ANALYZE TABLE 或者修改参数值,也可以用下面这样的SQL:

select / set_var(information_schema_stats_expiry = 1) / * from information_schema.tables where table_schema='test' and table_name = 'ttxx'\G

这是MySQL 8.0后新增的HINT语法。

另外,文档中还有一段注释:

If the innodb_read_only system variable is enabled, ANALYZE TABLE may fail because it cannot update statistics tables in the data dictionary, which use InnoDB. For ANALYZE TABLE operations that update the key distribution, failure may occur even if the operation updates the table itself (for example, if it is a MyISAM table). To obtain the updated distribution statistics, set information_schema_stats_expiry=0.

意思是,当启用参数 innodb_read_only 后再执行 ANALYZE TABLE 就会失败,哪怕要更新统计信息的表是MyISAM引擎,因为所有InnoDB表都被设置为只读,更新统计信息后无法回写到对应的InnoDB字典表里了。

3. 总结

遇到诡异问题时,总是习惯性地先去查阅官方手册,通常都是可以得到答案的,耐心点,再耐心点。

            </div>
相关文章
|
关系型数据库 MySQL
925. 【mysql】convert 函数
925. 【mysql】convert 函数
477 3
|
NoSQL 索引 MongoDB
利用MongoDB的SplitVector命令实现并发数据迁移
数据迁移是数据库运维中一个很常见的场景。数据迁移分为全量和增量。为了追求速度,通常我们会采用并发的方式对数据进行全量迁移。在全量导出数据时,通常都会选择做到记录级的并发,因此通常会涉及到对需要导出的某个表(集合)按照并发度进行切分(分区)的过程。现有常用做法是通过若干个skip加limit来找到一些分区点,然后就可以并发同时导出多个分区。事实上MongoDB还有一个SplitVector命令特别适合用来做集合的分区。本文将介绍一下如何利用这个命令来对集合做分区,实现并发数据迁移。
7001 0
|
SQL 分布式计算 并行计算
PostgreSQL 并行计算解说 之1 - parallel seq scan
标签 PostgreSQL , cpu 并行 , smp 并行 , 并行计算 , gpu 并行 , 并行过程支持 背景 PostgreSQL 11 优化器已经支持了非常多场合的并行。简单估计,已支持27余种场景的并行计算。 parallel seq scan parallel index scan parallel index only scan
5232 0
|
存储 大数据 数据处理
ClickHouse中的ReplicatedMergeTree是什么
ClickHouse中的ReplicatedMergeTree是什么
1145 1
|
SQL 关系型数据库 MySQL
基于proxysql实现MySQL读写分离
基于proxysql实现MySQL读写分离
466 0
|
存储 Kubernetes 关系型数据库
使用开源ProxySQL构建PolarDB-X标准版高可用路由服务
本文将指导如何快速搭建和配置PolarDB-X标准版与ProxySQL,并提供验证高可用路由服务验证测试。
|
存储 NoSQL 关系型数据库
redis.conf 7.0 配置和原理全解,生产王者必备
redis.conf 7.0 配置和原理全解,生产王者必备
497 0
|
存储 SQL 关系型数据库
MySQL之深入InnoDB存储引擎——Checkpoint机制
一、引入 由于页的操作首先都是在缓冲池中完成的,那么如果一条DML语句改变了页中的记录,那么此时页就是脏的,即缓冲池中页的版本要比磁盘的新。那么数据库需要将新版本的页刷新到磁盘。倘若每次一个页发生变化就刷新,那么开销会很大,若热点数据集中在某几个页中,那么数据库的性能将变得非常差。
|
Rust Linux C语言
Rust让科学计算速度提升200倍
Rust 语言自身相对已经成熟,生态也足够丰富,并且在很多应用领域崭露头角。但是Rust陡峭的学习曲线让Rust目前依然是小众语言,缺乏成熟的开发者基础,这是CTO在引入Rust到技术栈时要考虑的重要问题。如果团队人才密度足够高,可以比较轻松地转到Rust,否则将会面临市场人才紧缺,能力参差不齐等问题,最终导致技术选型灾难。
608 0
Rust让科学计算速度提升200倍
|
缓存 安全 数据建模