10个案例告诉你mysql不使用子查询的原因

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介: 大家好,我是V哥。上周与朋友讨论数据库子查询问题,深受启发。为此,我整理了10个案例,详细说明如何通过优化子查询提升MySQL性能。主要问题包括性能瓶颈、索引失效、查询优化器复杂度及数据传输开销等。解决方案涵盖使用EXISTS、JOIN、IN操作符、窗口函数、临时表及索引优化等。希望通过这些案例,帮助大家在实际开发中选择更高效的查询方式,提升系统性能。关注V哥,一起探讨技术,欢迎点赞支持!

大家好,我是 V 哥,上周跟一个哥们吃饭,技术人在一起,你知道的,没聊上一会儿,就转到技术问题探讨上了,其中聊到数据库子查询的问题印象深刻,回来整理了以下10个案例说明不使用子查询的问题,分享给大家。

首先,来说一下在MySQL中,不推荐使用子查询和JOIN的原因,主要有以下几点:

  1. 性能问题:子查询在执行时,MySQL需要创建临时表来存储内层查询的结果,查询完毕后再删除这些临时表,这会增加CPU和IO资源的消耗,产生慢查询。JOIN操作本身效率也是硬伤,特别是当数据量很大时,性能难以保证。

  2. 索引失效:子查询可能导致索引失效,因为MySQL会将查询强行转换为联接来执行,这使得子查询不能首先被执行,如果外表很大,性能上会出问题。

  3. 查询优化器的复杂度:子查询会影响查询优化器的判断,导致不够优化的执行计划。相比之下,联表查询更容易被优化器理解和处理。

  4. 数据传输开销:子查询可能导致大量不必要的数据传输,因为每个子查询都需要将结果返回给主查询,而联表查询则可以通过一次查询返回所需的所有数据,减少数据传输的开销。

  5. 维护成本:使用JOIN写的SQL语句在修改表的schema时比较复杂,成本较大,尤其是在系统较大时,不易维护。

针对这些原因,可以采取以下解决方案:

  1. 应用层关联:在业务层单表查询出数据后,作为条件给下一个单表查询,减少数据库层的负担。

  2. 使用IN代替子查询:如果子查询结果集比较小,可以考虑使用“IN”操作符进行查询,这在数据量较小的情况下,查询效率更高。

  3. 使用WHERE EXISTS:WHERE EXISTS是一种比“IN”更好的方案,它会检查子查询是否返回结果集,查询速度能够明显提高。

  4. 改写为JOIN:使用JOIN查询来替代子查询,不需要建立临时表,速度更快,如果查询中使用索引,性能会更好。

接下来,V 哥通过10个案例来直观的介绍一下。

案例1:查询所有有库存的商品信息。

  • 原始查询(使用子查询):查询字段太多,就用*号替代了哈,不用在意,实际项目中肯定是不这样使用的。
  SELECT * FROM products WHERE id IN (SELECT product_id FROM inventory WHERE stock > 0);

这个查询会导致查询速度慢,影响用户体验。

  • 优化方案(使用EXISTS):
    SELECT * FROM products WHERE EXISTS (SELECT 1 FROM inventory WHERE inventory.product_id = products.id AND inventory.stock > 0);
    
    这个优化方案可以大幅提升查询速度,改善用户体验。

案例2:使用EXISTS优化子查询

原始查询

SELECT * FROM orders WHERE customer_id IN (SELECT customer_id FROM customers WHERE country = 'USA');

优化方案

SELECT * FROM orders WHERE EXISTS (SELECT 1 FROM customers WHERE orders.customer_id = customers.customer_id AND customers.country = 'USA');

使用EXISTS代替IN子查询可以减少回表查询的次数,提高查询效率。

案例3:使用JOIN代替子查询

原始查询

SELECT * FROM orders WHERE customer_id IN (SELECT customer_id FROM customers WHERE country = 'USA');

优化方案

SELECT o.* FROM orders o JOIN customers c ON o.customer_id = c.customer_id WHERE c.country = 'USA';

使用JOIN代替子查询可以减少子查询的开销,并且更容易利用索引。

案例4:优化子查询以减少数据量

原始查询

SELECT * FROM orders WHERE customer_id IN (SELECT customer_id FROM customers);

优化方案

SELECT * FROM orders WHERE customer_id IN (SELECT customer_id FROM customers WHERE active = 1);

限制子查询返回的数据量,减少主查询需要检查的行数,提高查询效率。

案例5:使用索引覆盖

原始查询

SELECT customer_id FROM customers WHERE country = 'USA';

优化方案

CREATE INDEX idx_country ON customers(country);
SELECT customer_id FROM customers WHERE country = 'USA';

country字段创建索引,使得子查询可以直接在索引中找到数据,避免回表查询。

案例6:使用临时表优化复杂查询

原始查询

SELECT * FROM orders WHERE customer_id IN (SELECT customer_id FROM customers WHERE last_order_date > '2023-01-01');

优化方案

CREATE TEMPORARY TABLE temp_customers AS SELECT customer_id FROM customers WHERE last_order_date > '2023-01-01';
SELECT * FROM orders WHERE customer_id IN (SELECT customer_id FROM temp_customers);

对于复杂的子查询,使用临时表存储中间结果,简化查询并提高性能。

案例7:使用窗口函数替代子查询

原始查询

SELECT employee_id, salary, (SELECT AVG(salary) FROM employees WHERE department_id = e.department_id) AS avg_salary FROM employees e;

优化方案

SELECT employee_id, salary, AVG(salary) OVER (PARTITION BY department_id) AS avg_salary FROM employees;

使用窗口函数替代子查询,提高查询效率。

