【GreatSQL优化器-09】make_join_query_block

【GreatSQL优化器-09】make_join_query_block

一、make_join_query_block介绍

GreatSQL优化器对于多张表join的连接顺序在前面的章节介绍过的best_access_path函数已经执行了,接着就是把where条件进行切割然后推给合适的表。这个过程就是由函数make_join_query_block来执行的。

下面用几个简单的例子来说明join连接中条件推送是什么。

CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 INT,date1 DATETIME);
INSERT INTO t1 VALUES (1,10,'2021-03-25 16:44:00.123456'),(2,1,'2022-03-26 16:44:00.123456'),(3,4,'2023-03-27 16:44:00.123456'),(5,5,'2024-03-25 16:44:00.123456'),(7,null,'2020-03-25 16:44:00.123456'),(8,10,'2020-10-25 16:44:00.123456'),(11,16,'2023-03-25 16:44:00.123456');
CREATE TABLE t2 (cc1 INT PRIMARY KEY, cc2 INT);
INSERT INTO t2 VALUES (1,3),(2,1),(3,2),(4,3),(5,15);
CREATE TABLE t3 (ccc1 INT, ccc2 varchar(100));
INSERT INTO t3 VALUES (1,'aa1'),(2,'bb1'),(3,'cc1'),(4,'dd1'),(null,'ee');
CREATE INDEX idx1 ON t1(c2);
CREATE INDEX idx2 ON t1(c2,date1);
CREATE INDEX idx2_1 ON t2(cc2);
CREATE INDEX idx3_1 ON t3(ccc1);

下面这个例子((t1.c1 = t3.ccc1) or (t3.ccc1 < 3))条件推送给t1

greatsql> EXPLAIN FORMAT=TREE SELECT * FROM t1 join t3 ON t1.c1=t3.ccc1 or t3.ccc1<3;
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                                                                                                                                                         |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| -> Filter: ((t1.c1 = t3.ccc1) or (t3.ccc1 < 3))  (cost=5.26 rows=35)
    -> Inner hash join (no condition)  (cost=5.26 rows=35)
        -> Index scan on t1 using idx2  (cost=0.34 rows=7)
        -> Hash
            -> Table scan on t3  (cost=0.75 rows=5)
 |
+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

下面例子(t1.c1 < 3)条件推给t1,(ccc1=t1.c1)条件推给t3

greatsql> EXPLAIN FORMAT=TREE SELECT * FROM t1 join t3 ON t1.c1=t3.ccc1 and t3.ccc1<3;
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| EXPLAIN                                                                                                                                                                                                                          |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| -> Nested loop inner join  (cost=2.40 rows=2)
    -> Filter: (t1.c1 < 3)  (cost=1.70 rows=2)
        -> Index scan on t1 using idx2  (cost=1.70 rows=7)
    -> Index lookup on t3 using idx3_1 (ccc1=t1.c1)  (cost=0.30 rows=1)
 |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

下面例子((t3.ccc1 = t1.c2) or (t3.ccc1 is null) or (t3.ccc2 like 'a%'))条件推给t3,(((t3.ccc1 = t1.c2) and (t2.cc1 = t1.c1)) or (t3.ccc1 is null) or (t3.ccc2 like 'a%'))条件推给t2

greatsql> EXPLAIN SELECT * FROM t2,t1,t3 WHERE t1.c1=t2.cc1 AND t1.c2=t3.ccc1 OR t3.ccc1 IS NULL OR t3.ccc2 LIKE 'a%';
| -> Filter: (((t3.ccc1 = t1.c2) and (t2.cc1 = t1.c1)) or (t3.ccc1 is null) or (t3.ccc2 like 'a%'))  (cost=14.27 rows=85)
    -> Inner hash join (no condition)  (cost=14.27 rows=85)
        -> Index scan on t2 using idx2_1  (cost=0.09 rows=5)
        -> Hash
            -> Filter: ((t3.ccc1 = t1.c2) or (t3.ccc1 is null) or (t3.ccc2 like 'a%'))  (cost=4.70 rows=17)
                -> Inner hash join (no condition)  (cost=4.70 rows=17)
                    -> Table scan on t3  (cost=0.07 rows=5)
                    -> Hash
                        -> Index scan on t1 using idx2  (cost=0.95 rows=7)

