mysql查询优化实战:查询用时一分半降到三毫秒

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,集群系列 2核4GB
简介: 项目中的课程预约记录查询功能,线下门店反馈说进入到页面需要等2分钟

背景问题说明


   项目中的课程预约记录查询功能,线下门店反馈说进入到页面需要等2分钟,按理来说,现在数据记录数并不大,应该不会到2分钟.看了一下查询sql,发现仅sql的执行时间就已经1分19秒.经过处理,相同的数据,查询用时已经降到34毫秒,虽然不算是最优的处理方式,但是应该能满足门店的使用了.下面就说一下问题处理过程,希望对有sql优化有同样困惑的同学能所有帮助.


问题处理过程


1.表结构说明以及问题sql

   sql中涉及表:manage_course_record、manage_staff、manage_staff_card、manage_course_table、manage_course、manage_user_studio、manage_studio;所有表有主键索引,其中仅manage_staff_card中card_no有唯一索引。

问题sql:

SELECT 
  manage_course_record.id course_record_id,manage_staff_card.`card_no`,manage_staff.`real_name` staff_name,manage_staff.`mobile`,
  DATE_FORMAT(manage_course_record.`start_time`,'%Y-%m-%d %H:%i') start_time,
        manage_course.`course_name`, manage_user_studio.`user_name` teacher_name,manage_studio.studio_name,manage_studio.id'studioId',
        manage_course_record.`status`,manage_card.`card_name`,manage_course_record.apply_count,manage_staff_card.card_type,manage_course_record.type course_type
        ,IF(NOW()>manage_course_record.start_time,TRUE,FALSE) course_start_flag
        FROM manage_course_record FORCE INDEX(in_type_create_time)
        LEFT JOIN manage_staff_card ON manage_staff_card.`card_no`=manage_course_record.`card_no`
        LEFT JOIN manage_staff ON manage_course_record.`login`=manage_staff.`login`
        LEFT JOIN manage_card ON manage_card.`id`=manage_staff_card.`card_id`
        LEFT JOIN manage_course_table ON manage_course_table.`id`=manage_course_record.`data_id` AND manage_course_table.`studio_id`=manage_course_record.`studio_id`
        LEFT JOIN manage_course ON manage_course.`id`=manage_course_table.`course_id` AND manage_course.`studio_id`=manage_course_table.`studio_id`
        LEFT JOIN manage_user_studio ON manage_user_studio.`login`=manage_course_table.`teacher_id` AND manage_user_studio.`studio_id`=manage_course_table.`studio_id`
        LEFT JOIN manage_studio ON manage_studio.`id`= manage_course_record.`studio_id`
        WHERE manage_course_record.`type` IN (1,2) AND manage_staff_card.`studio_id`=manage_course_record.`studio_id`
          ORDER BY manage_course_record.create_time DESC

2.查看执行计划:


explain 查询sql

发现manage_staff、manage_user_studio中type类型均为all,all执行效率最低,所以进行添加索引.

d4c348da5a0b8330d186870f11fdba79_b90b2b98a1b4440384009b713ae66f14.png

alter  table  manage_staff  add  index  index_login (login);
alter  table  manage_user_studio  add  index  index_login_studioId  (login,studio_id);

添加之后发现查询时间并没有提高多少.

测试发现执行sql时,添加排序操作与不添加排序操作执行时间相差很大.不添加倒序查询时用时:0.026秒.


