hash join、merge join、nested loop的原理演示及性能对比

最新推荐文章于 2022-08-11 00:34:28 发布
最新推荐文章于 2022-08-11 00:34:28 发布
阅读量919 收藏
点赞数
分类专栏： oracle性能调优

一、适合hash join的情况

1） SQL演示:

SQL> create table tb as select * from dba_objects;

表已创建。//创建大表

SQL> create table ts as select * from dba_objects where rownum<100;

表已创建。//创建小表

SQL> select tb.* from tb,ts where tb.object_id=ts.object_id;

已选择99行。

执行计划

----------------------------------------------------------                                                              

Plan hash value: 2843080966                                                                                             

                                                                                                                        

---------------------------------------------------------------------------                                             

| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |                                             

---------------------------------------------------------------------------                                             

|   0 | SELECT STATEMENT   |      |    99 | 18810 |   175   (4)| 00:00:03 |                                             

|*  1 | HASH JOIN         |      |    99 | 18810 |   175   (4)| 00:00:03 |                                             

|   2 |   TABLE ACCESS FULL| TS   |    99 |  1287 |    3   (0)| 00:00:01 |                                             

|   3 |   TABLE ACCESS FULL| TB   | 51783 |  8950K|   171   (3)| 00:00:03 |                                          

---------------------------------------------------------------------------   

// 分别对大表和小表进行全表扫描，在内存中构造两个hash结构,代价分别为171（大表）和3（小表 ）。构造了hash结构后，后面关联的时候 代价就非常小了，每次匹配都可以直接根据键值寻址访问判定，代价增加约为1，最后总的代价是：171+3+1=175.

                                                                                                                              

Predicate Information (identified by operation id):                                                                     

---------------------------------------------------                                                                     

                                                                                                                        

   1 - access("TB"."OBJECT_ID"="TS"."OBJECT_ID")                                                                        

                                                                                                                        

Note                                                                                                                    

-----                                                                                                                  

   - dynamic sampling used for this statement                                                                           

统计信息

----------------------------------------------------------                                                              

          0  recursive calls                                                                                            

          0  db block gets                                                                                             

        746  consistent gets / /一致性读比较低                                                                                            

        735  physical reads                                                                                             

          0  redo size                                                                                                  

       5173  bytes sent via SQL*Net to client                                                                           

        466  bytes received via SQL*Net from client                                                                     

          8  SQL*Net roundtrips to/from client                                                                          

          0  sorts (memory)                                                                                             

          0  sorts (disk)                                                                                               

         99  rows processed

SQL> select /*+ use_nl(tb ts) */ tb.* from tb,ts where tb.object_id=ts.object_id;

已选择99行。

执行计划

----------------------------------------------------------                                                              

Plan hash value: 3711445679                                                                                             

                                                                                                                        

---------------------------------------------------------------------------                                             

| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |                                             

---------------------------------------------------------------------------                                             

|   0 | SELECT STATEMENT   |      |    99 | 18810 | 16717   (3)| 00:03:21 |                                             

|   1 |  NESTED LOOPS      |      |    99 | 18810 | 16717   (3)| 00:03:21 |                                             

|   2 |   TABLE ACCESS FULL| TS   |    99 |  1287 |     3   (0)| 00:00:01 |                                             

|*  3 |   TABLE ACCESS FULL| TB   |    1 |   177 |   169   (3)| 00:00:03 |                                             

---------------------------------------------------------------------------                                          

// 以小表作驱动表，逐行到大表中寻找是否有匹配的记录，由于两个表上都没有索引，无论是驱动表还是inner table都是走全表扫描，驱动表（小表）共有99行，故循环99次，每次循环都要对inner table（大表）进行全表扫描寻找是否有匹配的记录，每次循环内表扫描的代价为169，CBO预计每次循环内表返回一条记录；169×99=16731，在加上其他一些因素（例如CPU处理时间等）的考虑，故最后总的代价为16717（与上面计算16731在同一数量级，而且非常接近）。                                                                                                                    

Predicate Information (identified by operation id):                                                                     

---------------------------------------------------                                                                     

                                                                                                                        

   3 - filter("TB"."OBJECT_ID"="TS"."OBJECT_ID")                                                                        

                                                                                                                        

Note                                                                                                                    

