mysql - SQL 'like' 比使用内部联接的 '=' 性能更快
问题描述
我们有 2 张桌子:
CREATE TABLE `task_information`
(
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`project_id` varchar(64) NOT NULL DEFAULT '0',
`task_id` varchar(64) NOT NULL DEFAULT '0',
`machine_id` varchar(16) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
KEY `idx_project` (`project_id`,`task_id`),
KEY `idx_task` (`task_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1100523 DEFAULT CHARSET=utf8mb4
CREATE TABLE `task_process`
(
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`task_id` varchar(64) NOT NULL DEFAULT '0',
`project_id` varchar(64) NOT NULL DEFAULT '0',
`status` varchar(16) NOT NULL DEFAULT '0'
PRIMARY KEY (`id`),
UNIQUE KEY `uniq_task` (`task_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1096437 DEFAULT CHARSET=utf8mb4
这两个表具有基于“task_id”的一对一关系。
这两个表有近 800K 条目。在“状态”栏中也会有很多“成功”。“状态”列正好有“成功”、“失败”和“开始”三个值,它们的比例大致为 100:1:1。
现在我想选择指定 machined_id 且状态等于“成功”的 task_id,我的 sql 查询如下所示:
select *
from task_information
inner join task_process on task_process.task_id = task_information.task_id
and task_information.machine_id = "RA00906"
where task_process.status="success"\G;
这个耗时 4.96s,explain 的结果如下:
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: task_process
partitions: NULL
type: ALL
possible_keys: uniq_task
key: NULL
key_len: NULL
ref: NULL
rows: 760145
filtered: 10.00
Extra: Using where
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: task_information
partitions: NULL
type: ref
possible_keys: idx_task
key: idx_task
key_len: 258
ref: task_process.task_id
rows: 1
filtered: 10.00
Extra: Using where
但是,如果我将“=”更改为“喜欢”,速度会变得更快(大约 0.9 秒):
select status
from task_information
inner join task_process on task_process.task_id = task_information.task_id
and task_information.machine_id = "RA00906"
where task_process.status like "success"
解释的结果是这样的:
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: task_information
partitions: NULL
type: ALL
possible_keys: idx_task
key: NULL
key_len: NULL
ref: NULL
rows: 759749
filtered: 10.00
Extra: Using where
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: task_process
partitions: NULL
type: eq_ref
possible_keys: uniq_task
key: uniq_task
key_len: 258
ref: task_information.task_id
rows: 1
filtered: 11.11
Extra: Using where
这两个查询都返回大约 500 行,但是“LIKE”比“=”快得多,尽管它们在功能上应该大致相同。
有人可以向我解释这背后的原因吗?
tl; dr 在同一个“内部联接”查询中使用“LIKE”比“=”快得多,这背后的原因是什么?
解决方案
推荐阅读
- java - 为什么在解析 JSON 的方法中设置字符串时返回 null?(底部返回全部为空)
- hbase - 通过 NiFi 将 HBase 数据库转储到不同的集群
- python - Get the contents of a specific attribute in span tag
- lets-encrypt - 为什么 Let's Encrypt 颁发的证书在一个小时左右无效?
- c# - 如何在剃刀视图中使用左外连接处理来自linq的空值的ViewBag
- python-3.x - 将图像从 Subreddit 保存到文件夹 python
- r - 在更新到 read_xlsx 之前返回 .name_repair 结果?
- sqlite - 如何在 react-native 中将对象存储在 sqlite 表中?
- python - 如何从 python 数据框中绘制每分钟的词频
- r - gsub to add leading zero to selected numbers in column names text to aid in sorting