如何让in/exists 子查询(半连接)作为驱动表？

最新推荐文章于 2022-07-09 23:10:51 发布
原创 最新推荐文章于 2022-07-09 23:10:51 发布 · 1.2w 阅读 · 10 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文介绍如何通过调整SQL语句及使用提示来改变查询中的驱动表，以优化执行计划并减少逻辑读取次数。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

一哥们问我，怎么才能让子查询作为驱动表？ SQL如下：

select  rowid rid
   from its_car_pass7 v
  where 1 = 1
    and pass_datetime >=
        to_date('2013-07-06 :17:46:04', 'yyyy-mm-dd hh24:mi:ss')
    and pass_datetime <=
        to_date('2013-07-06 :18:46:06', 'yyyy-mm-dd hh24:mi:ss')
    and v.pass_device_unid in
        (select unid
           from its_base_device
          where dev_bay_unid in ('01685EFE4658C19D59C4DDAAEDD37393')
            and dev_type = '1'
            and dev_chk_flag = '1'
            and dev_delete_flag = 'N')
  order by v.pass_datetime asc 
 /

执行计划如下：

Execution Plan
----------------------------------------------------------
Plan hash value: 3634433140

--------------------------------------------------------------------------------------------------------------------
| Id  | Operation                     | Name               | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
--------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |                    |     1 |   111 |     2  (50)| 00:00:01 |       |       |
|   1 |  SORT ORDER BY                |                    |     1 |   111 |     2  (50)| 00:00:01 |       |       |
|   2 |   NESTED LOOPS                |                    |       |       |            |          |       |       |
|   3 |    NESTED LOOPS               |                    |     1 |   111 |     1   (0)| 00:00:01 |       |       |
|   4 |     PARTITION RANGE SINGLE    |                    |     1 |    39 |     1   (0)| 00:00:01 |  1284 |  1284 |
|*  5 |      INDEX SKIP SCAN          | IDX_VT7_DEVICEID   |     1 |    39 |     1   (0)| 00:00:01 |  1284 |  1284 |
|*  6 |     INDEX UNIQUE SCAN         | PK_ITS_BASE_DEVICE |     1 |       |     0   (0)| 00:00:01 |       |       |
|*  7 |    TABLE ACCESS BY INDEX ROWID| ITS_BASE_DEVICE    |     1 |    72 |     0   (0)| 00:00:01 |       |       |
--------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   5 - access("PASS_DATETIME">=TO_DATE(' 2013-07-06 17:46:04', 'syyyy-mm-dd hh24:mi:ss') AND
              "PASS_DATETIME"<=TO_DATE(' 2013-07-06 18:46:06', 'syyyy-mm-dd hh24:mi:ss'))
       filter("PASS_DATETIME">=TO_DATE(' 2013-07-06 17:46:04', 'syyyy-mm-dd hh24:mi:ss') AND
              "PASS_DATETIME"<=TO_DATE(' 2013-07-06 18:46:06', 'syyyy-mm-dd hh24:mi:ss'))
   6 - access("V"."PASS_DEVICE_UNID"="UNID")
   7 - filter("DEV_BAY_UNID"='01685EFE4658C19D59C4DDAAEDD37393' AND "DEV_TYPE"='1' AND
              "DEV_DELETE_FLAG"='N' AND "DEV_CHK_FLAG"='1')


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
     110973  consistent gets
          0  physical reads
          0  redo size
      47861  bytes sent via SQL*Net to client
       1656  bytes received via SQL*Net from client
        105  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
       1560  rows processed

这里我们就不管统计信息是否准确了，也不管SQL优化的问题，就单单讨论哥们问的问题吧。

那哥们说，怎么才能让子查询作为驱动表呢？他自己试了很多方法就是搞不定。 那我们来亲自搞搞吧