二、make_join_query_block代码解释

make_join_query_block函数通过join表顺序和每张表的table_map属性以及cond条件的属性来决定cond条件添加到哪张表,并且可能会重新对表的索引进行check找出cost更低的索引,下面是代码解析。

bool JOIN::optimize() {
  make_join_query_block();
}

static bool make_join_query_block(JOIN *join, Item *cond) {
  for (uint i = join->const_tables; i < join->tables; i++) {
      // 这四个变量说明见表一
      JOIN_TAB *const tab = join->best_ref[i];
      const plan_idx first_inner = tab->first_inner();
      const table_map used_tables = tab->prefix_tables();
      const table_map current_map = tab->added_tables();
      if (cond)
        // 这里通过table_map属性决定了是否给这个表添加条件,见下面表二、表四和表五说明
        tmp = make_cond_for_table(thd, cond, used_tables, current_map, false);
     // 如果recheck_reason=true,这里需要重新做一次确认,找出cost最低的索引。见表六
      if (recheck_reason)
        test_if_order_by_key();
        test_if_cheaper_ordering();
        test_quick_select();
      }  
      /* Add conditions added by add_not_null_conds(). */
      if (and_conditions(&tmp, tab->condition())) return true;
      if (join->attach_join_conditions(i)) return true;
  }
}
// 条件添加基本原则是条件带有表列的添加到该表,但是如果属性不一致的话也不会添加,只会添加到最后一张表。具体解释见下面实际例子。

表一:上面四个变量解释

变量解释说明
tab当前检测是否需要加条件的表这里是排序后的表
first_inner多张表join的时候排序后的第一张表例如:SELECT * FROM t1 LEFT OUTER JOIN (t2 JOIN t3) ON X
used_tables包括当前表以及之前的左连接表的信息如果该值=0代表所有表,used_tables信息在之前的set_prefix_tables()获得
current_map当前检测表信息包含被添加的一些信息

表二:make_cond_for_table()动作

场景解释返回
AND条件遍历Item_cond包含的所有list,判断list是否有包含该表左连接的表的列,有的话加入新的Item_cond_andnew Item_cond_and
OR条件遍历Item_cond包含的所有list,判断list是否有包含该表左连接的表的列,有的话加入新的Item_cond_ornew Item_cond_or
其他Item如果条件没有涉及左连接的表,或者给所有表添加条件cond->is_expensive()nullptr(无条件)
其他Item如果条件涉及左连接的表并且item与表的属性一致(见表四)该Item条件

表三:is_expensive_processor()函数

Itemis_expensive说明
Item_udf_functrue这个Item作为条件不会添加到所有join表里面
Item_func_sptrue这个Item作为条件不会添加到所有join表里面
普通Itemfalse这个Item作为条件可能会添加到join表里面

表四:Item的table_map属性

table_map使用的Item说明举例
INNER_TABLE_BITItem_trigger_field,Item_sp_variable,Item_param,Item_func_connection_id,Item_func_get_system_var,Item_func_user,Item_load_file, Item_func_sp,Item_func_get_user_var确定的常量,在表每行都一样f1(1)@@optimizer_search_depth
OUTER_REF_TABLE_BITItem_field,Item_ref,Item_view_ref,Item_outer_ref内部field需要外部query block的item信息select (select t1.a from t1 as t2 limit 1) from t1 group by t1.pk,t1.a就是OUTER_REF_TABLE_BIT
RAND_TABLE_BITItem_func_rand,Item_func_sleep,Item_func_uuid,Item_func_sysdate_local,Item_func_reject_if,Item_func_sp,Item_func_get_user_var不确定的,表每行都要换数据,非只有一行表,跟INNER_TABLE_BIT相反f1(t1.c1)
PSEUDO_TABLE_BITS包含以上三个

表五:表连接添加的属性

table_map第一张表中间的表最后一张表
INNER_TABLE_BITyes
OUTER_REF_TABLE_BITallow_outer_refs
RAND_TABLE_BITyes

表六:表的索引是否要重新check

