为什么这个简单的查询在 MySQL 8.0.25 这么慢？

[yiplee]

有一张简单的表 t ，总共 11 个字段 ，关键字段如下：

1. id int64 自增主键
2. a char(36) NOT NULL
3. b char(36) NOT NULL
4. c char(36) NULL

除主键索引之外，还有两个索引：

1. UNIQUE INDEX (a)
2. INDEX (b)

现在有一个简单的查询

SELECT * FROM t WHERE b = ? AND c IS NOT NULL AND id > ? LIMIT 32 ORDER BY id ；

在表有大几千万条数据，并且 WHERE 匹配到的行数很多的时候，同样的数据在 MySQL 5.7.x 版本查询非常快，1s 以内，但是在另外一台 MySQL 8.0.25 上就要二十几秒，可能是什么原因呢？

[thinkershare]

where 匹配非常多, 优化器可能不走索引,本来就慢, 你这个做了读写分离没有? 插入很多时候会严重影响读取的性能.

[wanguorui123]

用性能分析命令看看

[liuxu]

自己分析优化器结果

https://www.liuquanhao.com/posts/mysql%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96%E5%99%A8%E4%BD%BF%E7%94%A8%E6%8C%87%E5%8D%97/

[yiplee]

@thinkershare #1 补充一些情况：

- 没有读写分离
- 这张表断断续续的有 insert ，没有 update ，insert 是起事务一次批量写入几十条

[xuanbg]

看下执行计划，讲道理这个查询是走索引的的，因为 b 列有索引。

[yiplee]

@liuxu #3 赞，我学习下

[yiplee]

@xuanbg #5 我也是这么以为的 😂

[circle33]

两台机器还有啥不一样吗？

[optional]

有 order by id 和>id 走的应该是主键索引，或者直接全表了。

[yiplee]

@circle33 #8 配置都不低，处理这张简单的表的数据量肯定是没问题的

[sulinwork]

explan 看看

[yiplee]

@optional #9 看执行时间应该是扫描了很多行

[circle33]

会不会慢的那台机器 `c IS NOT NULL` 的数据太多了

[LeegoYih]

试试用 force index
或者 order by (id+0)

[123qwerty]

在两个版本的 MySQL 中 explain 语句，看下有没有什么不同

[yiplee]

@circle33 #13 这张表 ```c IS NOT NULL``` 只有极少的行不满足，所以就没在 c 上加索引；两个数据库数据都是一样的。

[circle33]

explain 的 type 是什么

[rrfeng]

explain 打出来啊，看看走了哪个索引。
比如走了 b 还扫描了非常多行，说明 b 的值不够分散，加索引也没用。

[wolfie]

建联合索引，或者 force index(b)

[djoiwhud]

有点好奇，你的 sql 可以执行？

select * from table where order by limit n