随笔分类 -  MySQL Execution Plan

摘要:## 测试环境 MySQL版本: 5.7.27-30-log Percona Server (GPL), wsrep_31.39 涉及表结构: ```SQL CREATE TABLE `scout_job` ( `task_id` varchar(22) NOT NULL DEFAULT '' CO 阅读全文
posted @ 2023-08-07 14:11 TeyGao 阅读(130) 评论(1) 推荐(0) 编辑
摘要:Semi-Join Subquery优化策略 Semi-Join Subquery(半连接子查询):对应IN或EXISTS子查询,仅需要检查"外表记录"在"子查询结果集"中是否存在匹配记录,不需要计算"子查询结果集"中记录匹配次数,也不需要返回"子查询结果集"中匹配记录内容 在MariaDB(MyS 阅读全文
posted @ 2023-05-06 18:04 TeyGao 阅读(168) 评论(0) 推荐(0) 编辑
摘要:问题描述 在很多业务场景中业务需要过滤掉重复数据,对于MySQL数据库可以有多种SQL写法能实现这种需求,如: 使用DISTINCT,如: SELECT DISTINCT username FROM hotel_owner WHERE username IN ('user001','user002' 阅读全文
posted @ 2023-04-21 16:44 TeyGao 阅读(53) 评论(0) 推荐(0) 编辑
摘要:1、问题场景 在很多业务存在增量抽取数据的场景,当抽取数据量较大时,通常采用分批方式按照主键进行抽取,以抽取表footprint_detail_info最近一天数据为例。表footprint_detail_info的结构为: CREATE TABLE `footprint_detail_info` 阅读全文
posted @ 2022-07-29 11:31 TeyGao 阅读(175) 评论(0) 推荐(0) 编辑
摘要:INDEX MERGE导致的查询预估行数不准问题 问题描述 某业务集群实例每秒读取记录数长时间很高(每秒超过150万): 抓取135秒全量慢日志分析,按照预估行数排序得到: *************************************************************** 阅读全文
posted @ 2022-07-27 17:16 TeyGao 阅读(135) 评论(0) 推荐(0) 编辑
摘要:问题描述 在排查某次业务慢SQL时,发现SQL执行计划异常,业务表结构为: CREATE TABLE `xxxx_user_cancellation` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键', `user_id` in 阅读全文
posted @ 2022-04-13 19:11 TeyGao 阅读(276) 评论(0) 推荐(0) 编辑
摘要:问题描述 有慢SQL如下: SELECT vendor.id, third_vendor_id, ctrip_id, vendor_type, vendor.lat as lat, vendor.lon as lon, vendor.create_time, vendor.update_time, 阅读全文
posted @ 2021-12-21 21:54 TeyGao 阅读(299) 评论(0) 推荐(0) 编辑
摘要:在MySQL处理ORDER BY语句时,如果查询无法利用索引的有序性,则需要额外操作对数据进行排序。在MySQL中有三种排序算法: 1、快速排序(Quick Sort),对冒泡排序的一种改进,基本思想是选取一个记录作为枢轴,经过一趟排序,将整段序列分为两个部分,其中一部分的值都小于枢轴,另一部分都大 阅读全文
posted @ 2019-12-17 18:40 TeyGao 阅读(548) 评论(0) 推荐(0) 编辑
摘要:安装Query Rewrite Plugin 在MySQL的安装目录的share文件夹下,有两个文件用来安装和卸载Query Rewrite Plugin: 安装完成后,可以使用下面脚本查看功能是否启用: 演示Demo 1、插入重写规则 2、加载规则 3、测试重写: 可以发现SQL语句中的换行或空格 阅读全文
posted @ 2019-10-29 11:04 TeyGao 阅读(593) 评论(0) 推荐(0) 编辑
摘要:COUNT全表记录 在MySQL中,相同的SQL不同的存储引擎执行计划不同: 现有测试表TB101: 对于没有WHERE条件的COUNT(*)/COUNT(1)/COUNT(ID)/COUNT(C1)的执行计划为: 对于没有WHERE条件的COUNT(C2)的执行计划为: 可以发现,对于MyISAM 阅读全文
posted @ 2019-10-27 23:59 TeyGao 阅读(413) 评论(0) 推荐(0) 编辑
摘要:问题描述 优化过程中遇到一个SQL: 其执行计划为: 从执行计划来看,使用Using index(覆盖索引)已经是最优的执行计划,但每次查询扫描数据较多,影响整体查询性能。 优化方案 查询需要使用SUM计算user_value的总和,借用1+1+0+0+0+0+0=1+1=2的例子,进行如下测试: 阅读全文
posted @ 2019-10-11 15:45 TeyGao 阅读(339) 评论(0) 推荐(0) 编辑
摘要:将大于或小于的范围查询装换为等值查询 在生产环境,经常会遇到需要对Worker表进行多次尝试的业务,超过一定重试次数后抛弃或使用其他方式处理,在查找满足重试条件数据时,通常会使用“小于”运算符并伴随排序操作,这种场景很容易出现性能问题。 如下面查找执行次数小于最大执行次数的记录的SQL: 表中数据分 阅读全文
posted @ 2019-08-27 17:47 TeyGao 阅读(541) 评论(0) 推荐(0) 编辑
摘要:问题描述 研发同事反馈某应用执行较慢,对应SQL为: 表bs_serial_trac上索引情况为: 由于使用OR条件,查询只能基于条件GOODS_NO = '4418095740626' 进行数据查找,其执行计划为: 由于GOODS_NO列选择性较差,满足条件的记录较多,导致查询性能较差: 解决步骤 阅读全文
posted @ 2019-08-05 16:25 TeyGao 阅读(731) 评论(0) 推荐(0) 编辑
摘要:问题描述 在系统中发现一条执行时间为为44652.060734秒(12.5小时)的慢SQL,SQL语句为: 对于执行计划为: 由于两个表上都使用全表扫描,需要循环外表ob_internal_task记录1654884次*内表ob_internal_orderstatus记录622596次=10303 阅读全文
posted @ 2019-07-05 11:34 TeyGao 阅读(273) 评论(0) 推荐(0) 编辑
摘要:在一次的优化过程中,由于没有关注执行计划中type列,仅看key列来查看"使用到的索引",导致优化过程走了不少弯路。 以下面SQL为例: 走索引查找的执行计划为: 走索引扫描执行计划为: 上面两个执行计划都使用索引idx_wave_no,但: 第一个执行计划影响行数为14238,与IN查询中的值数量 阅读全文
posted @ 2019-04-25 21:25 TeyGao 阅读(365) 评论(0) 推荐(0) 编辑
摘要:SQL语句: 执行计划: 执行计划JOSN: 将wave_no IN修改为CONCAT(wave_no,'') IN进行测试 SQL语句: 执行计划: 执行计划JSON: 去除org_No/distribute_No/warehouse_No任意列的过滤条件,如去除AND org_No= '661' 阅读全文
posted @ 2019-04-23 14:01 TeyGao 阅读(325) 评论(0) 推荐(0) 编辑
摘要:问题描述 版本:MySQL 5.7.24 SQL语句: 该SQL在慢日志中记录执行信息为: 表picking_locate_d上索引如下: 表picking_locate_d上数据量为: 当IN查询内部的值数量小于等于14238时,查询时间0.31秒,执行计划为: 当IN查询内部的值数量大于等于14 阅读全文
posted @ 2019-04-22 20:15 TeyGao 阅读(271) 评论(0) 推荐(0) 编辑
摘要:MySQL Explain新用法: 在EXPLAIN的输出结果中,有一行Type用来表示MYSQL使用哪种访问类型来从MYSQL表中找到需要的行。 使用EXPLAIN EXTENDED 命令+SHOW WARNINGS命令来看在SQL语句被执行前被执行优化器改写成的新SQL: 阅读全文
posted @ 2019-04-17 22:26 TeyGao 阅读(403) 评论(0) 推荐(0) 编辑
摘要:在某系统中想使用NOT IN子查询进行数据过滤,SQL为: 上面SQL执行时间未6.84秒,相关表数据量为:表TB001:507716表TB002:11266065 为验证NOT IN 子查询对查询的影响,移除NOT IN子查询后,SQL调整为: SQL执行时间未0.15秒 将上面NOT IN语句转 阅读全文
posted @ 2019-04-17 14:47 TeyGao 阅读(171) 评论(0) 推荐(0) 编辑
摘要:在很多业务场景中,会使用NOT EXISTS语句来确保返回数据不存在于特定集合,部分场景下NOT EXISTS语句性能较差,网上甚至存在谣言"NOT EXISTS无法走索引"。 首先需要明确的是:索引不是万能的,使用索引的执行计划并不一定就是最好的执行计划。 以某监控平台为例,使用NOT EXIST 阅读全文
posted @ 2019-04-17 00:00 TeyGao 阅读(708) 评论(0) 推荐(0) 编辑

点击右上角即可分享
微信分享提示