阿里Mysql最佳实践

于 2024-07-28 16:29:18 发布
阅读量1.2k 收藏 9
点赞数 29
分类专栏： # 精通Mysql 文章标签： mysql 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/LittleStar_Cao/article/details/140752416
版权

参考阿里手册 Mysql规范，并补充一些示例以及理解

建表规约

【强制】表达是与否概念的字段，必须使用 is_xxx 的方式命名，数据类型是 unsigned tinyint（1 表示是，0 表示否）。

注意：POJO 类中的任何布尔类型的变量，都不要加 is 前缀，所以，需要在设置从 is_xxx 到 Xxx 的映射关
系。数据库表示是与否的值，使用 tinyint 类型，坚持 is_xxx 的命名方式是为了明确其取值含义与取值范围。
说明：任何字段如果为非负数，必须是 unsigned。
正例：表达逻辑删除的字段名 is_deleted，1 表示删除，0 表示未删除。

【强制】表名、字段名必须使用小写字母或者数字，禁止出现数字开头禁止两个下划线中间出现数字。数据库字段名的修改代价很大，因为无法进行预发布，所以字段名称需要慎重考虑

说明：MySQL 在 Windows 下不区分大小写，但在 Linux 下默认是区分大小写。因此，数据库名、表名、字段名，都不允
许出现任何大写字母，避免节外生枝。
正例：aliyun_admin，rdc_config，level3_name
反例：AliyunAdmin，rdcConfig，level_3_name

【强制】表名不使用复数名词

说明：表名应该仅仅表示表里面的实体内容，不应该表示实体数量，对应于 DO 类名也是单数形式，符合表达习惯。

【强制】禁用保留字，如 desc、range、match、delayed 等，请参考 MySQL 官方保留字

【强制】主键索引名为 pk_字段名；唯一索引名为 uk_字段名；普通索引名则为 idx_字段名。

说明：pk_即 primary key；uk_即 unique key；idx_即 index 的简称。

【强制】小数类型为 decimal，禁止使用 float 和 double。

说明：在存储的时候，float 和 double 都存在精度损失的问题，很可能在比较值的时候，得到不正确的结果。如果存
储的数据范围超过 decimal 的范围，建议将数据拆成整数和小数并分开存储。

【强制】如果存储的字符串长度几乎相等，使用 char 定长字符串类型

【强制】varchar 是可变长字符串，不预先分配存储空间，长度不要超过 5000，如果存储长度大于此值，定义字段类型为 text，独立出来一张表，用主键来对应，避免影响其它字段索引率

【强制】表必备三字段：id，create_time，update_time

说明：其中 id 必为主键，类型为 bigint unsigned、单表时自增、步长为 1。create_time，update_time 的类型均为datetime 类型， 如果要记录时区信息，那么类型设置为 timestamp。

【强制】在数据库中不能使用物理删除操作，要使用逻辑删除。

说明：逻辑删除在数据删除后可以追溯到行为操作。不过会使得一些情况下的唯一主键变得不唯一，需要根据情况来酌情解决。

【推荐】表的命名最好是遵循“业务名称_表的作用”。

正例：alipay_task / force_project / trade_config / tes_question

【推荐】库名与应用名称尽量一致。

【推荐】如果修改字段含义或对字段表示的状态追加时，需要及时更新字段注释

【推荐】字段允许适当冗余， 以提高查询性能， 但必须考虑数据一致。 冗余字段应遵循：

  • 不是频繁修改的字段
  • 不是唯一索引的字段
  • 不是varchar超长字段，更不能是text字段

正例：各业务线经常冗余存储商品名称，避免查询时需要调用 IC 服务获取。

【推荐】单表行数超过 500 万行或者单表容量超过 2GB， 才推荐进行分库分表。

说明：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。

【参考】合适的字符存储长度， 不但节约数据库表空间、节约索引存储， 更重要的是提升检索速度。

正例：无符号值可以避免误存负数，且扩大了表示范围
image.png

索引规约

【强制】业务上具有唯一特性的字段，即使是组合字段， 也必须建成唯一索引。

