如何解决mysql解释类型索引与所有性能问题
我有下表：我有350万条记录。
.conda
.docker
.ipython
.jupyter
.matplotlib
...
只有CREATE TABLE `video_downloads` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,`user_id` bigint(20) NOT NULL,`video_id` bigint(20) NOT NULL,`download_at` datetime NOT NULL,PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3573041 DEFAULT CHARSET=latin1
和id是user_id。
这是我的查询：
indexed使用当前表设置，此查询使我花费了大约10分钟以上的时间来运行。
这是select max(video_id),user_id
from video_downloads
group by user_id
explain| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
|----|-------------|-----------------|-------|---------------|---------|---------|-----|---------|-------|
| 1 | SIMPLE | video_downloads | index | | user_id | 8 | | 3562709 | |
然后我删除了运行相同查询的{
"query_block": {
"select_id": 1,"table": {
"table_name": "video_downloads","access_type": "index","key": "user_id","key_length": "8","used_key_parts": ["user_id"],"rows": 3562709,"filtered": 100
}
}
}
的索引，这花了我大约user_id。
这里是1.5 s，没有explain索引
user_id| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
|----|-------------|-----------------|------|---------------|-----|---------|-----|---------|---------------------------------|
| 1 | SIMPLE | video_downloads | ALL | | | | | 3562709 | Using temporary; Using filesort |
我认为我的主要问题是，为什么使用{
"query_block": {
"select_id": 1,"filesort": {
"sort_key": "video_downloads.user_id","temporary_table": {
"table": {
"table_name": "video_downloads","access_type": "ALL","filtered": 100
}
}
}
}
}
上的索引在时间上有如此大的差异。并且当user_id上有索引时，user_id为type，这意味着它正在使用索引，但是查询非常慢。
我对结果感到有些困惑，我认为我不明白为什么会这样，我检查official doc仍然没有完全理解。
更新我认为主要原因可能是使用index数据从磁盘中获取行，并且它将一个接一个地随机执行。因此，这是从磁盘随机读取的350万次。那是我能想到的唯一原因。但是，那会这么慢吗？ （超过index与10 mins ???）。
但是，来自MySQL doc
有时，即使索引可用，MySQL也不使用索引。发生这种情况的一种情况是，优化器估计使用索引将需要MySQL访问表中很大比例的行。
就我而言，MySQL似乎没有做出正确的决定。我可以看到1.5 s是possible_keys，但是null仍在使用索引，为什么？是因为key吗？
解决方法
优化器使用的“统计信息”并不总是完美的。但是，“ 10分钟”与“ 1.5秒”相当壮观。我想知道是否有外界干扰。哦，正在使用什么引擎？
使用单列索引时，它可能必须在索引和数据之间跳动，一次只能读取350万行，但是随机的。
进行表扫描（“全部”）时，它还会读取350万行，但顺序读取。但随后必须进行某种跟进。
缓冲池
innodb_buffer_pool_size的16M是问题。除非您的计算机特别小，否则将其设置为RAM大小的大约70％。
10分钟的查询可能是可靠的I / O，它随机地读取和重新读取表中的数据。
在旋转磁盘（HDD，而非SDD）上，以100个块/秒的速度读取3.5M数小时。因此，您很幸运仅在10分钟之内完成了任务。 1.5s表示足够大的RAM缓存有用。
1.5s可能是一次（不随机地）遍历整个表格一次所需要的全部时间。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。