SELECT 
  manage_course_record.id course_record_id,manage_staff_card.`card_no`,manage_staff.`real_name` staff_name,manage_staff.`mobile`,
  DATE_FORMAT(manage_course_record.`start_time`,'%Y-%m-%d %H:%i') start_time,
        manage_course.`course_name`, manage_user_studio.`user_name` teacher_name,manage_studio.studio_name,manage_studio.id'studioId',
        manage_course_record.`status`,manage_card.`card_name`,manage_course_record.apply_count,manage_staff_card.card_type,manage_course_record.type course_type
        ,IF(NOW()>manage_course_record.start_time,TRUE,FALSE) course_start_flag
        FROM manage_course_record 
        LEFT JOIN manage_staff_card ON manage_staff_card.`card_no`=manage_course_record.`card_no`
        LEFT JOIN manage_staff ON manage_course_record.`login`=manage_staff.`login`
        LEFT JOIN manage_card ON manage_card.`id`=manage_staff_card.`card_id`
        LEFT JOIN manage_course_table ON manage_course_table.`id`=manage_course_record.`data_id` AND manage_course_table.`studio_id`=manage_course_record.`studio_id`
        LEFT JOIN manage_course ON manage_course.`id`=manage_course_table.`course_id` AND manage_course.`studio_id`=manage_course_table.`studio_id`
        LEFT JOIN manage_user_studio ON manage_user_studio.`login`=manage_course_table.`teacher_id` AND manage_user_studio.`studio_id`=manage_course_table.`studio_id`
        LEFT JOIN manage_studio ON manage_studio.`id`= manage_course_record.`studio_id`
        WHERE manage_course_record.`type` IN (1,2) AND manage_staff_card.`studio_id`=manage_course_record.`studio_id`


   发现问题应该是存在于按照创建时间排序上,对manage_course_record中的type与create_time进行添加联合索引.

ALTER  TABLE  manage_course_record  ADD  INDEX  index_type_create_time  (type,create_time);

但是执行计划中type还是显示all.

cc52af51e975582bd0f89146e059fae4_654a7252e98e413181a5d55d5a58c36e.png

   到这里的时候会有疑问,明明已经加上索引了,但是不能生效.并且排序类型是using filesort,查询资料发现这种按照文件排序的方式效率是很低的.至于添加排序索引之后为何不生效猜测是mysql进行执行查询时内部优化器认为按照创建时间查询不是最优的方式,所以不使用创建时间作为索引进行查询.

   关于排序的处理这里想到两种处理方式,一种是排序放到逻辑层中处理;另一种是对manage_course_record表强制使用索引进行查询,在manage_course_record后面添加 FORCE INDEX(index_type_create_time)

执行sql如下:

SELECT
  manage_course_record.id course_record_id,manage_staff_card.`card_no`,manage_staff.`real_name` staff_name,manage_staff.`mobile`,
  DATE_FORMAT(manage_course_record.`start_time`,'%Y-%m-%d %H:%i') start_time,
        manage_course.`course_name`, manage_user_studio.`user_name` teacher_name,manage_studio.studio_name,manage_studio.id'studioId',
   manage_course_record.`status`,manage_card.`card_name`,manage_course_record.apply_count,manage_staff_card.card_type,manage_course_record.type course_type
        ,IF(NOW()>manage_course_record.start_time,TRUE,FALSE) course_start_flag
        FROM manage_course_record FORCE INDEX(in_type_create_time)
        LEFT JOIN manage_staff_card ON manage_staff_card.`card_no`=manage_course_record.`card_no`
        LEFT JOIN manage_staff ON manage_course_record.`login`=manage_staff.`login`
        LEFT JOIN manage_card ON manage_card.`id`=manage_staff_card.`card_id`
        LEFT JOIN manage_course_table ON manage_course_table.`id`=manage_course_record.`data_id` AND manage_course_table.`studio_id`=manage_course_record.`studio_id`
        LEFT JOIN manage_course ON manage_course.`id`=manage_course_table.`course_id` AND manage_course.`studio_id`=manage_course_table.`studio_id`
        LEFT JOIN manage_user_studio ON manage_user_studio.`login`=manage_course_table.`teacher_id` AND manage_user_studio.`studio_id`=manage_course_table.`studio_id`
        LEFT JOIN manage_studio ON manage_studio.`id`= manage_course_record.`studio_id`
        WHERE manage_course_record.`type` IN (1,2) AND manage_staff_card.`studio_id`=manage_course_record.`studio_id`
          ORDER BY manage_course_record.create_time DESC

修改完成之后查询时间为0.035秒.至此,问题解决!

   以上是mysql查询时间过慢进行优化的一次记录,希望对有同样需求的同学有所帮助和借鉴!