说明：不要以为唯一索引影响了 insert 速度，这个速度损耗可以忽略，但提高查找速度是明显的；另外，即使在应用层做了非常完善的校验控制，只要没有唯一索引，根据墨菲定律，必然有脏数据产生

【强制】超过三个表禁止 join。 需要 join 的字段，数据类型保持绝对一致； 多表关联查询时， 保证被关联的字段需要有索引

说明：即使双表 join 也要注意表索引、SQL 性能。

【强制】在 varchar 字段上建立索引时， 必须指定索引长度， 没必要对整个字段建立索引， 根据实际文本区分度决定索引长度

说明： 索引的长度与区分度是一对矛盾体， 一般对字符串类型数据， 长度为 20 的索引， 区分度会高达 90%以上，可以使用 count(distinct left(列名，索引长度)) / count(*) 的区分度来确定。
正例：
假设我们有一个用户表’users’，其中包含一个名称’email’的字段，该字段类型为’varchar(255)’

CREATE TABLE users (
  id INT PRIMARY KEY,
  name VARCHAR(100),
  email VARCHAR(255)
);
  1. 分析 email 字段的区分度

我们首先需要分析 email 字段的区分度，以确定合适的索引长度。区分度的计算公式为：

SELECT COUNT(DISTINCT LEFT(email, 索引长度)) / COUNT(*) AS 区分度 FROM users;

假设我们希望确定长度为 10 的索引的区分度：

SELECT COUNT(DISTINCT LEFT(email, 10)) / COUNT(*) AS 区分度 FROM users;
  1. 评估不同索引长度的区分度

我们可以测试不同长度的索引，以找到一个平衡点。通常，区分度达到 90% 以上即为较好的长度选择

-- 测试索引长度为 5 的区分度
SELECT COUNT(DISTINCT LEFT(email, 5)) / COUNT(*) AS 区分度 FROM users;

-- 测试索引长度为 10 的区分度
SELECT COUNT(DISTINCT LEFT(email, 10)) / COUNT(*) AS 区分度 FROM users;

-- 测试索引长度为 20 的区分度
SELECT COUNT(DISTINCT LEFT(email, 20)) / COUNT(*) AS 区分度 FROM users;
  1. 选择合适的索引长度

假设测试结果如下：

  • 索引长度为 5 的区分度：60%
  • 索引长度为 10 的区分度：85%
  • 索引长度为 20 的区分度：95%

基于上述结果，我们可以选择索引长度为 20，因为它的区分度已经达到 95%，符合我们的优化要求

  1. 创建索引

根据测试结果，我们可以创建一个长度为 20 的索引：

CREATE INDEX idx_email ON users (email(20));

【强制】页面搜索严禁左模糊或者全模糊， 如果需要请走搜索引擎来解决。

说明：索引文件具有 B-Tree 的最左前缀匹配特性，如果左边的值未确定，那么无法使用此索引。

【推荐】如果有 order by 的场景， 请注意利用索引的有序性。order by 最后的字段是组合索引的一部分，并且放在索引组合顺序的最后，避免出现 filesort 的情况，影响查询性能

正例：where a = ? and b = ? order by c；索引：a_b_c
正例：where a = ? order by b, c ；索引：a_b_c

反例：索引如果存在范围查询，那么索引有序性无法利用，如：WHERE a > 10 ORDER BY b；索引 a_b 无法排序

【推荐】利用覆盖索引来进行查询操作， 避免回表。

说明：如果一本书需要知道第 11 章是什么标题，会翻开第 11 章对应的那一页吗？目录浏览一下就好，这个目录就是起到覆盖索引的作用。
正例：能够建立索引的种类分为主键索引、唯一索引、普通索引三种，而覆盖索引只是一种查询的一种效果，用 explain的结果，extra 列会出现：using index。

【推荐】利用延迟关联或者子查询优化超多分页场景

说明：MySQL 并不是跳过 offset 行，而是取 offset+N 行，然后返回放弃前 offset 行，返回 N 行，那当 offset 特别大的时候，效率就非常的低下，要么控制返回的总页数，要么对超过特定阈值的页数进行 SQL 改写。

正例：先快速定位需要获取的 id 段，然后再关联：

SELECT t1.* FROM 表 1 as t1 , (select id from 表 1 where 条件 LIMIT 100000 , 20) as t2 where t1.id = t2.id

