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

本文涉及的产品
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
简介: 项目中的课程预约记录查询功能,线下门店反馈说进入到页面需要等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查询时间过慢进行优化的一次记录,希望对有同样需求的同学有所帮助和借鉴!


相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
相关文章
|
2天前
|
关系型数据库 MySQL 中间件
【MySQL实战笔记】07 | 行锁功过:怎么减少行锁对性能的影响?-02 死锁和死锁检测
【4月更文挑战第19天】在高并发环境下,死锁发生在多个线程间循环等待资源时,导致无限期等待。MySQL中,死锁可通过`innodb_lock_wait_timeout`参数设置超时或`innodb_deadlock_detect`开启死锁检测来解决。默认的50s超时可能不适用于在线服务,而频繁检测会消耗大量CPU。应对热点行更新引发的性能问题,可以暂时关闭死锁检测(风险是产生大量超时),控制并发度,或通过分散记录减少锁冲突,例如将数据分拆到多行以降低死锁概率。
18 1
|
5天前
|
SQL 关系型数据库 MySQL
Python与MySQL数据库交互:面试实战
【4月更文挑战第16天】本文介绍了Python与MySQL交互的面试重点,包括使用`mysql-connector-python`或`pymysql`连接数据库、执行SQL查询、异常处理、防止SQL注入、事务管理和ORM框架。易错点包括忘记关闭连接、忽视异常处理、硬编码SQL、忽略事务及过度依赖低效查询。通过理解这些问题和提供策略,可提升面试表现。
25 6
|
5天前
|
SQL 关系型数据库 MySQL
mysql 数据库查询 查询字段用逗号隔开 关联另一个表并显示
mysql 数据库查询 查询字段用逗号隔开 关联另一个表并显示
17 2
|
7天前
|
关系型数据库 MySQL Shell
MySQL 查询
MySQL 查询
|
9天前
|
SQL 关系型数据库 MySQL
DQL语言之基础查询(mysql)
DQL语言之基础查询(mysql)
|
9天前
|
SQL 关系型数据库 MySQL
DQL语言之连接查询(mysql)
DQL语言之连接查询(mysql)
|
9天前
|
关系型数据库 MySQL
MySQL全局库表查询准确定位字段
information_schema.COLUMNS 详细信息查询
199 4
|
12天前
|
存储 关系型数据库 MySQL
【MySQL实战笔记】 04 | 深入浅出索引(上)-02
【4月更文挑战第9天】InnoDB数据库使用B+树作为索引模型,其中主键索引的叶子节点存储完整行数据,非主键索引则存储主键值。主键查询只需搜索一棵树,而非主键查询需两次搜索,因此推荐使用主键查询以提高效率。在插入新值时,B+树需要维护有序性,可能导致数据页分裂影响性能。自增主键在插入时可避免数据挪动和页分裂,且占用存储空间小,通常更为理想。然而,如果场景仅需唯一索引,可直接设为主键以减少查询步骤。
13 1
【MySQL实战笔记】 04 | 深入浅出索引(上)-02
|
14天前
|
存储 SQL 关系型数据库
【MySQL实战笔记】03.事务隔离:为什么你改了我还看不见?-02
【4月更文挑战第7天】数据库通过视图实现事务隔离,不同隔离级别如读未提交、读已提交、可重复读和串行化采用不同策略。以可重复读为例,MySQL使用多版本并发控制(MVCC),每个事务有其独立的视图。回滚日志在无更早视图时被删除。长事务可能导致大量存储占用,应避免。事务启动可显式用`begin`或设置`autocommit=0`,但后者可能意外开启长事务。建议使用`autocommit=1`并显式管理事务,若需减少交互,可使用`commit work and chain`。
29 5
|
14天前
|
关系型数据库 MySQL
Mysql查询语句的执行顺序
Mysql查询语句的执行顺序
11 0