MySQL到底是 join 性能好,还是in一下更快呢?

先总结:

  1. 数据量小的时候,用join更划算

  2. 数据量大的时候,join的成本更高,但相对来说join的速度会更快

  3. 数据量过大的时候,in的数据量过多,会有无法执行SQL的问题,待解决

事情是这样的,去年入职的新公司,之后在代码review的时候被提出说,不要写join,join耗性能还是慢来着,当时也是真的没有多想,那就写in好了,最近发现in的数据量过大的时候会导致sql慢,甚至sql太长,直接报错了。

这次来浅究一下,到底是in好还是join好,仅目前认知探寻,有不对之处欢迎指正

以下实验仅在本机电脑试验

一、表结构

1、用户表

 CREATE TABLE <code>user (
  id int NOT NULL AUTO_INCREMENT,
  name varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL COMMENT '姓名',
  gender smallint DEFAULT NULL COMMENT '性别',
  mobile varchar(11) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL COMMENT '手机号',
  create_time datetime NOT NULL COMMENT '创建时间',
  PRIMARY KEY (id),
  UNIQUE KEY mobile (mobile) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1005 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci

2、订单表

CREATE TABLE <code>order (
  id int unsigned NOT NULL AUTO_INCREMENT,
  price decimal(18,2) NOT NULL,
  user_id int NOT NULL,
  product_id int NOT NULL,
  status smallint NOT NULL DEFAULT '0' COMMENT '订单状态',
  PRIMARY KEY (id),
  KEY user_id (user_id),
  KEY product_id (product_id)
) ENGINE=InnoDB AUTO_INCREMENT=202 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci

二、先来试少量数据的情况

用户表插一千条随机生成的数据,订单表插一百条随机数据

查下所有的订单以及订单对应的用户

下面从三个维度来看

多表连接查询成本 = 一次驱动表成本 + 从驱动表查出的记录数 * 一次被驱动表的成本

1、join

JOIN:

explain format=json select order.id, price, user.`name` from `order` join user on order.user_id = user.id;<br>

order查出来的结果过长了,,,

3、代码层面

in

join

四、到底怎么才能更好

注:对于本机来说100000条数据不少了,更大的数据量害怕电脑卡死

总的来说,当数据量小时,可能一页数据就够放的时候,join的成本和速度都更好。数据量大的时候确实分开查的成本更低,但是由于数据量大,造成循环的成本更多,代码执行的时间也就越长。

实验过程中发现,当in的数据量过大的时候,sql过长会无法执行,可能还要拆开多条sql进行查询,这样的查询成本和时间一定也会更长,而且如果有分页的需求的话,也无法满足。。。

感觉这两个方法都不是太好,各位小伙伴,有没有更好的方法呢?