【推荐】SQL 性能优化的目标：至少要达到 range 级别，要求是 ref 级别，如果可以是 const 最好。

说明：

  • consts 单表中最多只有一个匹配行（主键或者唯一索引），在优化阶段即可读取到数据
  • ref 指的是使用普通的索引（normal index）
  • range 对索引进行范围检索

反例：explain 表的结果，type = index，索引物理文件全扫描，速度非常慢，这个 index 级别比较 range 还低，与全
表扫描是小巫见大巫

【推荐】建组合索引的时候，区分度最高的在最左边。

正例：如果 where a = ? and b = ?，a 列的几乎接近于唯一值（每一行都是唯一的，比如身份证号），那么只需要单建 idx_a 索引即可。
假设有一个表 users，包含 user_id、country 和 age 三个列。user_id 是唯一的，country 有少量重复值，而 age 有较多重复值

CREATE TABLE users (
    user_id INT PRIMARY KEY,
    country VARCHAR(50),
    age INT
);

如果我们有如下：

SELECT * FROM users WHERE user_id = ? AND country = ?;

由于 user_id 的区分度最高，可以仅为 user_id 建立索引：

CREATE INDEX idx_user_id ON users(user_id);

【推荐】存在非等号和等号混合判断条件时，在建索引时，请把等号条件的列前置

正例：假设我们有如下查询：

SELECT * FROM users WHERE age > 30 AND country = 'USA';

即使 age 的区分度可能更高，但由于 country 是等号条件，我们应该将 country 放在索引的最前面：

CREATE INDEX idx_country_age ON users(country, age);

【推荐】防止因字段类型不同造成的隐式转换， 导致索引失效

【参考】创建索引时避免有如下极端误解：

  1. 索引宁滥勿缺。认为一个查询就需要建一个索引
  2. 吝啬索引的创建。认为索引会消耗空间、严重拖慢记录的更新以及行的新增速度
  3. 抵制唯一索引。认为唯一索引一律需要在应用层通过“先查后插”方式解决。

SQL语句

【强制】不要使用 count(列名) 或 count(常量) 来替代 count()，count() 是 SQL92 定义的标准统计行数的语法，跟数据库无关，跟 NULL 和非 NULL 无关。

说明：count(*) 会统计值为 NULL 的行，而 count(列名) 不会统计此列为 NULL 值的行。

补充：count（*）和count（1）并没有所谓的性能差异，mysql45讲提到过

【强制】count(distinct col) 计算该列除 NULL 之外的不重复行数，注意 count(distinct col1 , col2) 如果其中一列全为 NULL，那么即使另一列有不同的值，也返回为 0。

【强制】当某一列的值全是 NULL 时，count(col) 的返回结果为 0；但 sum(col) 的返回结果为 NULL，因此使用 sum() 时需注意 NPE 问题

正例：可以使用如下方式来避免 sum 的 NPE 问题：SELECT IFNULL(SUM(column) , 0) FROM table;

【强制】使用 ISNULL() 来判断是否为 NULL 值。

说明：NULL 与任何值的直接比较都为 NULL

  1. NULL<>NULL 的返回结果是 NULL，而不是 false
  2. NULL=NULL 的返回结果是 NULL，而不是 true
  3. NULL<>1 的返回结果是 NULL，而不是 true。

反例：在 SQL 语句中，如果在 null 前换行，影响可读性。

select * from table where column1 is null and column3 is not null；而 ISNULL(column) 是一个整体，简洁易懂。
从性能数据上分析，ISNULL(column) 执行效率更快一些。

【强制】代码中写分页查询逻辑时，若 count 为 0 应直接返回，避免执行后面的分页语句

【强制】不得使用外键与级联，一切外键概念必须在应用层解决

说明：（概念解释）学生表中的 student_id 是主键，那么成绩表中的 student_id 则为外键。如果更新学生表中的student_id，同时触发成绩表中的 student_id 更新，即为级联更新。外键与级联更新适用于单机低并发，不适合分布式、高并发集群；级联更新是强阻塞，存在数据库更新风暴的风险；外键影响数据库的插入速度