-----                                                                                                                  

   - dynamic sampling used for this statement                                                                           

统计信息

----------------------------------------------------------                                                              

          0  recursive calls                                                                                            

          0  db block gets                                                                                             

      72880  consistent gets // 一致性读相当高，7万多。                                                                                          

          0  physical reads                                                                                             

          0  redo size                                                                                                  

       5173  bytes sent via SQL*Net to client                                                                           

        466  bytes received via SQL*Net from client                                                                     

          8  SQL*Net roundtrips to/from client                                                                          

          0  sorts (memory)                                                                                             

          0  sorts (disk)                                                                                               

         99  rows processed                                                                                             

                                       

2）分析说明：

&Oslash;  使用dba_objects构造分别构造大表TB（7万多行）和小表TS（99行），两个表上均无索引。

&Oslash;  执行等值查询；

&Oslash;  CBO默认走hash join，通过上面与nested loop join的执行计划对比可以看出，hash join 的执行效率确实比较高；具体原因可能是，hash join在第一次扫描两个表并构造了hash 结构之后，扫描驱动表并匹配的代价非常低，虽然在把大表构造成hash 结构时消耗了一定的代价，但这个还是值得。

&Oslash;  每次进行实验前最好先用“ALTER SYSTEM FLUSH BUFFER_CACHE;”把缓存区清空，若连续执行多次同一个SQL，会发现第二次执行计算的代价与第一执行的代价略有不同,可能跟第二次执行时不需要再进行物理读有关。

二、适合nested  loop join的
1）        SQL演示:
SQL> create table tb as select * from dba_objects;

表已创建。//创建大表

SQL> create table ts as select * from dba_objects where rownum<100;

表已创建。//创建小表

SQL> create index idx_tb on tb(object_id);

索引已创建。//在大表上创建索引
SQL> select * from tb,ts where tb.object_id=ts.object_id;

执行计划
----------------------------------------------------------                                                              
Plan hash value: 2538607451                                                                                             
                                                                                                                        
---------------------------------------------------------------------------------------                                 
| Id  | Operation                    | Name   | Rows  | Bytes | Cost (%CPU)| Time     |                                 
---------------------------------------------------------------------------------------                                 
|   0 | SELECT STATEMENT             |        |    99 | 40986 |   201   (0)| 00:00:03 |                                 
|   1 |  NESTED LOOPS                |        |       |       |            |          |                                 
|   2 |   NESTED LOOPS               |        |    99 | 40986 |   201   (0)| 00:00:03 |                                 
|   3 |    TABLE ACCESS FULL         | TS     |    99 | 20493 |     3   (0)| 00:00:01 |                                 
|*  4 |    INDEX RANGE SCAN          | IDX_TB |     1 |       |     1   (0)| 00:00:01 |                                 
|   5 |   TABLE ACCESS BY INDEX ROWID| TB     |     1 |   207 |     2   (0)| 00:00:01 |                                 
---------------------------------------------------------------------------------------                                 
  // 以小表作驱动表，逐行到大表中寻找是否有匹配的记录，大表在关联键上有索引，所以在匹配时走INDEX RANGE SCAN，每匹配一行的代价为2，（主要看TABLE ACCESS BY INDEX ROWID 的代价），故总的代价为99×2+3=198+3=201

Predicate Information (identified by operation id):                                                                     
---------------------------------------------------                                                                     
                                                                                                                     
   4 - access("TB"."OBJECT_ID"="TS"."OBJECT_ID")                                                                        
                                                                                                                        
Note                                                                                                                    
-----                                                                                                                  
   - dynamic sampling used for this statement (level=2)                                                                 

SQL> select /*+ use_hash(tb ts) */ * from tb,ts where tb.object_id=ts.object_id;

执行计划
----------------------------------------------------------                                                              
Plan hash value: 2843080966                                                                                             
                                                                                                                        