案例8:优化子查询以避免全表扫描

原始查询

SELECT * FROM users WHERE username IN (SELECT username FROM orders WHERE order_date = '2024-01-01');

优化方案

CREATE INDEX idx_order_date ON orders(order_date);
SELECT * FROM users WHERE username IN (SELECT username FROM orders WHERE order_date = '2024-01-01');

order_date字段创建索引,避免全表扫描,提高子查询效率。

案例9:使用LIMIT子句限制子查询返回数据量

原始查询

SELECT * FROM orders WHERE customer_id IN (SELECT customer_id FROM customers WHERE country = 'USA');

优化方案

SELECT * FROM orders WHERE customer_id IN (SELECT customer_id FROM customers WHERE country = 'USA' LIMIT 100);

使用LIMIT子句限制子查询返回的数据量,减少主查询需要处理的数据量,提高查询效率。

案例10:使用JOIN代替子查询以利用索引

原始查询

SELECT * FROM transactions WHERE product_id IN (SELECT product_id FROM products WHERE category = 'Equity');

优化方案

SELECT t.* FROM transactions t JOIN products p ON t.product_id = p.product_id WHERE p.category = 'Equity';

使用JOIN代替子查询,并且可以更容易地利用products表上的category索引。

这些案例展示了如何通过不同的优化策略来提升MySQL查询性能,特别是在处理子查询时。

最后

通过上述分析和案例,我们可以看到,在实际业务场景中,替代子查询和JOIN的高效编程方法能够在不同场景下显著提升MySQL数据库的查询性能。在实际应用中,应根据具体业务需求和数据特点,灵活选择合适的优化方案。关注威哥爱编程,痴迷技术咱是认真滴。官人,都看到这了,高低点个赞再走呗,V 哥感谢你的支持。

相关文章
|
4天前
|
调度 云计算 芯片
云超算技术跃进,阿里云牵头制定我国首个云超算国家标准
近日,由阿里云联合中国电子技术标准化研究院主导制定的首个云超算国家标准已完成报批,不久后将正式批准发布。标准规定了云超算服务涉及的云计算基础资源、资源管理、运行和调度等方面的技术要求,为云超算服务产品的设计、实现、应用和选型提供指导,为云超算在HPC应用和用户的大范围采用奠定了基础。
179562 18
|
12天前
|
存储 运维 安全
云上金融量化策略回测方案与最佳实践
2024年11月29日,阿里云在上海举办金融量化策略回测Workshop,汇聚多位行业专家,围绕量化投资的最佳实践、数据隐私安全、量化策略回测方案等议题进行深入探讨。活动特别设计了动手实践环节,帮助参会者亲身体验阿里云产品功能,涵盖EHPC量化回测和Argo Workflows量化回测两大主题,旨在提升量化投研效率与安全性。
云上金融量化策略回测方案与最佳实践
|
13天前
|
人工智能 自然语言处理 前端开发
从0开始打造一款APP:前端+搭建本机服务,定制暖冬卫衣先到先得
通义灵码携手科技博主@玺哥超carry 打造全网第一个完整的、面向普通人的自然语言编程教程。完全使用 AI,再配合简单易懂的方法,只要你会打字,就能真正做出一个完整的应用。
9161 23
|
17天前
|
Cloud Native Apache 流计算
资料合集|Flink Forward Asia 2024 上海站
Apache Flink 年度技术盛会聚焦“回顾过去,展望未来”,涵盖流式湖仓、流批一体、Data+AI 等八大核心议题,近百家厂商参与,深入探讨前沿技术发展。小松鼠为大家整理了 FFA 2024 演讲 PPT ,可在线阅读和下载。
4847 12
资料合集|Flink Forward Asia 2024 上海站
|
17天前
|
自然语言处理 数据可视化 API
Qwen系列模型+GraphRAG/LightRAG/Kotaemon从0开始构建中医方剂大模型知识图谱问答
本文详细记录了作者在短时间内尝试构建中医药知识图谱的过程,涵盖了GraphRAG、LightRAG和Kotaemon三种图RAG架构的对比与应用。通过实际操作,作者不仅展示了如何利用这些工具构建知识图谱,还指出了每种工具的优势和局限性。尽管初步构建的知识图谱在数据处理、实体识别和关系抽取等方面存在不足,但为后续的优化和改进提供了宝贵的经验和方向。此外,文章强调了知识图谱构建不仅仅是技术问题,还需要深入整合领域知识和满足用户需求,体现了跨学科合作的重要性。
|
25天前
|
人工智能 自动驾驶 大数据
预告 | 阿里云邀您参加2024中国生成式AI大会上海站,马上报名
大会以“智能跃进 创造无限”为主题,设置主会场峰会、分会场研讨会及展览区,聚焦大模型、AI Infra等热点议题。阿里云智算集群产品解决方案负责人丛培岩将出席并发表《高性能智算集群设计思考与实践》主题演讲。观众报名现已开放。
|
13天前
|
人工智能 容器
三句话开发一个刮刮乐小游戏!暖ta一整个冬天!
本文介绍了如何利用千问开发一款情侣刮刮乐小游戏,通过三步简单指令实现从单个功能到整体框架,再到多端优化的过程,旨在为生活增添乐趣,促进情感交流。在线体验地址已提供,鼓励读者动手尝试,探索编程与AI结合的无限可能。
三句话开发一个刮刮乐小游戏!暖ta一整个冬天!
|
13天前
|
消息中间件 人工智能 运维
12月更文特别场——寻找用云高手,分享云&AI实践
我们寻找你,用云高手,欢迎分享你的真知灼见!
993 67