【强制】禁止使用存储过程，存储过程难以调试和扩展，更没有移植性

【强制】数据订正（特别是删除或修改记录操作）时，要先 select，避免出现误删除的情况，确认无误才能执行更新语句

【强制】对于数据库中表记录的查询和变更，只要涉及多个表，都需要在列名前加表的别名（或表名）进行限定

说明：对多表进行查询记录、更新记录、删除记录时，如果对操作列没有限定表的别名（或表名），并且操作列在多个表中存在时，就会抛异常。
正例：select t1.name from first_table as t1 , second_table as t2 where t1.id = t2.id;
反例：在某业务中，由于多表关联查询语句没有加表的别名（或表名）的限制，正常运行两年后，最近在某个表中增加一个同名字段，在预发布环境做数据库变更后，线上查询语句出现出 1052 异常：
Column ‘name’ infield list is ambiguous。

【推荐】SQL 语句中表的别名前加 as，并且以 t1、t2、t3、…的顺序依次命名

说明：

  1. 别名可以是表的简称，或者是依照表在 SQL 语句中出现的顺序，以 t1、t2、t3 的方式命名。
  2. 别名前加 as 使别名更容易识别。

正例：select t1.name from first_table as t1 , second_table as t2 where t1.id = t2.id;

【推荐】in 操作能避免则避免，若实在避免不了，需要仔细评估 in 后边的集合元素数量，控制在1000 个之内

【参考】因国际化需要， 所有的字符存储与表示，均采用 utf8mb4 字符集，字符计数方法需要注意

说明：
SELECT LENGTH(“轻松工作”)；–返回为 12
SELECT CHARACTER_LENGTH(“轻松工作”)；–返回为 4
表情需要用 utf8mb4 来进行存储，注意它与 utf8 编码的区别。

【参考】TRUNCATE TABLE 比 DELETE 速度快，且使用的系统和事务日志资源少，但 TRUNCATE无事务且不触发 trigger，有可能造成事故，故不建议在开发代码中使用此语句

说明：TRUNCATE TABLE 在功能上与不带 WHERE 子句的 DELETE 语句相同。

ORM映射

【强制】在表查询中，一律不要使用 * 作为查询的字段列表，需要哪些字段必须明确写明。

说明：

  1. 增加查询分析器解析成本。
  2. 增减字段容易与 resultMap 配置不一致。
  3. 无用字段增加网络消耗，尤其是 text 类型的字段。

【强制】POJO 类的布尔属性不能加 is，而数据库字段必须加 is_，要求在 resultMap 中进行字段与属性之间的映射。

说明：参见定义 POJO 类以及数据库字段定义规定，在 sql.xml 增加映射，是必须的。

【强制】不要用 resultClass 当返回参数，即使所有类属性名与数据库字段一一对应，也需要定义；反过来，每一个表也必然有一个与之对应。

说明：配置映射关系，使字段与 DO 类解耦，方便维护

【强制】sql.xml 配置参数使用：#{}，#param# 不要使用 ${} 此种方式容易出现 SQL 注入

【强制】iBATIS 自带的 queryForList(String statementName，int start，int size) 不推荐使用

说明：其实现方式是在数据库取到 statementName 对应的 SQL 语句的所有记录，再通过 subList 取 start，size的子集合，线上因为这个原因曾经出现过 OOM

正例：
Map<String,Object> map = new HashMap<>(16);
map.put(“start”, start);
map.put(“size”, size);

【强制】不允许直接拿 HashMap 与 Hashtable 作为查询结果集的输

反例：某同学为避免写一个xxx，直接使用 Hashtable 来接收数据库返回结果，结果出现
日常是把 bigint 转成 Long 值，而线上由于数据库版本不一样，解析成 BigInteger，导致线上问题

【强制】更新数据表记录时，必须同时更新记录对应的 update_time 字段值为当前时间

【推荐】不要写一个大而全的数据更新接口。 传入为 POJO 类，不管是不是自己的目标更新字段，都进行

update table set c1 = value1 , c2 = value2 , c3 = value3；这是不对的。执行 SQL 时，不要更新无改动的字段，一是易出错；二是效率低；三是增加 binlog 存储