---------------------------------------------------------------------------                                             
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |                                             
---------------------------------------------------------------------------                                             
|   0 | SELECT STATEMENT   |      |    99 | 40986 |   296   (2)| 00:00:04 |                                             
|*  1 |  HASH JOIN         |      |    99 | 40986 |   296   (2)| 00:00:04 |                                             
|   2 |   TABLE ACCESS FULL| TS   |    99 | 20493 |     3   (0)| 00:00:01 |                                             
|   3 |   TABLE ACCESS FULL| TB   | 69437 |    13M|   292   (2)| 00:00:04 |                                             
---------------------------------------------------------------------------                                             
//对大表进行hash构造，消耗代价292，292+3=295；再综合其他因素例如cpu计算时间等，最终的代价为296，这个SQL进行hash join的代价比nested loop的代价（201）高
                                                                                                                        
Predicate Information (identified by operation id):                                                                     
---------------------------------------------------                                                                     
                                                                                                                        
   1 - access("TB"."OBJECT_ID"="TS"."OBJECT_ID")                                                                        
                                                                                                                        
Note                                                                                                                    
-----                                                                                                                  
   - dynamic sampling used for this statement (level=2)                                                                 
2）分析说明：
        使用dba_objects构造分别构造大表TB（7万多行）和小表TS（99行），并在大表上建立索引。
        在大表的索引键上执行等值查询；
        CBO默认走nested loop join，通过上面与hash join的执行计划对比可以看出，nested loop join 的执行效率确实比较高一些；具体原因可能是，内表在索引键上建立了索引，nested loop join的每次循环中，扫描内表时可以走索引，大大的降低了每次循环匹配的消耗，即使嵌套循环了，总体代价还是比在内存中构造大表的hash结构的代价更低一些
        这个实验在10g上并不能测试成功，在10g上同样的sql默认走的是hash join。在10g中NL的适用场景又是什么呢？
（下面是11g中的应用场景
       关联中一个表比较小
       被关联表的关联字段上没有索引
       索引的键值的重复率不应该很高）         

三、适合merge join的？？

1）        SQL演示:
SQL> create table t1 as select * from dba_objects;

表已创建。

SQL> create table t2 as select * from dba_objects;

表已创建。
SQL> select a.* from (select * from t1 where object_id<100 order by object_id)a,(select * from t2 where object_id<100 order by object_id)b where a.object_id>50;
已选择4802行。

执行计划
----------------------------------------------------------                                                              
Plan hash value: 3344246350                                                                                             
                                                                                                                        
------------------------------------------------------------------------------                                          
| Id  | Operation             | Name | Rows  | Bytes | Cost (%CPU)| Time     |                                          
------------------------------------------------------------------------------                                          
|   0 | SELECT STATEMENT      |      |   140 | 30800 |  3765   (1)| 00:00:46 |                                          
|   1 |  SORT ORDER BY        |      |   140 | 30800 |  3765   (1)| 00:00:46 |                                          
|   2 |   MERGE JOIN CARTESIAN|    |   140 | 30800 |  3764   (1)| 00:00:46 |                                         
|   3 |    VIEW               |      |    12 |  2484 |   292   (2)| 00:00:04 |                                          
|   4 |     SORT ORDER BY     |      |    12 |  2484 |   292   (2)| 00:00:04 |                                          
|*  5 |      TABLE ACCESS FULL| T1   |    12 |  2484 |   291   (1)| 00:00:04 |                                          
|   6 |    BUFFER SORT        |      |    12 |   156 |  3765   (1)| 00:00:46 |                                          
|*  7 |     TABLE ACCESS FULL | T2   |    12 |   156 |   289   (1)| 00:00:04 |                                          
//CBO默认走Merge join ，两个表均预先排序，排序时走全表扫描，代价均接近300，排序的代价比较大（3765），但排序后连接的代价增加得很小（最终返回的Cost也是3765）
其实不是能看懂这个执行计划的cost是如何累加的，希望老师能找个时间讲解一下。^_^
------------------------------------------------------------------------------                                          
                                                                                                                        
Predicate Information (identified by operation id):                                                                     
---------------------------------------------------                                                                     
                                                                                                                        
   5 - filter("OBJECT_ID"<100 AND "T1"."OBJECT_ID">50)                                                                  
   7 - filter("OBJECT_ID"<100)                                                                                          
                                                                                                                        
Note                                                                                                                    
-----                                                                                                                  
   - dynamic sampling used for this statement (level=2)                                                                 