recheck_reason说明
DONT_RECHECK没有索引的表不需要重新check
NOT_FIRST_TABLE不是第一张表需要重新check
LOW_LIMIT带有limit语句的sql需要重新check
三、实际例子说明

接下来看几个例子来说明上面的代码。

首先看一下最后确定的连接顺序,为t1,t3,t2,因为条件不带有RAND_TABLE_BIT的Item,因此最后是按照cond含有的列推送给对应表来实现的。

例子一:

greatsql> EXPLAIN SELECT * FROM t2,t1,t3 WHERE t1.c1=t2.cc1 AND t1.c2=t3.ccc1 OR t3.ccc1 IS NULL OR t3.ccc2 LIKE 'a%';
+----+-------------+-------+------------+-------+-------------------+--------+---------+------+------+----------+---------------------------------------------------------+
| id | select_type | table | partitions | type  | possible_keys     | key    | key_len | ref  | rows | filtered | Extra                                                   |
+----+-------------+-------+------------+-------+-------------------+--------+---------+------+------+----------+---------------------------------------------------------+
|  1 | SIMPLE      | t1    | NULL       | index | PRIMARY,idx1,idx2 | idx2   | 11      | NULL |    7 |   100.00 | Using index                                             |
|  1 | SIMPLE      | t3    | NULL       | ALL   | idx3_1            | NULL   | NULL    | NULL |    5 |    48.80 | Using where; Using join buffer (hash join)              |
|  1 | SIMPLE      | t2    | NULL       | index | PRIMARY           | idx2_1 | 5       | NULL |    5 |   100.00 | Using where; Using index; Using join buffer (hash join) |
+----+-------------+-------+------------+-------+-------------------+--------+---------+------+------+----------+---------------------------------------------------------+

表一:是否把cond条件推送给表

CONDt1[t1,]t3[t1,t3,]t2
(t1.c1=t2.cc1)nonoyes
(t3.ccc1 = t1.c2)noyesyes
(t3.ccc1 is null)noyesyes
(t3.ccc2 like 'a%')noyesyes

注:这里的中括号代表当前检测表的左连接表,中括号右边就是当前正在检测的表

表二:表的table_map值

CONDt1t3t2
best_ref->table_ref->map()0x0100x1000x001
best_ref->prefix_tables()INNER_TABLE_BIT+ OUTER_REF_TABLE_BIT+0x010INNER_TABLE_BIT+ OUTER_REF_TABLE_BIT+0x010+0x100INNER_TABLE_BIT+OUTER_REF_TABLE_BIT +RAND_TABLE_BIT+0x010+0x100+0x001
best_ref->added_tables()INNER_TABLE_BIT+ OUTER_REF_TABLE_BIT+0x0100x100RAND_TABLE_BIT+0x001

注:这里的INNER_TABLE_BIT和OUTER_REF_TABLE_BIT在函数JOIN::set_prefix_tables()默认加上了

看一下结果是否符合预期,确实如上表所述。这里看到又执行了一次test_quick_select()来确定走哪个索引。