explain plan for   select  rowid rid
   from its_car_pass7 v
  where 1 = 1
    and pass_datetime >=
        to_date('2013-07-06 :17:46:04', 'yyyy-mm-dd hh24:mi:ss')
    and pass_datetime <=
        to_date('2013-07-06 :18:46:06', 'yyyy-mm-dd hh24:mi:ss')
    and v.pass_device_unid in
        (select unid
           from its_base_device
          where dev_bay_unid in ('01685EFE4658C19D59C4DDAAEDD37393')
            and dev_type = '1'
            and dev_chk_flag = '1'
            and dev_delete_flag = 'N')
  order by v.pass_datetime asc 
 /

执行计划如下

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY(NULL, NULL, 'ADVANCED -PROJECTION'));

-----------------------------------------------------------
Plan hash value: 2191740724
---------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name               | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
---------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |                    |     1 |   111 |  2092K  (1)| 06:58:26 |       |       |
|   1 |  NESTED LOOPS                        |                    |       |       |            |          |       |       |
|   2 |   NESTED LOOPS                       |                    |     1 |   111 |  2092K  (1)| 06:58:26 |       |       |
|   3 |    PARTITION RANGE SINGLE            |                    |     1 |    39 |  2092K  (1)| 06:58:26 |  1284 |  1284 |
|   4 |     TABLE ACCESS BY LOCAL INDEX ROWID| ITS_CAR_PASS7      |     1 |    39 |  2092K  (1)| 06:58:26 |  1284 |  1284 |
|*  5 |      INDEX RANGE SCAN                | IDX_VT7_DATETIME   |     1 |       |  6029   (1)| 00:01:13 |  1284 |  1284 |
|*  6 |    INDEX UNIQUE SCAN                 | PK_ITS_BASE_DEVICE |     1 |       |     0   (0)| 00:00:01 |       |       |
|*  7 |   TABLE ACCESS BY INDEX ROWID        | ITS_BASE_DEVICE    |     1 |    72 |     0   (0)| 00:00:01 |       |       |
---------------------------------------------------------------------------------------------------------------------------
 
Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------
 
   1 - SEL$5DA710D3
   4 - SEL$5DA710D3 / V@SEL$1
   5 - SEL$5DA710D3 / V@SEL$1
   6 - SEL$5DA710D3 / ITS_BASE_DEVICE@SEL$2
   7 - SEL$5DA710D3 / ITS_BASE_DEVICE@SEL$2
 
Outline Data
-------------
 
  /*+
      BEGIN_OUTLINE_DATA
      NLJ_BATCHING(@"SEL$5DA710D3" "ITS_BASE_DEVICE"@"SEL$2")
      USE_NL(@"SEL$5DA710D3" "ITS_BASE_DEVICE"@"SEL$2")
      LEADING(@"SEL$5DA710D3" "V"@"SEL$1" "ITS_BASE_DEVICE"@"SEL$2")
      INDEX(@"SEL$5DA710D3" "ITS_BASE_DEVICE"@"SEL$2" ("ITS_BASE_DEVICE"."UNID"))
      INDEX_RS_ASC(@"SEL$5DA710D3" "V"@"SEL$1" ("ITS_CAR_PASS7"."PASS_DATETIME"))
      OUTLINE(@"SEL$2")
      OUTLINE(@"SEL$1")
      UNNEST(@"SEL$2")
      OUTLINE_LEAF(@"SEL$5DA710D3")
      FIRST_ROWS
      DB_VERSION('11.2.0.3')
      OPTIMIZER_FEATURES_ENABLE('11.2.0.3')
      IGNORE_OPTIM_EMBEDDED_HINTS
      END_OUTLINE_DATA
  */
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   5 - access("PASS_DATETIME">=TO_DATE(' 2013-07-06 17:46:04', 'syyyy-mm-dd hh24:mi:ss') AND 
              "PASS_DATETIME"<=TO_DATE(' 2013-07-06 18:46:06', 'syyyy-mm-dd hh24:mi:ss'))
   6 - access("V"."PASS_DEVICE_UNID"="UNID")
   7 - filter("DEV_BAY_UNID"='01685EFE4658C19D59C4DDAAEDD37393' AND "DEV_TYPE"='1' AND "DEV_DELETE_FLAG"='N' AND 
              "DEV_CHK_FLAG"='1')