统计信息
----------------------------------------------------------                                                              
        372  recursive calls                                                                                            
          0  db block gets                                                                                             
       2252  consistent gets                                                                                            
       2070  physical reads //一致性读和物理读的次数均为2000多。                                                                                             
          0  redo size                                                                                                  
     194177  bytes sent via SQL*Net to client                                                                           
       4039  bytes received via SQL*Net from client                                                                     
        322  SQL*Net roundtrips to/from client                                                                          
          3  sorts (memory)                                                                                             
          0  sorts (disk)                                                                                               
       4802  rows processed                                                                                             

SQL> select /*+ use_nl(a b) */ a.* from (select * from t1 where object_id<100 order by object_id)a,(select * from t2 where object_id<100 order by object_id)b where a.object_id>50;

已选择4802行。


执行计划
----------------------------------------------------------                                                              
Plan hash value: 1185711386                                                                                             
                                                                                                                        
------------------------------------------------------------------------------                                          
| Id  | Operation             | Name | Rows  | Bytes | Cost (%CPU)| Time     |                                          
------------------------------------------------------------------------------                                          
|   0 | SELECT STATEMENT      |      |   140 | 30800 |  3765   (1)| 00:00:46 |                                          
|   1 |  SORT ORDER BY        |      |   140 | 30800 |  3765   (1)| 00:00:46 |                                          
|   2 |   NESTED LOOPS       |      |   140 | 30800 |  3764   (1)| 00:00:46 |                                          
|   3 |    VIEW               |      |    12 |  2484 |   292   (2)| 00:00:04 |                                          
|   4 |     SORT ORDER BY     |      |    12 |  2484 |   292   (2)| 00:00:04 |                                          
|*  5 |      TABLE ACCESS FULL| T1   |    12 |  2484 |   291   (1)| 00:00:04 |                                          
|*  6 |    TABLE ACCESS FULL  | T2   |    12 |   156 |   289   (1)| 00:00:04 |                                          
//使用hints强制走nested loop join,同样是先全表扫描，全表扫的代价跟上面的差不多；这里应该是T1做驱动表，T1预计返回12行，循环12次，计算所得的代价约为 12×289+291=3468+291=3759，再加上其他因素影响，最终计算的cost为3765,跟上面的推算相当接近了。

------------------------------------------------------------------------------                                          
                                                                                                                        
Predicate Information (identified by operation id):                                                                     
---------------------------------------------------                                                                     
                                                                                                                        
   5 - filter("OBJECT_ID"<100 AND "T1"."OBJECT_ID">50)                                                                  
   6 - filter("OBJECT_ID"<100)                                                                                          
                                                                                                                        
Note                                                                                                                    
-----                                                                                                                  
   - dynamic sampling used for this statement (level=2)                                                                 


统计信息
----------------------------------------------------------                                                              
          7  recursive calls                                                                                            
          0  db block gets                                                                                             
      52136  consistent gets //一致性读为5万多，比merge join的数量级高很多                                                                                            
          0  physical reads                                                                                             
          0  redo size                                                                                                  
     194177  bytes sent via SQL*Net to client                                                                           
       4039  bytes received via SQL*Net from client                                                                     
        322  SQL*Net roundtrips to/from client                                                                          
          2  sorts (memory)                                                                                             
          0  sorts (disk)                                                                                               
       4802  rows processed  

2）        疑问:
尝试构造过一些SQL，也跟群里的同学讨论过，似乎很多人的实验结果都是，merge join 跟 nested loop join 的Cost和Time都差不多，但统计信息里的一致性读，merge join更低一些，不知道这样是否已经显示merge join的效率更高了，希望老师有机会的时候能讲解一下。
（我尝试过对同样的sql 使用hash join的hints，但没有生效，未知是否因为两个表的大小几乎一样？）