【参考】@Transactional 事务不要滥用。 事务会影响数据库的 QPS，另外使用事务的地方需要考虑各

方面的回滚方案，包括缓存回滚、搜索引擎回滚、消息补偿、统计修正等

【参考】中的 compareValue 是与属性值对比的常量，一般是数字，表示相等时带上此条

件；表示不为空且不为 null 时执行；表示不为 null 值时执行

ORM示例：

我们假设有一个用户表 user，包含以下字段：id、name、email、is_active、created_time 和 update_time。

1. 数据库表和 POJO 类定义

数据库表定义（user 表）

CREATE TABLE user (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(100) NOT NULL,
  email VARCHAR(100) NOT NULL,
  is_active BOOLEAN NOT NULL DEFAULT TRUE,
  created_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

POJO 类定义（User.java）

public class User {
    private Long id;
    private String name;
    private String email;
    private Boolean active;  // 布尔属性不加 is
    private Date createdTime;
    private Date updateTime;

    // getters and setters
}

2. MyBatis 映射文件（UserMapper.xml）

resultMap 定义
<resultMap id="userResultMap" type="com.example.User">
  <id property="id" column="id" />
  <result property="name" column="name" />
  <result property="email" column="email" />
  <result property="active" column="is_active" />  <!-- 字段映射 -->
  <result property="createdTime" column="created_time" />
  <result property="updateTime" column="update_time" />
</resultMap>

查询语句
<select id="selectUserById" resultMap="userResultMap">
  SELECT id, name, email, is_active, created_time, update_time
  FROM user
  WHERE id = #{id}
</select>

3. 参数使用 #{} 而非 ${}

查询示例
<select id="selectUsersByStatus" resultMap="userResultMap">
  SELECT id, name, email, is_active, created_time, update_time
  FROM user
  WHERE is_active = #{active}
</select>

4. 分页查询示例

Mapper 方法定义
public interface UserMapper {
    List<User> selectUsersWithPagination(Map<String, Object> params);
}

XML 映射文件
<select id="selectUsersWithPagination" resultMap="userResultMap">
  SELECT id, name, email, is_active, created_time, update_time
  FROM user
  LIMIT #{start}, #{size}
</select>

Java 调用示例

Map<String, Object> params = new HashMap<>(16);
params.put("start", 0);
params.put("size", 10);
List<User> users = userMapper.selectUsersWithPagination(params);

5. 更新数据时更新 update_time 字段

Mapper 方法定义
public interface UserMapper {
    void updateUser(User user);
}

XML 映射文件
<update id="updateUser">
  UPDATE user
  SET 
  name = #{name},
  email = #{email},
  is_active = #{active},
  update_time = CURRENT_TIMESTAMP  <!-- 强制更新 update_time -->
  WHERE id = #{id}
</update>
上海第一深情Alan
关注
专栏目录
Mysql数据库设计规范
05-07
在使用Mysql数据库时，首先要对MySQL数据库的设计规范有所了解，有了深刻的了解之后才能设计出更加规范和文档的数据库
MySQL设计规范
Black-Keys的博客
09-09 922
前言 本规范是在项目开发中整理的一些开发规范和技巧，期望能更充分利用MySQL的特性，得到更好的性能。主要提供给需要基于MySQL做应用开发的人员作为参考，方便完成更有效率的开发。 1.1 数据库设计 数据库设计的目标三个：功能实现，可伸缩性，可用性。设计时需要平衡业务技术各个方面，做好取舍。数据库的架构设计时最重要的，80%的性能优势来自架构设计的优势。 2.1 版本选择 官方版本建议
MySQL数据库设计规范
架构之路
06-06 523
数据库命名规范1、所有数据库对象名称必须使用小写字母并用下划线分割。2、所有数据库对象名称禁止使用MySQL保留关键字3、数据库对象的命名要能做到见名识义，并且最好不要超过32个字符。4、临时表必须以tmp为前缀并以日期为后缀。5、备份库，备份表必须以bak为前缀并以日期为后缀。6、所有存储相同数据的列名和列类型必须一致。数据库基本设计规范1、所有表必须使用Innodb存储引擎。2、数据库和表的字...
MYSQL数据库设计规范与原则
...
02-15 2821
MYSQL数据库设计规范 1、数据库命名规范 采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成; 命名简洁明确(长度不能超过30个字符); 例如：user, stat, log, 也可以wifi_user, wifi_stat, wifi_log给数据库加个前缀; 除非是备份数据库可以加0
数据库杂乱记
D_A_I_H_A_O的博客
07-18 266
概述 SQL(Structural query language)语句分三种类型： DML(Data Manipulation Language) 数据操纵语言 DDL(Data Definition Language) 数据定义语言 DCL(Data Control Language) 数据控制语言 DML DML用于查询与修改数据记录。包括以下语句： INSERT： 添加数据到数据库中 UPDATE： 修改数据库中的数据 DELETE： 删除数据库中的数据 SELECT： 选择(查询)数据 D
阿里巴巴MySQL开发规范
02-21
阿里巴巴MySQL开发规范是一套针对MySQL数据库设计、实现及优化的最佳实践指南。这套规范旨在提高数据库应用的稳定性、性能和可维护性，同时降低潜在的风险。规范主要分为三个部分：建库建表、创建索引、编写SQL语句...
阿里MySQL备份恢复指南
11-19
在实践中，用户还需要遵循最佳实践，如定期测试恢复流程，以确保在真实情况下能够顺利恢复。此外，理解并遵守阿里云的服务级别协议（SLA）和数据保护政策也是确保数据安全的关键。 总的来说，阿里MySQL备份恢复指南...
阿里Tengine直播最佳实践.pdf
08-29
### 阿里Tengine直播最佳实践 #### 核心知识点概述 1. **从传统LNMT到分布式架构转型**：介绍了从传统的Linux+Nginx+Tomcat+MySQL（LNMT）架构向分布式架构（包括负载均衡、消息系统、服务化、分布式存储等组件）...
阿里云-深入MySQL实战：快速了解MySQL核心技术
最新发布
05-31
为了进一步推广MySQL的核心技术和最佳实践，阿里云于2021年初推出了为期七天的深入MySQL实战营。该实战营旨在帮助开发者们深入了解MySQL在高并发场景下的应用技巧与实践经验，特别是针对如双11这样的大型促销活动时...
阿里云下配置MySQL远程连接的步骤详解
09-09
在实际操作中，确保遵循最佳安全实践，如使用强密码，限制对数据库的不必要的访问，以及定期备份数据，以防止潜在的安全风险。 总结：配置阿里云MySQL远程连接涉及修改用户权限、调整服务器防火墙和安全组规则。...
MySQL数据库设计规范（大佬整理）
shw12357的专栏
09-14 396
MySQL数据库设计规范 1. 规范背景与目的 3 2. 设计规范 3 3.1 数据库设计 3 3.2.1 库名 3 3.2.2 表结构 3 3.2.3 列数据类型优化 4 3.2.4 索引设计 6 3.2.5 分库分表、分区表 7 3.2.6 字符集 7 3.2.7 程序DAO层设计建议 7 3.2.8 一个规范的建表语句示例 8 3.2 SQL编写 8 3.2.1 DML语句 8 3.2.2 多表连接 9 3.2.3 事务 10 3.2.4 排序和分组 10 3..
MYSQL数据库设计规范
MYSQL轻松学的专栏
11-20 627
一、基础规范 （1）必须使用InnoDB存储引擎 解读：支持事务、行级锁、并发性能更好、CPU及内存缓存页优化使得资源利用率更高   （2）必须使用UTF8字符集 解读：万国码，无需转码，无乱码风险，节省空间   （3）数据表、数据字段必须加入中文注释 解读：若干年后谁知道这个c1,c2,c3字段是干嘛的   （4）禁止使用存储过程、视图
mysql设计数据库和表的规范
03-08 563
一、数据库设计 1、一般都使用 INNODB 存储引擎，除非读写比率&lt;1%,才考虑使用 MYISAM 存储引擎;其 他存储引擎请在 DBA 的建议下使用。 2、Stored procedure (包括存储过程，函数，触发器)对于 MYSQL 来说还不是很成熟， 没有完善的出错记录处理，不建议使用。 3、UUID()，USER()这样的MySQL INSIDE 函数对于复制来说是很危险的，会...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值