[MySQL] 使用索引覆盖优化业务查询

矫情吗；* 2022-05-27 23:09 186阅读 0赞

一、

在MySQL表中，有一项无法忽略的部分，那就是**索引**——因为它直接或间接的决定了业务查询的时间复杂度。一个差的索引，会导致SQL操作需要扫描全表，来查出符合条件的数据行，这当然是一个悲剧。我们有必要，但也很容易去避免以下这种情况的发生，只要针对业务查询建对应的索引就可以了。

但是，只需要建出对应的索引就可以了吗？当然是不够的，核心操作业务如果需要的字段很少，通过索引覆盖，性能可以达到一个质的飞跃。

二、

在最近涉及的业务当中，有一个比较简单的点赞服务。模块维护人当时的建表是符合常理的：

CREATE TABLE `user_like` (
      `item_id` bigint(20) NOT NULL,
      `user_id` bigint(20) NOT NULL,
      `insert_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
      KEY (`user_id, item_id`),
      KEY (`user_id, insert_time`),) 
    ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

由于业务需求主要集中在两项：

1. 查看用户是否对这个东西点过赞：select count(1) from user\_like where user\_id=xx and item\_id=xx;

2. 查询用户的历史点赞列表：select \* from user\_like where user\_id=xx order by insert\_time desc;

咋一看这两个索引完美的契合了业务需求，但是实际上呢？

由于第2项业务在该产品中频繁的触发，即使有缓存还是有大量的SQL操作，虽然触发索引KEY (user\_id, insert\_time)找到了对应的记录，但是仍然需要读取磁盘来查找这条索引对应的item\_id字段，造成了一个庞大的开销。

解决办法就是将其改为KEY (user\_id, insert\_time, item\_id)，即保留了user\_id为某值且按insert\_time排序的查询需求，又在索引中保留有item\_id。这样第二项业务需求的查询，就被索引“覆盖了”。而单纯只查询索引的数值，基本上只需要通过内存中的缓存，因此减少了大量打到磁盘的I/O。