"attaching_conditions_to_tables": {
              "original_condition": "(((`t3`.`ccc1` = `t1`.`c2`) and (`t2`.`cc1` = `t1`.`c1`)) or (`t3`.`ccc1` is null) or (`t3`.`ccc2` like 'a%'))",
              "attached_conditions_computation": [
                {
                  "table": "`t2`",
                  "rechecking_index_usage": { 这里对索引重新做了一次check
                    "recheck_reason": "not_first_table",
                    "range_analysis": {
                      "table_scan": {
                        "rows": 5,
                        "cost": 3.6
                      },
                      "potential_range_indexes": [
                        {
                          "index": "PRIMARY",
                          "usable": true,
                          "key_parts": [
                            "cc1"
                          ]
                        },
                        {
                          "index": "idx2_1",
                          "usable": false,
                          "cause": "not_applicable"
                        }
                      ],
                      "best_covering_index_scan": {
                        "index": "idx2_1",
                        "cost": 0.751098,
                        "chosen": true
                      },
                      "setup_range_conditions": [
                      ],
                      "group_index_range": {
                        "chosen": false,
                        "cause": "not_single_table"
                      },
                      "skip_scan_range": {
                        "chosen": false,
                        "cause": "not_single_table"
                      }
                    }
                  }
                }
              ],
              "attached_conditions_summary": [
                {
                  "table": "`t1`",
                  "attached": null
                },
                {
                  "table": "`t3`",
                  "attached": "((`t3`.`ccc1` = `t1`.`c2`) or (`t3`.`ccc1` is null) or (`t3`.`ccc2` like 'a%'))"
                },
                {
                  "table": "`t2`",
                  "attached": "(((`t3`.`ccc1` = `t1`.`c2`) and (`t2`.`cc1` = `t1`.`c1`)) or (`t3`.`ccc1` is null) or (`t3`.`ccc2` like 'a%'))"
                }
              ]
            }
          },
          {
            "finalizing_table_conditions": [
              {
                "table": "`t3`",
                "original_table_condition": "((`t3`.`ccc1` = `t1`.`c2`) or (`t3`.`ccc1` is null) or (`t3`.`ccc2` like 'a%'))",
                "final_table_condition   ": "((`t3`.`ccc1` = `t1`.`c2`) or (`t3`.`ccc1` is null) or (`t3`.`ccc2` like 'a%'))"
              },
              {
                "table": "`t2`",
                "original_table_condition": "(((`t3`.`ccc1` = `t1`.`c2`) and (`t2`.`cc1` = `t1`.`c1`)) or (`t3`.`ccc1` is null) or (`t3`.`ccc2` like 'a%'))",
                "final_table_condition   ": "(((`t3`.`ccc1` = `t1`.`c2`) and (`t2`.`cc1` = `t1`.`c1`)) or (`t3`.`ccc1` is null) or (`t3`.`ccc2` like 'a%'))"
              }
            ]
          },
          {
            "refine_plan": [
              {
                "table": "`t1`"
              },
              {
                "table": "`t3`"
              },
              {
                "table": "`t2`"
              }
            ]
          }
        ]
      }
    }

如果条件带有RAND_TABLE_BIT的Item,那么即使cond带有表的列,也不会推送给对应的表,而是推送到最后一张表。看下面的t1.c1 < rand()这个条件。

例子二:

