前言
不管是Oracle还是MySQL，新版本推出的新特性，一方面给产品带来功能、性能、用户体验等方面的提升，另一方面也可能会带来一些问题，如代码bug、客户使用方法不正确引发问题等等。
案例分享
MySQL 5.7下的场景
（1）首先，创建两张表，并插入数据
mysql> select version();
+------------+
| version() |
+------------+
| 5.7.30-log |
+------------+
1 row in set (0.00 sec)
mysql> show create table test\G
*************************** 1. row ***************************
Table: test
Create Table: CREATE TABLE `test` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`k` int(10) unsigned NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `k_1` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=101 DEFAULT CHARSET=utf8mb4 MAX_ROWS=1000000
1 row in set (0.00 sec)
mysql> show create table sbtest1\G
*************************** 1. row ***************************
Table: sbtest1
Create Table: CREATE TABLE `sbtest1` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`k` int(10) unsigned NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `k_1` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=1000001 DEFAULT CHARSET=utf8mb4 MAX_ROWS=1000000
1 row in set (0.00 sec)
mysql> select count(*) from test;
+----------+
| count(*) |
+----------+
| 100 |
+----------+
1 row in set (0.00 sec)
mysql> select count(*) from sbtest1;
+----------+
| count(*) |
+----------+
| 1000000 |
+----------+
1 row in set (0.14 sec)
（2）查看两张表的统计信息，均比较准确
mysql> select table_schema,table_name,table_rows from tables where table_name='test'; +--------------+------------+------------+ | table_schema | table_name | table_rows | +--------------+------------+------------+ | test | test | 100 | +--------------+------------+------------+ 1 row in set (0.00 sec) mysql> select table_schema,table_name,table_rows from tables where table_name='sbtest1'; +--------------+------------+------------+ | table_schema | table_name | table_rows | +--------------+------------+------------+ | test | sbtest1 | 947263 | +--------------+------------+------------+ 1 row in set (0.00 sec)
（3）我们持续往test表插入1000w条记录，并再次查看统计信息，还是相对准确的，因为在默认情况下，数据变化量超过10%，就会触发统计信息更新
mysql> select count(*) from test; +----------+ | count(*) | +----------+ | 10000100 | +----------+ 1 row in set (1.50 sec) mysql> select table_schema,table_name,table_rows from tables where table_name='test'; +--------------+------------+------------+ | table_schema | table_name | table_rows | +--------------+------------+------------+ | test | test | 9749036 | +--------------+------------+------------+ 1 row in set (0.00 sec)
MySQL 8.0下的场景
（1）接下来我们看看8.0下的情况吧，同样地，我们创建两张表，并插入相同记录
mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.20 |
+-----------+
1 row in set (0.00 sec)
mysql> show create table test\G
*************************** 1. row ***************************
Table: test
Create Table: CREATE TABLE `test` (
`id` int unsigned NOT NULL AUTO_INCREMENT,
`k` int unsigned NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `k_1` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=101 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci MAX_ROWS=1000000
1 row in set (0.00 sec)
mysql> show create table sbtest1\G
*************************** 1. row ***************************
Table: sbtest1
Create Table: CREATE TABLE `sbtest1` (
`id` int unsigned NOT NULL AUTO_INCREMENT,
`k` int unsigned NOT NULL DEFAULT '0',
`c` char(120) NOT NULL DEFAULT '',
`pad` char(60) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `k_1` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=1000001 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci MAX_ROWS=1000000
1 row in set (0.00 sec)
mysql> select count(*) from test;
+----------+
| count(*) |
+----------+
| 100 |
+----------+
1 row in set (0.00 sec)
mysql> select count(*) from sbtest1;
+----------+
| count(*) |
+----------+
| 1000000 |
+----------+
1 row in set (0.02 sec)
（2）查看两张表的统计信息，均比较准确
mysql> select table_schema,table_name,table_rows from tables where table_name='test'; +--------------+------------+------------+ | TABLE_SCHEMA | TABLE_NAME | TABLE_ROWS | +--------------+------------+------------+ | test | test | 100 | +--------------+------------+------------+ 1 row in set (0.00 sec) mysql> select table_schema,table_name,table_rows from tables where table_name='sbtest1'; +--------------+------------+------------+ | TABLE_SCHEMA | TABLE_NAME | TABLE_ROWS | +--------------+------------+------------+ | test | sbtest1 | 947468 | +--------------+------------+------------+ 1 row in set (0.01 sec)
（3）同样地，我们持续往test表插入1000w条记录，并再次查看统计信息，发现table_rows显示还是100条，出现了较大偏差
mysql> select count(*) from test; +----------+ | count(*) | +----------+ | 10000100 | +----------+ 1 row in set (0.33 sec) mysql> select table_schema,table_name,table_rows from tables where table_name='test'; +--------------+------------+------------+ | TABLE_SCHEMA | TABLE_NAME | TABLE_ROWS | +--------------+------------+------------+ | test | test | 100 | +--------------+------------+------------+ 1 row in set (0.00 sec)
原因剖析
那么导致统计信息不准确的原因是什么呢？其实是MySQL 8.0为了提高information_schema的查询效率，将视图tables和statistics里面的统计信息缓存起来，缓存过期时间由参数information_schema_stats_expiry决定，默认为86400s；如果想获取最新的统计信息，可以通过如下两种方式：
（1）analyze table进行表分析
（2）设置information_schema_stats_expiry=0
继续探索
那么统计信息不准确，会带来哪些影响呢？是否会影响执行计划呢？接下来我们再次进行测试
测试1：表test记录数100，表sbtest1记录数100w
执行如下SQL，查看执行计划，走的是NLJ，小表test作为驱动表(全表扫描)，大表sbtest1作为被驱动表(主键关联)，执行效率很快
mysql> select count(*) from test; +----------+ | count(*) | +----------+ | 100 | +----------+ 1 row in set (0.00 sec) mysql> select count(*) from sbtest1; +----------+ | count(*) | +----------+ | 1000000 | +----------+ 1 row in set (0.02 sec) mysql> select table_schema,table_name,table_rows from tables where table_name='test'; +--------------+------------+------------+ | TABLE_SCHEMA | TABLE_NAME | TABLE_ROWS | +--------------+------------+------------+ | test | test | 100 | +--------------+------------+------------+ 1 row in set (0.00 sec) mysql> select table_schema,table_name,table_rows from tables where table_name='sbtest1'; +--------------+------------+------------+ | TABLE_SCHEMA | TABLE_NAME | TABLE_ROWS | +--------------+------------+------------+ | test | sbtest1 | 947468 | +--------------+------------+------------+ 1 row in set (0.01 sec) mysql> select t.* from test t inner join sbtest1 t1 on t.id=t1.id where t.c='08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977' and t1.c='08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977'; +----+--------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+ | id | k | c | pad | +----+--------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+ | 1 | 501885 | 08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977 | 63188288836-92351140030-06390587585-66802097351-49282961843 | +----+--------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+ 1 row in set (0.00 sec) mysql> explain select t.* from test t inner join sbtest1 t1 on t.id=t1.id where t.c='08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977' and t1.c='08566691963-88624912351-16662227201-4664 +----+-------------+-------+------------+--------+---------------+---------+---------+-----------+------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-------+------------+--------+---------------+---------+---------+-----------+------+----------+-------------+ | 1 | SIMPLE | t | NULL | ALL | PRIMARY | NULL | NULL | NULL | 100 | 10.00 | Using where | | 1 | SIMPLE | t1 | NULL | eq_ref | PRIMARY | PRIMARY | 4 | test.t.id | 1 | 10.00 | Using where | +----+-------------+-------+------------+--------+---------------+---------+---------+-----------+------+----------+-------------+ 2 rows in set, 1 warning (0.00 sec)
测试2：表test记录数1000w左右，表sbtest1记录数100w
再次执行SQL，查看执行计划，走的也是NLJ，相对小表sbtest1作为驱动表，大表test作为被驱动表，也是正确的执行计划
mysql> select count(*) from test; +----------+ | count(*) | +----------+ | 10000100 | +----------+ 1 row in set (0.33 sec) mysql> select count(*) from sbtest1; +----------+ | count(*) | +----------+ | 1000000 | +----------+ 1 row in set (0.02 sec) mysql> select table_schema,table_name,table_rows from tables where table_name='test'; +--------------+------------+------------+ | TABLE_SCHEMA | TABLE_NAME | TABLE_ROWS | +--------------+------------+------------+ | test | test | 100 | +--------------+------------+------------+ 1 row in set (0.00 sec) mysql> select table_schema,table_name,table_rows from tables where table_name='sbtest1'; +--------------+------------+------------+ | TABLE_SCHEMA | TABLE_NAME | TABLE_ROWS | +--------------+------------+------------+ | test | sbtest1 | 947468 | +--------------+------------+------------+ 1 row in set (0.01 sec) mysql> select t.* from test t inner join sbtest1 t1 on t.id=t1.id where t.c='08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977' and t1.c='08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977'; +----+--------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+ | id | k | c | pad | +----+--------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+ | 1 | 501885 | 08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977 | 63188288836-92351140030-06390587585-66802097351-49282961843 | +----+--------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+ 1 row in set (0.37 sec) mysql> explain select t.* from test t inner join sbtest1 t1 on t.id=t1.id where t.c='08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977' and t1.c='08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977'; +----+-------------+-------+------------+--------+---------------+---------+---------+------------+--------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-------+------------+--------+---------------+---------+---------+------------+--------+----------+-------------+ | 1 | SIMPLE | t1 | NULL | ALL | PRIMARY | NULL | NULL | NULL | 947468 | 10.00 | Using where | | 1 | SIMPLE | t | NULL | eq_ref | PRIMARY | PRIMARY | 4 | test.t1.id | 1 | 10.00 | Using where | +----+-------------+-------+------------+--------+---------------+---------+---------+------------+--------+----------+-------------+ 2 rows in set, 1 warning (0.01 sec)
为什么优化器没有选择错误的执行计划呢？之前文章也提过，MySQL 8.0是将元数据信息存放在mysql库下的数据字典表里，information_schema库只是提供相对方便的视图供用户查询，所以优化器在选择执行计划时，会从数据字典表中获取统计信息，生成正确的执行计划。
总结
MySQL 8.0为了提高information_schema的查询效率，会将视图tables和statistics里面的统计信息缓存起来，缓存过期时间由参数information_schema_stats_expiry决定(建议设置该参数值为0)；这可能会导致用户查询相应视图时，无法获取最新、准确的统计信息，但并不会影响执行计划的选择。
以上就是MySQL 8.0统计信息不准确的原因的详细内容，更多关于MySQL 8.0统计信息不准确的资料请关注其它相关文章！
免责声明：本站文章均来自网站采集或用户投稿，网站不提供任何软件下载或自行开发的软件！
如有用户或公司发现本站内容信息存在侵权行为，请邮件告知！ 858582#qq.com
暂无“MySQL 8.0统计信息不准确的原因”评论...
《魔兽世界》大逃杀！60人新游玩模式《强袭风暴》3月21日上线
暴雪近日发布了《魔兽世界》10.2.6 更新内容，新游玩模式《强袭风暴》即将于3月21 日在亚服上线，届时玩家将前往阿拉希高地展开一场 60 人大逃杀对战。
艾泽拉斯的冒险者已经征服了艾泽拉斯的大地及遥远的彼岸。他们在对抗世界上最致命的敌人时展现出过人的手腕，并且成功阻止终结宇宙等级的威胁。当他们在为即将于《魔兽世界》资料片《地心之战》中来袭的萨拉塔斯势力做战斗准备时，他们还需要在熟悉的阿拉希高地面对一个全新的敌人──那就是彼此。在《巨龙崛起》10.2.6 更新的《强袭风暴》中，玩家将会进入一个全新的海盗主题大逃杀式限时活动，其中包含极高的风险和史诗级的奖励。
《强袭风暴》不是普通的战场，作为一个独立于主游戏之外的活动，玩家可以用大逃杀的风格来体验《魔兽世界》，不分职业、不分装备（除了你在赛局中捡到的），光是技巧和战略的强弱之分就能决定出谁才是能坚持到最后的赢家。本次活动将会开放单人和双人模式，玩家在加入海盗主题的预赛大厅区域前，可以从强袭风暴角色画面新增好友。游玩游戏将可以累计名望轨迹，《巨龙崛起》和《魔兽世界：巫妖王之怒 经典版》的玩家都可以获得奖励。
更新动态
2024年11月24日
2024年11月24日
- 凤飞飞《我们的主题曲》飞跃制作[正版原抓WAV+CUE]
- 刘嘉亮《亮情歌2》[WAV+CUE][1G]
- 红馆40·谭咏麟《歌者恋歌浓情30年演唱会》3CD[低速原抓WAV+CUE][1.8G]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[320K/MP3][193.25MB]
- 【轻音乐】曼托凡尼乐团《精选辑》2CD.1998[FLAC+CUE整轨]
- 邝美云《心中有爱》1989年香港DMIJP版1MTO东芝首版[WAV+CUE]
- 群星《情叹-发烧女声DSD》天籁女声发烧碟[WAV+CUE]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[FLAC/分轨][748.03MB]
- 理想混蛋《Origin Sessions》[320K/MP3][37.47MB]
- 公馆青少年《我其实一点都不酷》[320K/MP3][78.78MB]
- 群星《情叹-发烧男声DSD》最值得珍藏的完美男声[WAV+CUE]
- 群星《国韵飘香·贵妃醉酒HQCD黑胶王》2CD[WAV]
- 卫兰《DAUGHTER》【低速原抓WAV+CUE】
- 公馆青少年《我其实一点都不酷》[FLAC/分轨][398.22MB]
- ZWEI《迟暮的花 (Explicit)》[320K/MP3][57.16MB]