上一篇整理完了 MySQL 的性能优化方式 , 其中最常用的就是 explain .
这一篇来详细看看 explain 中各个参数的含义和扩展 , 整理出来便于使用时快速查询
在日常实践中 , 我们应该如何使用 explain 提供的查询来判断索引怎么配置呢?
以一个实际业务场景为例 : 首先场景里面的数据分布都很均衡 , 这就导致设置的索引在查询优化器的处理下 , 很难产生最好的效果.
先来看一下表结构 :
CREATE TABLE `user_info` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键id',
`user_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '会员ID',
`user_no` bigint(20) NOT NULL DEFAULT '0' COMMENT '会员编号',
`open_id` varchar(128) NOT NULL DEFAULT '' COMMENT '外部ID',
`org_id` varchar(128) NOT NULL DEFAULT '0' COMMENT '组织ID',
`listen_num` int(11) NOT NULL DEFAULT '0' COMMENT '记录次数',
`create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
`create_person` varchar(50) NOT NULL DEFAULT '' COMMENT '创建人',
`update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
`update_person` varchar(50) NOT NULL DEFAULT '' COMMENT '更新人',
PRIMARY KEY (`id`),
KEY `idx_user_id` (`user_id`),
KEY `idx_org_id_open_id` (`org_id`,`open_id`) USING BTREE,
KEY `idx_create_time` (`create_time`) USING BTREE,
KEY `idx_update_time` (`update_time`) USING BTREE
) COMMENT='会员记录表';
复制代码
需要获取到记录次数 (listen_num) > 0 用户的会员编号 (user_no)(A/B/C/D) , 每种数据预计占25% - 30%修改后会更新 update_time基础信息
// 1. 总记录数 4200000
// 2. 不同 org_id 下的记录数
- 1234567890 : 100万
- 9876543210 : 100万
- 8888888888 : 100万
- 6666666666 : 100万
- 其他 : 20万
// 3. 时间周期
> 2022-01
> 2022-12
复制代码
listen_num 本身没有创建索引 , 以该字段查肯定会走全表 , 优先考虑的思路就是 > user_id 为条件进行有序查询 :
explain select * from user_info where user_id > 69999887 and listen_num > 0
复制代码