greatsql> SELECT * FROM t2,t1,t3 WHERE t1.c1=t2.cc1 AND t1.c2=t3.ccc1 OR t3.ccc1 IS NULL AND t1.c1 < rand();
              "attached_conditions_summary": [
                {
                  "table": "`t1`",
                  "attached": null
                },
                {
                  "table": "`t3`",
                  "attached": "((`t3`.`ccc1` = `t1`.`c2`) or (`t3`.`ccc1` is null))"
                },
                {
                  "table": "`t2`",
                  "attached": "(((`t3`.`ccc1` = `t1`.`c2`) and (`t2`.`cc1` = `t1`.`c1`)) or ((`t3`.`ccc1` is null) and (`t1`.`c1` < rand())))"  看到条件t1.c1 < rand()没有推送给t1而是推送到最后一张表t2去了
                }
              ]
            }
          },
          {
            "finalizing_table_conditions": [
              {
                "table": "`t3`",
                "original_table_condition": "((`t3`.`ccc1` = `t1`.`c2`) or (`t3`.`ccc1` is null))",
                "final_table_condition   ": "((`t3`.`ccc1` = `t1`.`c2`) or (`t3`.`ccc1` is null))"
              },
              {
                "table": "`t2`",
                "original_table_condition": "(((`t3`.`ccc1` = `t1`.`c2`) and (`t2`.`cc1` = `t1`.`c1`)) or ((`t3`.`ccc1` is null) and (`t1`.`c1` < rand())))",
                "final_table_condition   ": "(((`t3`.`ccc1` = `t1`.`c2`) and (`t2`.`cc1` = `t1`.`c1`)) or ((`t3`.`ccc1` is null) and (`t1`.`c1` < rand())))"
              }
            ]
          },
          {
            "refine_plan": [
              {
                "table": "`t1`"
              },
              {
                "table": "`t3`"
              },
              {
                "table": "`t2`"
              }

看一下每张表的属性:

CONDt1t3t2
best_ref->table_ref->map()0x0100x1000x001
best_ref->prefix_tables()INNER_TABLE_BIT+ OUTER_REF_TABLE_BIT+0x010INNER_TABLE_BIT+ OUTER_REF_TABLE_BIT+0x010+0x100INNER_TABLE_BIT+OUTER_REF_TABLE_BIT +RAND_TABLE_BIT+0x010+0x100+0x001
best_ref->added_tables()INNER_TABLE_BIT+ OUTER_REF_TABLE_BIT+0x0100x100RAND_TABLE_BIT+0x001
四、总结

从上面优化器最早的步骤我们认识了make_join_query_block函数的作用,知道了通过join表顺序和每张表的table_map属性以及cond条件的属性来决定cond条件添加到哪张表,并且可能会重新对表的索引进行check找出cost更低的索引,需要注意的是有的带有表列的条件不会被添加到对应表,因为Item的属性跟表的属性不一致所以最后只会被添加到最后一张join表。

Enjoy GreatSQL :)

关于 GreatSQL

GreatSQL是适用于金融级应用的国内自主开源数据库,具备高性能、高可靠、高易用性、高安全等多个核心特性,可以作为MySQL或Percona Server的可选替换,用于线上生产环境,且完全免费并兼容MySQL或Percona Server。

相关链接: GreatSQL社区 Gitee GitHub Bilibili

GreatSQL社区:

image

社区有奖建议反馈: https://greatsql.cn/thread-54-1-1.html

社区博客有奖征稿详情: https://greatsql.cn/thread-100-1-1.html

(对文章有疑问或者有独到见解都可以去社区官网提出或分享哦~)

技术交流群:

微信&QQ群:

QQ群:533341697

微信群:添加GreatSQL社区助手(微信号:wanlidbc )好友,待社区助手拉您进群。

代码下载链接: https://pan.quark.cn/s/a4b39357ea24 iSecure Center综合安防管理平台配置手册V2.0最新完整版。综合安防管理平台是一个集成了多种功能的智能化系统,通过接入视频监控、停车场、门禁以及报警检测等设备,达成安防信息化集成与联动。以电子地图作为核心载体,融合各类安防设备,达成安防信息化集成与联动。 【海康威视iSecure Center综合安防管理平台配置手册 V2.0.0】是专门针对该公司的安防管理系统而编写的详细指南。iSecure Center是一个集成化、智能化的解决方案,其目标是通过整合视频监控、停车场管理、门禁控制和报警系统等多个安全子系统,达成全面的安防信息化集成与联动。平台的核心作用是借助电子地图作为基础,整合各种安防功能,以提供高效且全面的安全监控和管理。 手册中明确指出,iSecure Center的配置和使用仅限于海康威视HIKVISION的用户,并且详细说明了版权和法律声明,强调手册内容的所有权归属于杭州海康威视数字技术股份有限公司,未经授权,禁止进行任何形式的复制、翻译或修改。同时,手册也声明了产品仅适用于中国大陆地区,并且在法律允许的范围内,产品按照现有状态提供,不提供任何形式的保证,对于因使用产品或手册所导致的损失,公司不承担任何赔偿责任。 手册还特别警示用户,将产品接入互联网可能面临风险,如网络攻击、黑客入侵或病毒感染,用户需自行承担这些风险。同时,用户必须遵守适用的法律法规,不得将产品用于侵犯第三方权利或不当用途,否则公司将不承担任何责任。 在操作前,手册提供了符号约定,包括说明、注意和危险等级的标识,帮助用户理解文档中关键信息的重要性。例如,“注意”用于提醒用户重要操作或...
源码下载地址: https://pan.quark.cn/s/a4b39357ea24 gddrxy综合性实验——某系统的设计与实现---互联网应用开发(JSP)4 1. 在MySQL数据库中构建用于实验的数据表,要求包含至少三个字段,并在其中至少加入一条数据记录 2. 设计一个数据录入界面,将用户提交的信息发送至Servlet以执行合法性验证,若验证通过则调用DAO组件向数据表中追加一条新记录 实验报告 实验名称:综合性实验——某系统的设计与实现(互联网应用开发——JSP) 一、实验目的与要求 本次实验旨在使学生深入掌握并熟练运用JavaServer Pages (JSP) 技术开展互联网应用开发工作,特别是在数据库交互方面的实践。通过本次实践操作,期望达成以下学习目标: 1. 精通JSP在数据库层面的增删改查(Create, Read, Update, Delete)操作,包括建立数据库连接、执行SQL指令以及管理结果集等环节。 2. 掌握Servlet的生命周期机制,理解其在Web系统中的功能定位与工作流程。 3. 学会构建动态网页,实现用户输入信息的采集,并在服务器端完成数据校验与处理流程。 二、实验原理与内容 1. JSP进行数据库操作的典型流程涵盖数据库连接建立、SQL指令执行、结果集处理以及连接关闭等多个关键步骤。 2. Servlet作为Java Web应用程序的核心构成部分之一,具有初始化、服务、销毁这三个生命周期阶段。在本次实验中,Servlet将负责接收并处理来自JSP页面的请求,完成数据合法性校验工作。 三、实验步骤与结果 1. 数据库准备: - 采用MySQL数据库创建一个实验用的数据表,例如命名"Student",表中包含"ID"(作...
内容概要:本文详细介绍了基于风光储能和需求响应的微电网日前经济调度模型的Python代码实现,重点探讨了在风能、光伏等可再生能源出力具有不确定性的背景下,如何结合储能系统的运行特性与用户侧的需求响应机制,实现微电网系统的日前优化调度。该模型通过构建精确的数学模型并结合高效的优化算法,对分布式电源、储能设备及可控负荷进行协调优化,旨在最小化系统运行成本、提升可再生能源的消纳水平,并确保供电的安全性与稳定性。文中提供的完整Python代码实现了从数据输入、模型构建到求解分析的全流程,便于读者复现、验证与二次开发。; 适合人群:具备一定电力系统基础知识和Python编程能力,从事新能源、微电网、智能电网等相关领域研究的研究生、科研人员及工程技术人员。; 使用场景及目标:①用于高校或科研机构开展微电网优化调度相关课题的教学与科研工作;②为实际微电网项目的日前调度策略设计提供技术支撑与仿真验证工具;③帮助研究人员深入掌握基于Python平台的能源系统建模与优化求解方法。; 阅读建议:建议读者结合文档中的理论推导与代码实现同步学习,重点关注目标函数设计、约束条件建模及优化求解器调用等关键环节,并尝试调整参数设置或拓展模型结构以适配不同应用场景。
内容概要:本文围绕电力系统短期负荷预测问题,深入研究了基于极限学习机(ELM)及其智能优化算法改进模型的预测方法,重点实现了ELM、白鲸优化算法(BWO)优化ELM以及鹭鹰优化算法(IBO)优化ELM三种预测模型,并通过Matlab平台进行仿真与性能对比。研究旨在提升负荷预测的精度与鲁棒性,解决传统ELM因输入权重和偏置随机初始化导致的性能不稳定问题。通过引入两种新兴的元启发式优化算法对ELM的关键参数进行全局寻优,有效提升了模型的泛化能力与收敛稳定性。文章系统地完成了模型构建、参数优化、实验设计与结果分析,验证了优化后模型在短期负荷预测中的优越性,为电力系统调度决策提供了高精度的数据支撑和技术路径。; 适合人群:具备一定电力系统基础知识、时间序列预测背景及Matlab编程能力的科研人员、电气工程专业高校研究生,以及从事智能电网、能源管理与负荷预测相关工作的工程技术人员。; 使用场景及目标:①应用于电力系统短期负荷预测,提升电网运行调度的精确性与经济性;②为智能优化算法与浅层神经网络融合研究提供可复现的技术方案与实验基准;③作为科研项目、学位论文或工程实践中负荷预测模块的核心算法参考。; 阅读建议:建议读者结合所提供的Matlab代码,深入理解ELM网络结构原理及白鲸、鹭鹰优化算法的实现机制,重点关注参数寻优过程与预测误差指标(如MAE、RMSE、MAPE)的对比分析,建议进一步尝试在不同数据集上验证模型泛化能力,并探索将其拓展至中长期负荷预测或其他时序预测领域。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值