相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
2月前
|
缓存 关系型数据库 MySQL
MySQL索引策略与查询性能调优实战
在实际应用中,需要根据具体的业务需求和查询模式,综合运用索引策略和查询性能调优方法,不断地测试和优化,以提高MySQL数据库的查询性能。
258 66
|
2月前
|
SQL 关系型数据库 MySQL
大厂面试官:聊下 MySQL 慢查询优化、索引优化?
MySQL慢查询优化、索引优化,是必知必备,大厂面试高频,本文深入详解,建议收藏。关注【mikechen的互联网架构】,10年+BAT架构经验分享。
大厂面试官:聊下 MySQL 慢查询优化、索引优化?
|
21天前
|
SQL 存储 关系型数据库
MySQL秘籍之索引与查询优化实战指南
最左前缀原则。不冗余原则。最大选择性原则。所谓前缀索引,说白了就是对文本的前几个字符建立索引(具体是几个字符在建立索引时去指定),比如以产品名称的前 10 位来建索引,这样建立起来的索引更小,查询效率更快!
88 22
 MySQL秘籍之索引与查询优化实战指南
|
1月前
|
SQL 关系型数据库 MySQL
【MySQL基础篇】多表查询(隐式/显式内连接、左/右外连接、自连接查询、联合查询、标量/列/行/表子查询)
本文详细介绍了MySQL中的多表查询,包括多表关系、隐式/显式内连接、左/右外连接、自连接查询、联合查询、标量/列/行/表子查询及其实现方式,一文全面读懂多表联查!
【MySQL基础篇】多表查询(隐式/显式内连接、左/右外连接、自连接查询、联合查询、标量/列/行/表子查询)
|
5天前
|
缓存 关系型数据库 MySQL
【深入了解MySQL】优化查询性能与数据库设计的深度总结
本文详细介绍了MySQL查询优化和数据库设计技巧,涵盖基础优化、高级技巧及性能监控。
63 0
|
1月前
|
存储 Oracle 关系型数据库
索引在手,查询无忧:MySQL索引简介
MySQL 是一款广泛使用的关系型数据库管理系统,在2024年5月的DB-Engines排名中得分1084,仅次于Oracle。本文介绍MySQL索引的工作原理和类型,包括B+Tree、Hash、Full-text索引,以及主键、唯一、普通索引等,帮助开发者优化查询性能。索引类似于图书馆的分类系统,能快速定位数据行,极大提高检索效率。
63 8
|
1月前
|
SQL 关系型数据库 MySQL
MySQL 窗口函数详解:分析性查询的强大工具
MySQL 窗口函数从 8.0 版本开始支持,提供了一种灵活的方式处理 SQL 查询中的数据。无需分组即可对行集进行分析,常用于计算排名、累计和、移动平均值等。基本语法包括 `function_name([arguments]) OVER ([PARTITION BY columns] [ORDER BY columns] [frame_clause])`,常见函数有 `ROW_NUMBER()`, `RANK()`, `DENSE_RANK()`, `SUM()`, `AVG()` 等。窗口框架定义了计算聚合值时应包含的行。适用于复杂数据操作和分析报告。
84 11
|
1月前
|
存储 关系型数据库 MySQL
mysql怎么查询longblob类型数据的大小
通过本文的介绍,希望您能深入理解如何查询MySQL中 `LONG BLOB`类型数据的大小,并结合优化技术提升查询性能,以满足实际业务需求。
142 6
|
2月前
|
SQL 关系型数据库 MySQL
MySQL慢查询优化、索引优化、以及表等优化详解
本文详细介绍了MySQL优化方案,包括索引优化、SQL慢查询优化和数据库表优化,帮助提升数据库性能。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
MySQL慢查询优化、索引优化、以及表等优化详解
|
2月前
|
SQL 前端开发 关系型数据库
SpringBoot使用mysql查询昨天、今天、过去一周、过去半年、过去一年数据
SpringBoot使用mysql查询昨天、今天、过去一周、过去半年、过去一年数据
87 9