花露丝雨
关注
专栏目录
Nested Loops Join、Hash join、Merge Sort Join三大经典表连接浅谈（笔记）
sd285757的专栏
03-20 597
今天上完梁老师的课，感觉表连接的意义非常深刻，知识消化可以转化成Sql优化方面的强力武器！ 必须认真记下来！ 一、SQL写法上的限制（CBO选择执行计划时的限制） Nested Loops Jion：无限制 Hash Join：作为经典的等值算法，不支持非等值条件（like、>、） Merge Sort Join：支持>、 二、各自特性 表访问次数： Nested Loops
Nested loops、Hash join、Sort merge join（三种连接类型原理、使用要点）
weixin_33671935的博客
11-12 428
nested loop 嵌套循环（原理）： oracle从较小结果集（驱动表、也可以被称为outer）中读取一行，然后和较大结果集（被侦查表，也可以叫做inner）中的所有数据逐条进行比较（也是等值连接，也可以是非等值连接），如果符合规则，就放在结果集中，然后取驱动表的下一条数据继续循环，直到结束。 简单的理解就是：从A表抽一条记录，遍历B表查找匹配记录...
排序合并连接(sort merge join)的原理
weixin_33920401的博客
11-01 695
这三类表连接方式是oracle最基本的连接方式： 嵌套循环连接(nested loops join)原理   哈希连接(hash join) 原理    排序合并连接(sort merge join)     访问次数：两张表都只会访问0次或1次。     驱动表是否有顺序：无。     是否要排序：是。     应用场景：当结果集已经排过序。 排序合并连接原理：如果A表的数据...
嵌套循环连接(nested loops join)原理
关注系统性能调优
10-31 3870
嵌套循环连接(nested loops join)    访问次数：驱动表返回几条，被驱动表访问多少次。    驱动表是否有顺序：有。    是否要排序：否。    应用场景：  1. 关联中有一个表比较小；                             2. 被关联表的关联字段上有索引；                             3
Hash join与nested loops join的效率比较
weixin_34417183的博客
10-14 488
创建测试表SQL> create table t as select rownum id from dba_objects;Table created.SQL> create index idx_t on t(id);Index created.SQL> exec dbms_stats.gather_table_stats('sys','t',cascade...
表与表间的连接方式 Nest loop, Hash join and Sort merge join
Vindak's DBA Life
04-10 1370
Nest loop / Hash join / Sort merge join区别和说明 NESTED LOOP nested loop就是扫描一个表，每读到一条记录，就根据索引去另一个表里面查找，没有索引一般就不会是nested loops。对于被连接的数据子集较小的情况，nested loop连接是个较好的选择。 一般在nested loop中， 驱动表满足条件结果集不大
PostgreSQL HashJoin、MergeJoin、NestLooPJoin
qq_33968941的博客
12-25 587
PostgreSQL HashJoin、MergeJoin、NestLooPJoin 通过控制物理执行方式对比分析 List item PG_hint_plan使用 https://pghintplan.osdn.jp/pg_hint_plan.html 3. ## 测试结果分析
Nested Loop，Hash Join，Merge Join
技术世界
06-08 1159
原创文章，首发自本人个人博客站点，转载请务必注明出自http://www.jasongj.com Nested Loop，Hash Join，Merge Join介绍 Nested Loop: 对于被连接的数据子集较小的情况，Nested Loop是个较好的选择。Nested Loop就是扫描一个表（外表），每读到一条记录，就根据Join字段上的索引去另一张表（内
多表连接的三种方式详解 hash join、merge join、 nested loop
weixin_33836223的博客
04-30 2139
在多表联合查询的时候，如果我们查看它的执行计划，就会发现里面有多表之间的连接方式。多表之间的连接有三种方式：Nested Loops，Hash Join 和 Sort Merge Join.具体适用哪种类型的连接取决于 当前的优化器模式 （ALL_ROWS 和 RULE） 取决于表大小 取决于连接列是否有索引 取决于连接列是否排序 下面来介绍三种不同连接工作方式的不同： 实验s...
MySQL中Nested-Loop Join算法小结
09-10
MySQL在5.7版本中仍然不支持Hash Join，只支持NLJ和Merge Join。在某些情况下，NLJ可以通过选择正确的驱动表（即JOIN顺序）来优化。MySQL会选择预计结果集最小的表作为驱动表，因为这通常会导致更少的循环次数和更高...
HASH JOIN ,MERGE JOIN ,NESTED LOOP
cuixie2370的博客
07-05 71
SORT MERGE JOIN 排序合并连接通常情况下散列连接的效果都比排序合并连接要好，然而如果行源已经被排过序，在执行排序合并连接时不需要再排序了，这时排序合并连接的性能会优于散列连接。可以使用USE_MERGE(table...
HASH JOIN ,MERGE JOIN ,NESTED LOOP详解
袈裟本无清净，红尘不染性空。幽幽古刹千年钟，都是痴人说梦
12-24 157
1，排序 - - 合并连接（Sort Merge Join， SMJ） 　　内部连接过程： 　　1） 首先生成row source1需要的数据，然后对这些数据按照连接操作关联列（如A.col3）进行排序。 　　2） 随后生成row source2需要的数据，然后对这些数据按照与sort source1对应的连接操作关联列（如B.col4）进行排序。 　　3） 最后两边已排序...
浅谈merge join 与hash join的区别
tianlianchao1982的专栏
04-05 1577
Merge Joins Sort merge joins can be used to join rows from two independent sources. Hash joins generally perform. better than sort merge joins. On the other hand, sort merge joins can perform. bett
Merge join、Hash join、Nested loop join对比分析
热门推荐
开平人生
11-16 1万+
SQL server 内部实现了三种类型的内连接运算，大多数人从来没有听说过这些连接类型，因为它们不是逻辑连接也很少被用于代码中。那么它们什么时候会被用到呢？答案是要依情况而定。这就意味着要依赖于记录集和索引。查询优化器总是智能的选择最优的物理连接类型。我们知道SQL优化器创建一个计划开销是基于查询开销的，并依据此来选择最佳连接类型。         那查询优化器究竟是怎样从内部选择连接类型的呢
oracle 效率 join,Hash join与nested loops join的效率比较
weixin_34351588的博客
04-09 527
创建测试表SQL> create table t as select rownum id from dba_objects;Table created.SQL> create index idx_t on t(id);Index created.SQL> exec dbms_stats.gather_table_stats('sys','t',cascade=>true);...
SQL JOIN --Merge Join
weixin_34244102的博客
08-27 114
1概述Merge join 合并连接。两个集合进行merge join，需要有一个等值的条件，然后需要两个已排序好的集合。2 one-to-many与many-to-many2.1 One-to-many当参与merge join的两个集合中，其中一个集合在等值条件上是具有唯一性(如SELECT * FROM T1 INNER JOIN T2 ON T1.A=T2.B，如果T1在A列上具有唯一性)...
浅谈SQL Server中的三种物理连接操作(Nested Loop Join、Merge Join、Hash Join)
hzp666的博客
08-06 1664
简介 在SQL Server中，我们所常见的表与表之间的Inner Join,Outer Join都会被执行引擎根据所选的列，数据上是否有索引，所选数据的选择性转化为Loop Join,Merge Join,Hash Join这三种物理连接中的一种。理解这三种物理连接是理解在表连接时解决性能问题的基础，下面我来对这三种连接的原理，适用场景进行描述。 嵌套循环连接(Nested Loop Join) 循环嵌套连接是最基本的连接,正如其名所示那样，需要进行循环嵌套，这种连接方式的过程...
【大数据技术】表连接的三种join方式详解 hash join、merge join、nested loop
u011762522的博客
08-11 624
【大数据技术】表连接的三种join方式详解 hash join、merge join、nested loop
greenplum中,Nested Loop Join、Merge Join、Hash Join 都适合于哪些场景
最新发布
05-30
在 Greenplum 中，Nested Loop Join、Merge Join、Hash Join 都适合于不同的场景，具体如下： 1. Nested Loop Join：适合小表和中等大小表的 join 操作。Nested Loop Join 的原理是对于外层表的每一行，都扫描内层表，因此当外层表的数据量较小时，Nested Loop Join 的效率较高。 2. Merge Join：适合大表之间的 join 操作。Merge Join 的原理是将两个有序表合并成一个有序表，因此需要保证两个表都有序。在 Greenplum 中，Merge Join 通常需要在排序的基础上进行，因此需要考虑排序操作的开销。 3. Hash Join：适合大表和中等大小表的 join 操作。Hash Join 的原理是将 join 条件中的列进行 hash，然后将结果集进行匹配，因此需要考虑内存管理和 hash 算法的选择。在 Greenplum 中，可以采用 Bloom Filter 等方式来优化 Hash Join 的性能。 需要注意的是，在确定 join 策略时，需要考虑表的大小、数据分布、查询条件等因素，选择合适的 join 策略可以提高查询效率。同时，不同的 join 策略也有不同的优缺点，需要根据具体情况进行选择和使用。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值