MySQL索引选择底层原理探究从一个慢查询说起 | 技术创作特训营第一期

一. 背景与问题

在生产环境中收到一个接口耗时预警, 通过监控发现, 接口耗时达到了89s, 最终定位到了是因为触发了一个sql慢查询场景.

MySQL索引选择底层原理探究从一个慢查询说起 | 技术创作特训营第一期-每日运维

下面本文会通过慢查询分析, 引出mysql底层优化器在索引选择上的策略以及特性, 并给出索引的最佳实践.

二. 慢查询sql与数据规模

2.1 慢sql

上面告警对应的慢sql如下, 其目的是根据指定条件筛选并排序返回前10条数据.

select col_list
from dal_meta_table_par_info_d
where fstore_server='tdw_cft' and ftb_name='ods_evt_zxg_cft_mta_event_hh'
      and fdb_name='ods_base'
order by fpar_name desc
limit 10;

2.2 数据量以及索引配置

(1) 表dal_meta_table_par_info_d的数据总量为: 5110万

(2) 索引定义主要有如下五个 (其中本文重点讨论的是第三个和第四个):

  • PRIMARY KEY (fid)
  • UNIQUE KEY uk_uid (ftb_uid, fpar_name)
  • UNIQUE KEY uk (ftb_name(255), fdb_name(100), fpar_name(50), fserver_id ) (表名+库名+分区名+serverId的联合唯一索引)
  • KEY ix_par_name (fpar_name) (分区名字段的普通索引)
  • KEY `ix_tb_ss_par` ( `ftb_name`(255), `fdb_name`(100), `fstore_server`, `fpar_name`(50))