mysql analyze_MySQL 案例:analyze,慢查询,与查询无响应

当MySQL执行计划不准确导致查询变慢时,通常会使用ANALYZE TABLE来更新统计信息。然而,在某些情况下,ANALYZE后,SELECT查询可能会无响应。解决方法是杀死在ANALYZE之前开始但未结束的慢查询。本文通过实例分析了此问题的原因,指出ANALYZE TABLE会导致表结构变化,进而需要等待所有线程关闭该表,造成阻塞。
摘要由CSDN通过智能技术生成

问题描述

MySQL 偶尔会遇到执行计划不准,导致查询变慢,这时候一般会怀疑是索引信息不准,去 analyze 一下,然后再 select 试一下,这时候可能会发现,select 会进入无响应的状态,并且 analyze 的这个表上其他正常的查询都会进入无响应的状态。

解决方案

如果这种现象已经发生了,可以尝试 kill 掉“最早的”那些慢查询。

即如果 tb1 上有慢查询,且进行了 analyze 后遇到了问题,找一下 tb1 上在 analyze 之前已经开始执行,但是没结束的慢查询,然后全部 kill 掉。

问题还原

先来构造一下场景:

CREATE TABLE `stu` (

`id` int(11) NOT NULL,

`name` varchar(16) DEFAULT NULL,

`age` int(11) DEFAULT NULL,

PRIMARY KEY (`id`),

KEY `idx_name` (`name`),

KEY `idx_age` (`age`),

KEY `idx_n_a` (`name`,`age`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

INSERT INTO `stu` VALUES (9,'adam',25),(7,'carlos',25),(1,'dave',19),(5,'sam',22),(3,'tom',22),(11,'zoe',29);

这时候来伪造一个长时间执行的慢查询:

mysql> select sleep(3600) from stu;

然后在其他的 session 模拟 analyze 和 select 的操作:

mysql> analyze table stu;

+----------+---------+----------+----------+

| Table | Op | Msg_type | Msg_text |

+----------+---------+----------+----------+

| test.stu | analyze | status | OK |

+----------+---------+----------+----------+

1 row in set (0.00 sec)

mysql> select * from stu limit 1;

这时候会发现这个 limit 1 的语句也会被阻塞,而且也不会触发innodb_lock_wait_timeo

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值