mysql 这个查询速度正常吗，怎么优化？

[cleveryun]

买的数据库是阿里云的，配置信息：

• 数据库类型：MySQL8.0
• 规格族：通用型
• CPU：2 核
• 数据库内存：16384 M
• 规格默认连接数：8000
• 最大 IOPS：6800
• 实例规格：mysql.n8m.medium.2c

目前有 4 千万不到的数据，我拆成了 8 个表，每个表放 500 万行数据。单张表的表结构如下：

create table `bio-hub`.`pubmed-article-0`
(
    pm_id             int           not null
        primary key,
    title             varchar(2000) not null,
    author            text          not null,
    lang              varchar(255)  null,
    abstract          text          null,
    keywords          text          null,
    journal_title     varchar(255)  null,
    journal_pub_year  varchar(255)  null,
    journal_pub_month varchar(255)  null,
    journal_i_s_s_n   varchar(255)  null,
    mesh_ids          varchar(2000) null,
    mesh_cat          varchar(2000) null comment '医学主题词所属分类，如`A01`',
    created_at        datetime      not null,
    updated_at        datetime      not null
);

create index `pubmed-article-0_journal_pub_year`
    on `bio-hub`.`pubmed-article-0` (journal_pub_year);

现状是我再 DataGrip 里光执行下面这样一句 count 都要三四十秒（首次，没缓存的情况下），是我哪里姿势不对吗，这也太慢了。带上关键词查询的 sql 不得更慢了。怎么破？

更新：我人在上海，数据库节点也是上海的。

SELECT COUNT(1) FROM `pubmed-article-1`;

[opengps]

mysql 的 count 好像本身就慢

[28Sv0ngQfIE7Yloe]

感觉楼上没说到点子上吧，你直接用阿里的 DMS 平台查下

[noparking188]

你 DataGrip 确定没问题嘛，你直接 mycli 命令行连上去 count 看看时间

[realNewBee]

正常，这个数据量这个配置，count 就是慢。所以，如果非得查询全表的数据，不走条件的情况下，必须得根据实际需求来换种查法

[justfindu]

count(*) 试一试, 不要 1 .

[sleepybear1113]

weibo> SELECT COUNT(*)
FROM weibo.hot_search_realtime t

[2023-10-30 11:52:23] completed in 5 m 59 s 185 ms

总共行数：2892 7376

基础型-1 核 1000MB 内存，100GB 存储空间，高性能云盘，IOPS:2300

比你的稍微慢一点点。从上海访问成都。

[sleepybear1113]

exam_data> SELECT COUNT(*)
FROM exam_data.admission_data t
[2023-10-30 11:57:56] completed in 256 ms

行数：45 4828
实例规格 1 核/1GB 最大 IOPS 8000 TDSQL-C MySQL 兼容数据库 MySQL5.7

这个快不少

[9y7cz863P00C7Lie]

MySQL 从 8.0.17 开始对于无条件的 count(*)会强制走主键，即使执行计划里面写的是走二级索引，这是因为因为在这个版本更新了并行扫描主键的功能。由于你的机器 CPU 配置不高，肯定跑不出好的效果。所以从结果上来说就比 5.7 的扫描二级索引要慢

[yh7gdiaYW]

mysql 做这个量级的统计查询时就是很慢（当然你这个有点不正常），我们当初因为这个换了 MongoDB ，现在准备换到 StarRocks （这玩意儿速度太逆天了）

[iyaozhen]

count(*)=count(1)>count(主键字段)>count(字段) 这个不认同，可以让楼主试下，count 啥都是慢

按之前经验来看，就是慢，不要不加 where 条件的 count 。用前面大家说的估算方法

带上关键词查询的 sql 不得更慢了，NO 。你 where 命中索引是很快的，几百万一张表几乎不需要啥优化。

[MoYi123]

mysql 的 count 就是这样的, 具体原因和事务隔离有关系;

[tangyiyong]

会不会是因为索引建在 varchar(255)上的问题？文本的字段一般不能做索引吧？

[tangyiyong]

journal_pub_year varchar(255) null,

create index `pubmed-article-0_journal_pub_year`
on `bio-hub`.`pubmed-article-0` (journal_pub_year);

索引里允许 null ？

[ccagml]

这种是不是得阿里云监控看看有什么指标达到瓶颈了吗？感觉也太慢了

[sivacohan]

fio --ioengine=libaio --bs=4k --direct=1 --thread --time_based --rw=randrw --filename=/root/io_test --runtime=300 --numjobs=1 --iodepth=1 --group_reporting --name=randread-dep1 --size=256M


测一下磁盘 IO 性能看看

[cleveryun]

大佬们求救，最新的情况我 Append 追加了。

[cleveryun]

字段长度我都改成实际数据中各字段实际最长的长度值了

[cleveryun]

@sivacohan 这是是要在服务器上跑吗，我买的是单独的数据库，只能跑 sql 语句。

[cleveryun]

@tangyiyong 已修改，年月都改成数字重新建了索引

[cleveryun]

@iyaozhen 我的场景要用到类似 like '%keyword%'的功能。用户会用关键词搜。