mysql优化 案例_记一次MySQL的优化案例

一  背景

有赞的每个OLTP数据库实例上会设置一个sql-killer进程用于kill 掉执行时间超过一定阈值的sql。下午开发接收到sql被kill的报错,一起帮助开发排查,本文介绍该案例。

二 场景分析

表结构:

CREATE TABLE `xxx_info` (

`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 'id',

`user_id` bigint(20) unsigned NOT NULL DEFAULT '0' ,

`group_id` bigint(20) unsigned NOT NULL DEFAULT '0',

`nick_name` varchar(30) NOT NULL DEFAULT '' COMMENT '昵称',

`is_del` tinyint(5) NOT NULL DEFAULT '0' COMMENT '0:数据有效、1:数据逻辑删除',

`created_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',

`updated_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间',

PRIMARY KEY (`id`),

KEY `idx_userid_groupid` (`user_id`,`group_id`)

) ENGINE=InnoDB AUTO_INCREMENT=1382032 DEFAULT CHARSET=utf8mb4 ;

问题sql如下

SELECT id, name,status FROM xxx_info WHERE user_id IN (670039223,'373149878') AND group_id = 1 AND is_del = 0;

第一眼看到sql ,先检查了表结构 和索引 user_id 是数值类型的,且索引ok 然后手工执行计划竟然没有走idx_userid_groupid索引,

8162a9b2fd2d2126c583bfbd950a7bb5.png

怀疑 user_id in 两种不同类型的字段导致"隐式转换",将 其中参数值都换为数值类型或者字符串 或者使用 user_id=数值类型 or user_id=字符串,再次执行

8c91ab0f5d6af81a85d35eb8a3617d5a.png

e0a3aeaed6c390275a28fde9bdc10afe.png

执行计划都是正确。对此我们要解决两个问题

那么为啥当user_id in (X,Y,Z) 是不同类型时,就不走索引了呢?

我们使用optimizer_trace 来跟踪执行计划。

set session optimizer_trace='enabled=on';

SELECT id, nick_name,is_del  FROM xxx_info WHERE user_id IN (670039223,'373149878') AND group_id = 1 AND is_del = 0;

select * from information_schema.optimizer_trace;

SELECT id, nick_name,is_del FROM xxx_info WHERE user_id IN (670039223,'373149878') AND group_id = 1 AND is_del = 0;

select * from information_schema.optimizer_trace;

set session optimizer_trace='enabled=off';

获取两个sql的执行计划并对比,结果显示

b55c0151cb841f95da69b26cbcc3ec67.png

看到结果我表示

140bb635abb6e044f8aa4f7ac84efbce.png

代码里面如何产生不同类型的值?

以下是开发(阿杜)自己的测试

5068ce5072c233f4980cada197575447.png

目前的解决方式是和开发同学沟通让他们在程序做参数类型一致性校验,都转换为 int/long 类型。

特别提醒常见发生隐式转换导致索引失效的场景

1  where 判断符号左边是字符串 ,右边是数值 比如

where  name = 123

2  多表join关联条件的字段类型不一致,类似于 1

3  多表join关联条件字符集类型不一样。比如

a 表 order_no 是utf8mb4 ,b 表order_no 是 utf8

感兴趣的 朋友可以多测试,有其他案例的 欢迎讨论。

以上就是记一次MySQL的优化案例的详细内容,更多关于MySQL优化案例的资料请关注脚本之家其它相关文章!

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值