TMD 执行计划又变了，我们也先别管执行计划为啥变了，驱动表仍然是 ITS_CAR_PASS7，现在我们来改变驱动表

select /*+ leading(ITS_BASE_DEVICE@SEL$2) */ rowid rid
   from its_car_pass7 v
  where 1 = 1
    and pass_datetime >=
        to_date('2013-07-06 :17:46:04', 'yyyy-mm-dd hh24:mi:ss')
    and pass_datetime <=
        to_date('2013-07-06 :18:46:06', 'yyyy-mm-dd hh24:mi:ss')
    and v.pass_device_unid in
        (select unid
           from its_base_device
          where dev_bay_unid in ('01685EFE4658C19D59C4DDAAEDD37393')
            and dev_type = '1'
            and dev_chk_flag = '1'
            and dev_delete_flag = 'N')
  order by v.pass_datetime asc 
 /

Execution Plan
----------------------------------------------------------
Plan hash value: 712001411

-------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                          | Name                     | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
-------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                   |                          |     1 |   111 |    25   (4)| 00:00:01 |       |       |
|   1 |  SORT ORDER BY                     |                          |     1 |   111 |    25   (4)| 00:00:01 |       |       |
|*  2 |   TABLE ACCESS BY LOCAL INDEX ROWID| ITS_CAR_PASS7            |     1 |    39 |     2   (0)| 00:00:01 |  1284 |  1284 |
|   3 |    NESTED LOOPS                    |                          |     1 |   111 |    24   (0)| 00:00:01 |       |       |
|*  4 |     TABLE ACCESS BY INDEX ROWID    | ITS_BASE_DEVICE          |     6 |   432 |    12   (0)| 00:00:01 |       |       |
|*  5 |      INDEX RANGE SCAN              | IDX_DEVICE_DEV_BAY_UNID  |     7 |       |     1   (0)| 00:00:01 |       |       |
|   6 |     PARTITION RANGE SINGLE         |                          |    44M|       |     2   (0)| 00:00:01 |  1284 |  1284 |
|*  7 |      INDEX RANGE SCAN              | IDX_VT7_PASS_DEVICE_UNID |    44M|       |     2   (0)| 00:00:01 |  1284 |  1284 |
-------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("PASS_DATETIME">=TO_DATE(' 2013-07-06 17:46:04', 'syyyy-mm-dd hh24:mi:ss') AND
              "PASS_DATETIME"<=TO_DATE(' 2013-07-06 18:46:06', 'syyyy-mm-dd hh24:mi:ss'))
   4 - filter("DEV_TYPE"='1' AND "DEV_DELETE_FLAG"='N' AND "DEV_CHK_FLAG"='1')
   5 - access("DEV_BAY_UNID"='01685EFE4658C19D59C4DDAAEDD37393')
   7 - access("V"."PASS_DEVICE_UNID"="UNID")


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
      18645  consistent gets
        130  physical reads
          0  redo size
      47861  bytes sent via SQL*Net to client
       1657  bytes received via SQL*Net from client
        105  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
       1560  rows processed


驱动表改了之后，逻辑读从11W降低为1.8W


 

分页查询、关联查询、in/exists和count优化
swadian2008的博客
04-16 1330
目录 1、分页查询优化 （1）根据自增且连续的主键排序的分页查询优化 （2）根据非主键字段排序的分页查询优化 2、关联查询优化 （1）嵌套循环连接 Nested-Loop Join(NLJ) 算法(关联字段有索引) （2）基于块的嵌套循环连接 Block Nested-Loop Join(BNL)算法(关联字段无索引) （3）对于关联 sql 的优化 3、in和exists优化 4、count(*)查询优化 1、分页查询优化 // 'employees' 建表结构同《Mysql exp
TiDB 关联子查询及半连接的优化实践
TiDB 社区干货传送门
10-14 555
作者： 数据源的TiDB学习之路 原文来源： https://tidb.net/blog/e9563a23 ...
深入解析：半连接与反连接的原理和等价改写方法
Enmotech的博客
03-26 1790
作者简介刘志永云和恩墨交付工程师，有5年的运营商及金融行业 DBA 运维工作经验，对故障处理、性能优化、迁移&升级有丰富的经验。本文由恩墨大讲堂152期线上分享整理而成。课程回看可点击文末“阅读原文”。 半连接的原理及等价改写1. 什么是半连接当两张表进行关联，只返回匹配上的数据并且只会返回一张的表的数据，半连接一般就是指的在子查询中出现 IN 和 EXISTS。执行计划最常见的有下面的两个：NE
半连接、物化、反连接
qiyan2012的博客
05-16 1022
半连接、物化、反连接 且将新火试新茶 MySQL查询优化器有多种策略可用于评估子查询： 对于IN（或=ANY）子查询，优化器具有以下选择： 半连接 物化 EXISTS 对于NOT IN（或 <>ALL）子查询，优化器具有以下选择： 物化 EXISTS semi-join半连接 我们来看一个mysql官方给出的案例： 在课程表和班级花名册（每个班级中都有学生）中分别有命名的表 class和roster列出的班级。要列出实际招收学生的课程，您可以使用以下联接： 假设有一个名为cl
MySQL 8.0 官方文档 第八章 优化（二十四）—— 用半连接转换优化IN和EXISTS子查询谓词
HZ_Samuel博客
05-19 780
@[TOC](目录) 第八章 优化（二十三）—— 用半连接变换优化IN和EXISTS子查询谓词 8.2 优化SQL语句 8.2.2 优化子查询、派生表、视图引用和公共表表达式 8.2.2.1 用半连接变换优化IN和EXISTS子查询谓词 上一集 MySQL 8.0 官方文档 第八章 优化（二十三）—— 优化子查询、派生表、视图引用和公共表表达式 ...
oracle半连接（in ,exists）
数据库
04-25 360
半连接和反连接，其实就是in，exists，之前我对这几个玩意其实也很迷茫，看网上都有的说exists比in好，等等之类的，其实并不然，等了解了他的一些内部机制，就不会再这么盲目了。 那么我先看几个相关参数： _always_semi_join=CHOOSE 这个说明是按最小成本选择半连接 这个参数可以通过select NAME_KSPVLD_VALUES name, VALUE_KSPV...
DB（五）：关联查询、子查询、关联子查询、分页查询
qq_45138120的博客
07-09 5311
包括关联查询内链接、外链接、自查询；子查询在SELECT、WHERE、FROM语句中使用，子查询的执行过程及注意事项；关联子查询EXISTS、NOT EXISTS的执行过程，IN和EXISTS的区别；分页查询。
MySQL 高级查询（内连接、外连接、自然连接、子查询）
weixin_44387652的博客
03-01 747
MySQL 高级查询1、关联查询,连接查询,内连接1.1、where 子句1.2、inner join…on…1.3、inner join…using…2、自然连接3、外连接3.1、左外连接:left [outer] join…on…3.2、右外连接:right [outer] join…on…4、子查询5、集合查询 Test Table emp and dept: 链接：https://pan.baidu.com/s/12p039KI59UDAJ9llXAIk7Q 提取码：58ry dept table：
sql 中in、exists在驱动表选择上的执行效率测试分析
mysql-龙召的专栏
01-22 1527
都说exits快，怎么快？哪快？为啥快？ 1 环境准备 环境为oracle 12c db 1.只查询需要的列，不用* 2.IN适合于外表大而内表小的情况；EXISTS适合于外表小而内表大的情况  create table a as select * from all_objects; insert into a select * from a; / / / commit;
SQL优化经典案例----让in/exists子查询作为驱动表
mengxiangfeiyang的专栏
05-20 1409
SQL优化经典案例----让in/exists子查询作为驱动表   ---http://blog.sina.com.cn/s/blog_61cd89f60102efam.html     在NL连接方式中，用小表或小的结果集作业驱动表，是提高SQL执行效率的重要因素之一，下面我们看一下让in/exists子查询作为驱动表优化的案例 select  rowid rid   
查询优化
weixin_43719015的博客
03-19 455
1.单表使用索引常见的索引失效 2.关联查询优化 3.子查询优化 1.单表使用索引常见的索引失效 1. 全值匹配我最爱 1.1 有以下 SQL EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.age=30 EXPLAIN SELECT SQL_NO_CACHE * FROM emp WHERE emp.age=30 and deptid=4 E...
exist 和 in 的区别，以及小表驱动大表的原理
piano_diano的博客
03-18 2910
【exist 和 in 的区别】 原作者： https://www.cnblogs.com/liyasong 表展示 首先，查询中涉及到的两个表，一个user和一个order表，具体表的内容如下： in 的使用 确定给定的值是否与子查询或列表中的值相匹配。in在查询的时候，首先查询子查询的表，然后将内表和外表做一个笛卡尔积，然后按照条件进行筛选。所以相对内表比较小的时候，in的速度较快。 具体sql语句如下： SELECT * FROM `user` WHERE `user`
mysql in 优化 大量_MySQL优化 — exists与in谁快谁慢？
weixin_42172204的博客
01-22 1296
相信很多开发人员或DBA经常为exists与in到底谁效率比较高而感到困扰。而exists和in是半连接(SEMI JOIN)，什么是半连接？半连接就是两张表进行关联只返回一个表的数据。所以半连接也属于表连接，既然是表连接，我们就需要关心两表的大小以及两表之间究竟走什么连接方式，从而有目的地去控制两表之间的连接方式，才能随心所欲地优化SQL。in/exists语句分析-...
子查询里面有树形查询，子查询选择使用in/exists需要特别留意
落落的专栏 专注SQL调优 性能调优
12-06 8822
今天下午盖尔又发来一条坑爹的SQL，哎，最近被盖尔给咕噜惨了，老是发一些鸟SQL让我调，最近都帮忙调了N多个SQL了，还好盖尔良心发现了，说这个月末给我重200元的话费。认识盖尔的人都知道，盖尔发的SQL那绝对是坑爹的，说它是OLTP的SQL不像，因为OLTP的SQL没那么复杂，说它是OLAP的也不像，因为我没看见典型的事实表，维度表的JOIN，那么唯一的解释就是他们DB设计的人是SB。  盖尔
oracle where in效率,Oracle 提高查询性能（基础）
weixin_29988441的博客
04-03 2013
#1，选择最有效的表名顺序Oracle解析器总是按照从右至左的顺序处理FROM后面的表，因此FROM最右边的表将会被当做驱动表优先处理，当存在多个表关联时，应当使用记录少的表当做驱动表。如果关联的表多的话，则用交叉表作为驱动表。#2，select中避免使用'*'.#3, 减少数据库访问的次数每当执行一条SQL语句,Oracle需要完成大量的内部操作,象解析SQL语句,估算索引的利用率,绑定变量...
查询SQL连接多个表，如何降低查询时间？
最新发布
07-12
<think>嗯，用户想优化多表SQL查询的性能，特别是多表连接的速度问题。让我仔细分析一下这个需求。 用户可能正在处理一个包含多个表关联的复杂查询，执行速度不够理想。从ta的提问方式来看，应该有一定SQL基础但需要更专业的优化建议。这类问题在实际工作中很常见，尤其是数据分析或报表生成场景。 我注意到几个关键点需要重点解决：首先是表连接方式的选择，不同连接类型对性能影响很大；其次是索引策略，这往往是优化的核心；还有执行计划的分析方法，这是诊断问题的关键工具。另外用户虽然没有明确说，但可能还关心如何避免常见的性能陷阱。 让我回忆下SQL优化的核心原则。根据引用[3]提到的驱动表概念，应该优先筛选数据量小的表作为驱动表。引用[1]强调要避免标量子查询，这点很重要但用户没直接问到，可以补充说明。引用[2]则指出数据库对多表连接的高速缓存机制有限，需要特别优化。 具体优化方案需要分层次：最基础的是确保索引正确，特别是连接字段和筛选条件字段必须索引；然后是改写查询逻辑，比如用EXISTS代替IN，避免在WHERE子句进行函数计算；高级技巧包括使用临时表分解复杂查询、调整数据库参数等。 用户可能还会遇到执行计划难以解读的问题，所以需要解释如何查看执行顺序和开销分布。另外要提醒避免过度优化，有时候简单的查询重组就能带来显著提升。 最后要给出可操作的步骤建议：先分析执行计划定位瓶颈，再检查索引，最后考虑查询重构。这样用户能循序渐进地解决问题。虽然用户没问，但可以补充说明在OLAP场景下物化视图等更高级的优化手段。</think>以下是SQL多表连接查询的性能优化方法，结合关键策略和实操建议： --- ### **一、核心优化策略** 1. **索引优化** - **连接字段必建索引**：确保 `ON` 子句中的关联列（如 `a.id = b.user_id`）在**所有被驱动表**上都有索引[^3] - **筛选字段索引**：对 `WHERE` 中的高频过滤条件（如 `status=1`, `create_time > '2023-01-01'`）建立索引 - **避免无效索引**：区分度低的字段（如性别）无需索引，长文本用前缀索引 2. **优化表连接顺序** - **小表驱动大表**：将数据量小的表作为驱动表（外层循环），减少内层表扫描次数 ```sql -- 优化前：大表user驱动小表order SELECT * FROM user u JOIN order o ON u.id = o.user_id; -- 优化后：小表order驱动大表user SELECT * FROM order o JOIN user u ON o.user_id = u.id; -- 假设order表更小 ``` - **减少中间结果集**：优先连接筛选后数据量最小的表 3. **避免全表扫描** - 禁止对索引列使用函数：`WHERE YEAR(create_time)=2023` → 改用范围查询 - 慎用 `OR`：`WHERE status=1 OR type=2` 可改写为 `UNION ALL` - 禁止隐式类型转换：`user_id='100'`（字符串vs整型）会导致索引失效 --- ### **二、高级优化技巧** 1. **替代低效写法** - **用 `JOIN` 代替子查询**：尤其避免在 `SELECT` 中使用标量子查询[^1] ```sql -- 低效：标量子查询（每行执行一次） SELECT name, (SELECT dept_name FROM dept d WHERE d.id = u.dept_id) FROM user u; -- 高效：JOIN连接 SELECT u.name, d.dept_name FROM user u LEFT JOIN dept d ON u.dept_id = d.id; ``` - **用 `EXISTS` 代替 `IN`**：当子查询结果集大时更高效 2. **分阶段执行** 复杂查询拆分为多个临时表，减少单次计算量： ```sql CREATE TEMPORARY TABLE tmp_orders SELECT user_id, SUM(amount) total FROM orders WHERE status='paid' GROUP BY user_id; -- 先聚合订单数据 SELECT u.name, tmp.total FROM users u JOIN tmp_orders tmp ON u.id = tmp.user_id; ``` 3. **调整数据库配置** - 增大连接缓冲区（如MySQL的 `join_buffer_size`）[^2] - 定期更新统计信息：`ANALYZE TABLE table_name` --- ### **三、诊断性能瓶颈** 1. **查看执行计划** - MySQL: `EXPLAIN FORMAT=JSON SELECT ...` - 关键指标： - `type` 列：避免 `ALL`（全表扫描），争取 `ref`/`range` - `rows` 列：估算扫描行数，值越小越好 - `Extra` 列：避免 `Using filesort`、`Using temporary` 2. **监控慢查询日志** 启用配置项： ```ini slow_query_log = ON long_query_time = 2 # 记录超过2秒的查询 ``` --- ### **典型优化案例** **问题场景**：用户表（100万行）连接订单表（1000万行），查询超时 **优化步骤**： 1. 确认索引：订单表的 `user_id` 必须有索引 2. 改写查询： ```sql -- 原查询（无索引扫描） SELECT * FROM users u JOIN orders o ON u.id = o.user_id WHERE u.reg_time > '2023-01-01'; -- 优化后：先过滤用户，再用索引关联订单 SELECT * FROM (SELECT id FROM users WHERE reg_time > '2023-01-01') u_filtered JOIN orders o ON u_filtered.id = o.user_id; -- 订单表通过user_id索引快速定位 ``` 3. 执行时间：从 12秒 → 0.3秒 --- ### **
评论 19
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值