mysql8使用日志--auto_increment自增值

最新推荐文章于 2025-03-20 21:18:39 发布
最新推荐文章于 2025-03-20 21:18:39 发布
阅读量1k 收藏 1
点赞数 2
分类专栏： mysql
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/u014043168/article/details/112788586
版权

最近做项目用到mysql8，有个业务场景是创建完资料后跳到资料详情。按常理直接返回个insert id了事。问题就此发生了，每次输出的自增值居然是一样的。然后就进行手动调试

SELECT AUTO_INCREMENT FROM information_schema.`TABLES` WHERE Table_Schema='dbname' AND table_name = 'tablename';

发现查询出来的AUTO_INCREMENT确实是一样的，这就很奇怪了，于是去翻了下mysql的资料。

在5.7及以前，alter table修改的auto_increment值确实是记录到tables表的auto_increment列的，但是有一个缺点是，tables表的引擎是memory，也就是说，如果MySQL重启了，这个表记录的auto_increment值就丢失了。例如tab表当前的auto_increment值是30，使用alter table将其修改为50，那么tables表的auto_increment列确实是记录显示了50，但如果tab没有插入任何数据，并重启了MySQL（不管是正常还是异常重启），下一次运行时，tab表的auto_increment属性就会回退到30，同时tables表的auto_increment列显示的也是30。
那么既然tables是memory引擎表，重启之后理应没有数据才对，为什么auto_increment列还显示30呢？原因是MySQL重启后，通过select max(col) from tab for update的方式，来选出当前的最大值并赋值给auto_increment。
那么到了8.0以后，有什么变化呢？auto_increment的值会记录到redo log里了。什么概念，redo log大哥出手，就意味着下次重启还能把值要回来啊，不再随着重启打水漂。
除了redo log，在系统表中也会记录auto_increment的信息，例如tables表。那么，在插入新行时，递增列应该参考redo log还是系统表呢？而且从上面的例子可以看到，tables记录根本就不准确。其实答案就一句话，哪个是最新的，就用哪个。
那么回到系统表的问题上，既然要在重启后提供参考，总得靠谱一点吧？以前那么老实，到新版就变调皮了啊。看一下8.0以前的tables表定义：

mysql> show create table tables\G
*************************** 1. row ***************************
       Table: TABLES
Create Table: CREATE TEMPORARY TABLE `TABLES` (
  `TABLE_CATALOG` varchar(512) NOT NULL DEFAULT '',
  `TABLE_SCHEMA` varchar(64) NOT NULL DEFAULT '',
  `TABLE_NAME` varchar(64) NOT NULL DEFAULT '',
  `TABLE_TYPE` varchar(64) NOT NULL DEFAULT '',
  `ENGINE` varchar(64) DEFAULT NULL,
  `VERSION` bigint(21) unsigned DEFAULT NULL,
  `ROW_FORMAT` varchar(10) DEFAULT NULL,
  `TABLE_ROWS` bigint(21) unsigned DEFAULT NULL,
  `AVG_ROW_LENGTH` bigint(21) unsigned DEFAULT NULL,
  `DATA_LENGTH` bigint(21) unsigned DEFAULT NULL,
  `MAX_DATA_LENGTH` bigint(21) unsigned DEFAULT NULL,
  `INDEX_LENGTH` bigint(21) unsigned DEFAULT NULL,
  `DATA_FREE` bigint(21) unsigned DEFAULT NULL,
  `AUTO_INCREMENT` bigint(21) unsigned DEFAULT NULL,
  `CREATE_TIME` datetime DEFAULT NULL,
  `UPDATE_TIME` datetime DEFAULT NULL,
  `CHECK_TIME` datetime DEFAULT NULL,
  `TABLE_COLLATION` varchar(32) DEFAULT NULL,
  `CHECKSUM` bigint(21) unsigned DEFAULT NULL,
  `CREATE_OPTIONS` varchar(255) DEFAULT NULL,
  `TABLE_COMMENT` varchar(2048) NOT NULL DEFAULT ''
) ENGINE=MEMORY DEFAULT CHARSET=utf8

mysql8之后


mysql> show create table tables\G
*************************** 1. row ***************************
                View: TABLES
         Create View: CREATE ALGORITHM=UNDEFINED DEFINER=`mysql.infoschema`@`localhost` SQL SECURITY DEFINER VIEW `TABLES` AS select `cat`.`name` AS `TABLE_CATALOG`,`sch`.`name` AS `TABLE_SCHEMA`,`tbl`.`name` AS `TABLE_NAME`,`tbl`.`type` AS `TABLE_TYPE`,if((`tbl`.`type` = 'BASE TABLE'),`tbl`.`engine`,NULL) AS `ENGINE`,if((`tbl`.`type` = 'VIEW'),NULL,10) AS `VERSION`,`tbl`.`row_format` AS `ROW_FORMAT`,internal_table_rows(`sch`.`name`,`tbl`.`name`,if(isnull(`tbl`.`partition_type`),`tbl`.`engine`,''),`tbl`.`se_private_id`,(`tbl`.`hidden` <> 'Visible'),`ts`.`se_private_data`,coalesce(`stat`.`table_rows`,0),coalesce(cast(`stat`.`cached_time` as unsigned),0)) AS `TABLE_ROWS`,internal_avg_row_length(`sch`.`name`,`tbl`.`name`,if(isnull(`tbl`.`partition_type`),`tbl`.`engine`,''),`tbl`.`se_private_id`,(`tbl`.`hidden` <> 'Visible'),`ts`.`se_private_data`,coalesce(`stat`.`avg_row_length`,0),coalesce(cast(`stat`.`cached_time` as unsigned),0)) AS `AVG_ROW_LENGTH`,internal_data_length(`sch`.`name`,`tbl`.`name`,if(isnull(`tbl`.`partition_type`),`tbl`.`engine`,''),`tbl`.`se_private_id`,(`tbl`.`hidden` <> 'Visible'),`ts`.`se_private_data`,coalesce(`stat`.`data_length`,0),coalesce(cast(`stat`.`cached_time` as unsigned),0)) AS `DATA_LENGTH`,internal_max_data_length(`sch`.`name`,`tbl`.`name`,if(isnull(`tbl`.`partition_type`),`tbl`.`engine`,''),`tbl`.`se_private_id`,(`tbl`.`hidden` <> 'Visible'),`ts`.`se_private_data`,coalesce(`stat`.`max_data_length`,0),coalesce(cast(`stat`.`cached_time` as unsigned),0)) AS `MAX_DATA_LENGTH`,internal_index_length(`sch`.`name`,`tbl`.`name`,if(isnull(`tbl`.`partition_type`),`tbl`.`engine`,''),`tbl`.`se_private_id`,(`tbl`.`hidden` <> 'Visible'),`ts`.`se_private_data`,coalesce(`stat`.`index_length`,0),coalesce(cast(`stat`.`cached_time` as unsigned),0)) AS `INDEX_LENGTH`,internal_data_free(`sch`.`name`,`tbl`.`name`,if(isnull(`tbl`.`partition_type`),`tbl`.`engine`,''),`tbl`.`se_private_id`,(`tbl`.`hidden` <> 'Visible'),`ts`.`se_private_data`,coalesce(`stat`.`data_free`,0),coalesce(cast(`stat`.`cached_time` as unsigned),0)) AS `DATA_FREE`,internal_auto_increment(`sch`.`name`,`tbl`.`name`,if(isnull(`tbl`.`partition_type`),`tbl`.`engine`,''),`tbl`.`se_private_id`,(`tbl`.`hidden` <> 'Visible'),`ts`.`se_private_data`,coalesce(`stat`.`auto_increment`,0),coalesce(cast(`stat`.`cached_time` as unsigned),0),`tbl`.`se_private_data`) AS `AUTO_INCREMENT`,`tbl`.`created` AS `CREATE_TIME`,internal_update_time(`sch`.`name`,`tbl`.`name`,if(isnull(`tbl`.`partition_type`),`tbl`.`engine`,''),`tbl`.`se_private_id`,(`tbl`.`hidden` <> 'Visible'),`ts`.`se_private_data`,coalesce(cast(`stat`.`update_time` as unsigned),0),coalesce(cast(`stat`.`cached_time` as unsigned),0)) AS `UPDATE_TIME`,internal_check_time(`sch`.`name`,`tbl`.`name`,if(isnull(`tbl`.`partition_type`),`tbl`.`engine`,''),`tbl`.`se_private_id`,(`tbl`.`hidden` <> 'Visible'),`ts`.`se_private_data`,coalesce(cast(`stat`.`check_time` as unsigned),0),coalesce(cast(`stat`.`cached_time` as unsigned),0)) AS `CHECK_TIME`,`col`.`name` AS `TABLE_COLLATION`,internal_checksum(`sch`.`name`,`tbl`.`name`,if(isnull(`tbl`.`partition_type`),`tbl`.`engine`,''),`tbl`.`se_private_id`,(`tbl`.`hidden` <> 'Visible'),`ts`.`se_private_data`,coalesce(`stat`.`checksum`,0),coalesce(cast(`stat`.`cached_time` as unsigned),0)) AS `CHECKSUM`,if((`tbl`.`type` = 'VIEW'),NULL,get_dd_create_options(`tbl`.`options`,if((ifnull(`tbl`.`partition_expression`,'NOT_PART_TBL') = 'NOT_PART_TBL'),0,1))) AS `CREATE_OPTIONS`,internal_get_comment_or_error(`sch`.`name`,`tbl`.`name`,`tbl`.`type`,`tbl`.`options`,`tbl`.`comment`) AS `TABLE_COMMENT` from (((((`mysql`.`tables` `tbl` join `mysql`.`schemata` `sch` on((`tbl`.`schema_id` = `sch`.`id`))) join `mysql`.`catalogs` `cat` on((`cat`.`id` = `sch`.`catalog_id`))) left join `mysql`.`collations` `col` on((`tbl`.`collation_id` = `col`.`id`))) left join `mysql`.`tablespaces` `ts` on((`tbl`.`tablespace_id` = `ts`.`id`))) left join `mysql`.`table_stats` `stat` on(((`tbl`.`name` = `stat`.`table_name`) and (`sch`.`name` = `stat`.`schema_name`)))) where (can_access_table(`sch`.`name`,`tbl`.`name`) and is_visible_dd_object(`tbl`.`hidden`))
character_set_client: utf8
collation_connection: utf8_general_ci

可以发现tables从原来的memory表变成视图了，auto_increment列引用自mysql.table_stats表的auto_increment列。于是，执行一下analyze，自增值就更新到最新了

analyze table tablename

 

MYSQL——自增主键相关原理
庄小焱
12-05 1627
不管的你在学习什么知识，你就问自己五个问题：这个东西是什么？这个东西怎么用？这个东西可能出现什么问题？为什么会出现这样的问题？你该怎么解决这样问题？如果你能对一件事情做到的这个五个问题。我想你基本上都能够解决很多事情。相信你在未来也能够做出自己的成就。 ...
MySQL 8 自动增长主键的变化
bug_syntax119的博客
09-13 197
在MySQL 8中，自动增长主键（Auto Increment）的实现方式发生了一些变化。除了语法的变化，MySQL 8还引入了一些新的函数来处理自动增长主键。希望本文的内容能够帮助您理解MySQL 8中自动增长主键的变化，并在实际开发中得到应用。总结一下，在MySQL 8中，自动增长主键的定义语法发生了变化，我们可以使用。关键字来定义自动增长主键，但是引入了一种新的语法，即使用默认值为。函数引入了一个新的语法来获取指定列的自动增长主键值。关键字来定义自动增长主键。的表，并定义一个自动增长的主键列。
由一个关于auto_increment的奇怪案例看MySQL8的一些改进优化
灯火觅阑珊
11-22 2194
偶然发现一个比较奇怪的问题，在使用alter table tab auto_increment=N修改表的自增初始值时，information_schema.tables这个表的auto_increment列并没有同步更新： mysql&amp;amp;amp;gt; show create table test.incr_test\g +-----------+-----------------------------...
8.MySQL的自增(AUTO_INCREMENT)
qq_24889005的博客
06-16 1054
8.MySQL的自增（AUTO_INCREMENT）1.为什么需要自增2.语法3.注意4.演示5.查看自动增长值6.修改自动增长7.删除自动增长8.添加自动增长 1.为什么需要自增 为数据表设置主键约束后，每次插入记录时，如果插入的值已经存在，会插入失败。为主键生成自动增长的值可以解决这种问题。 2.语法 字段名 数据类型 AUTO_INCREMENT 3.注意 一张表中只能有一个自动增长字段 该字段的数据类型是整数类型 必须定义为键 为自动增长字段插入NULL、0、DEFAULT或在插入时省略该字段，
MySQL 中主键的 AUTO_INCREMENT 详解
鸟人的博客
03-20 1361
避免手动插入唯一 ID，提升数据管理的效率。，以确保每一行数据都有唯一的标识符。💡 这会使下一个插入的数据。的列，并且通常作为主键。MySQL 允许自定义。在 MySQL 中，
MySQL 自增列解析（Auto_increment）
Vincent的博客
02-29 9295
MySQL数据库为列提供了一种自增属性，当列被定义为自增时。Insert语句对该列即使不提供值，MySQL也会自动为该列生成递增的唯一标识，因此这个特性广泛用于主键的自动生成。
关于自增约束auto_increment需要注意的地方，mysql8版本的报错
weixin_46060711的博客
12-07 4792
关于自增约束auto_increment需要注意的地方，mysql8版本的报错
mysql8 优化_MySQL 8.0 优化
weixin_39758696的博客
01-18 724
优化效果(从大到小)：硬件设备 -> MySQL数据库 -> Linux操作系统 -> 表设计—————————————————————————————————————-1硬件设备优化提升硬件设备，例如使用SSD高速磁盘，CPU等。—————————————————————————————————————-2MySQL数据库配置优化# 物理内存的50%~80%，这里为innodb...
【重学 MySQL】六十五、auto_increment 的使用
优快云全栈领域优秀博主，阿里云博客专家，工信部权威认证物联网技术开发工程师，曾30分钟高分通过C语言二级，两天手撸代码完成EasyX飞机大战，靠接软件私活一个月换苹果电脑
10-13 2230
是一个强大的工具，可以简化主键生成的过程，确保数据的唯一性和一致性。通过合理使用，你可以避免手动管理主键值的麻烦，并专注于数据的其他方面。
MySQL中InnoDB 表的 自增（AUTO_INCREMENT ）列详解
jkzyx123的博客
01-27 1369
MySQL中InnoDB 表的 自增（AUTO_INCREMENT ）列的三种模式
InnoDB的AUTO_INCREMENT处理
yuxxz的专栏
04-23 1698
本文翻译自MySQL官方手册，对InnoDB的AUTO_INCREMENT处理作了介绍。
MySQL8.0以下版本重启后自增主键值丢失问题
theflowerofac^MQLYES的专栏
10-21 1252
上周运维同学重启了UAT环境的MySQL数据库服务，刚开始我是不知道数据库重启了，先是业务服务开始异常，初步定位到的原因是一个表的主键ID出现了回退，又查到MySQL低版本（8.0以下）重启可能会导致自增主键值回退或重置，最后和运维同学确认了下重启时间，确认了原因。正如前文中所说，这种方式复杂且风险很大，MySQL8.0并不完全兼容低版本，升级后这个问题解决了，但可能会导致其他方面的问题，所以生产环境一般是不会同意这样做的。在MySQL8.0中，执行同样的操作，自增值仍为6，没有丢失，这里就不演示啦！
Mysql的AUTO_INCREMENT
Arthur_Lees的博客
08-02 614
什么是AUTO_INCREMENT 本文基于mysql 8.0的内容介绍AUTO_INCREMENT的用途
最全MySQL8.0实战教程 9 MySQL约束 9.3 自增长约束(auto_increment)
谢谢你们的关注
02-18 539
最全MySQL8.0实战教程 9 MySQL约束 9.3 自增长约束(auto_increment)
mysql修改auto_increment不生效
择一城终老，遇一人白首。
05-26 4207
一、mysql8修改AUTO_INCREMENT的值。执行sql如下，“tablename”为数据表名称。二、修改后查询一下auto_increment的值，执行下面sql可查询（结果发现还是修改之前的值）注意：修改的auto_increment的值得大于现有主键的最大值。否则，语句不报错，但不会生效。分析数据表之后，在执行第二步中的查询即可看到auto_increment的值修改成功。重新分析一下数据表即可，执行如下sql。
Mysql之AUTO_INCREMENT浅析
scientificCommunity的博客
02-09 1719
文章目录术语锁模式注意点总结参考链接 AUTO_INCREMENT用于为表中的列设置一个自增序列，在非集群模式下，用它来为主键列自动生成值是一件很方便的事。并且，Mysql提供了一系列的锁机制来保证它的性能跟可靠性，通过这些锁机制，我们可以让它变得很高效。 术语 先来了解后面将要用到的术语。 Simple inserts 能预先知道插入行数的语句。比如说单行插入（不包括[INSERT ... ON DUPLICATE KEY UPDATE](https://dev.mysql.com/doc/refma
mysql8.0版本修复自增列值重复利用情况（修复bug#199）
weixin_34348174的博客
07-13 1210
注意：mysql8.0之前的版本，InnoDB存储引擎的表自增id可能出现重复利用的情况。 这在很多场景下可能导致问题，包括但不限于：主备切换、历史数据迁移等场景。在bug#199下面一大堆的回复里，可以看到大量的同行抱怨。如，假设t1有个历史表t1_history用来存t1表的历史数据，那么mysqld重启前，ti_history表中可能已经有了（2,2）这条数据，而...
MySQL查询和修改auto_increment的方法
一份耕耘 一份收货
08-03 1872
本文实例讲述了MySQL查询和修改auto_increment的方法。分享给大家供大家参考。具体如下： 查询表名为tableName的auto_increment值： 复制代码 代码如下: SELECT AUTO_INCREMENT FROM information_schema.tables WHERE table_name="tableName"; 修改表名为tableName的auto_in
MySQL 8 和 MySQL 5.7 在自增计数上的区别
ActionTech的博客
09-25 410
MySQL 8 之前版本中的 InnoDB 存储引擎报告的自增计数器问题可能会导致困惑和数据不一致，特别是在服务器重启期间。计数器的值可能丢失，导致自动生成的主键值不匹配。MySQL 8 通过保证自增计数器在服务器重启之间持久化来解决这个问题。通过升级到 MySQL 8，开发者可以利用这个功能创建更加坚实的应用程序，可以管理不同的故障情况而不影响数据完整性。
mysql自动删除数据怎么解决
最新发布
03-29
<think>好的，我现在要解决用户的问题：如何防止或修复MySQL中数据被自动删除的问题。首先，我需要理解用户的具体情况。用户提到MySQL自动删除了数据，可能的原因有多种，比如误操作、配置问题、触发器或事件、主键不一致等。根据用户提供的引用内容，有几个关键点需要注意： 首先，引用[1]提到了sql_safe_updates=on时，如果没有WHERE条件或者使用索引字段，删除操作会被阻止。这可能和用户的情况有关，如果用户的数据被自动删除，可能是因为某些操作绕过了安全模式，或者有事件触发了删除。 引用[3]提到主键被占用后即使数据被删除，主键依然不可用，导致主键不连续。这可能和用户的问题关联不大，但需要确认是否有主键问题导致数据异常。 接下来，我需要考虑可能的解决方案。根据常见的MySQL问题，数据被自动删除的可能原因包括： 1. 误操作：用户或管理员不小心执行了DELETE语句。 2. 自动清理机制：如设置了定时任务或事件自动删除数据。 3. 触发器：某个表上的触发器在特定条件下自动删除数据。 4. 配置问题：比如某些配置导致数据被意外清理，比如binlog过期时间过短。 5. 外键约束：ON DELETE CASCADE导致级联删除。 6. 主从同步问题：从库执行了误操作。 针对这些可能性，我需要逐步排查。 首先，检查是否有自动删除的事件或任务。查看MySQL的事件调度器是否启用，并检查相关事件。用户可能需要检查information_schema.events表，查找是否有定时执行的DELETE语句。 其次，检查触发器。查看是否有触发器在特定操作后删除数据，可以使用SHOW TRIGGERS命令。 第三，检查外键约束。如果表之间有外键关系，并且设置了ON DELETE CASCADE，删除父表数据可能导致子表数据被删除。需要检查表结构中的外键设置。 第四，检查binlog和日志，确定删除操作的时间点和具体SQL语句。通过分析binlog或general log，可以找到执行删除的源头。 第五，确认是否启用了安全更新模式。如果sql_safe_updates=on，可能阻止无WHERE的删除，但如果关闭了，可能导致误操作。 根据引用[2]提到的数据恢复方法，如果数据已经被删除，可能需要从备份或binlog中恢复。但用户的问题更多是防止再次发生，所以预防措施更重要。 用户需要采取的步骤可能包括：启用安全模式、检查事件和触发器、审查外键约束、定期备份、监控日志等。同时，设置适当的权限，避免不必要的删除权限，也是重要的。 现在需要将这些思路整理成结构化的回答，分步骤说明原因和解决方法，并引用提供的资料中的相关信息。例如，引用[1]的安全模式设置，引用[3]的主键问题可能不直接相关，但需注意。 最后，生成相关问题，帮助用户进一步理解可能涉及的方面，比如如何恢复数据、如何设置安全模式等。</think>### 解决MySQL数据被自动删除问题的方法 #### 1. **确认数据删除原因** - **检查自动删除事件** 通过查询`information_schema.events`表，检查是否有定时任务自动执行`DELETE`操作： ```sql SELECT EVENT_NAME, EVENT_DEFINITION, INTERVAL_VALUE, INTERVAL_FIELD FROM information_schema.EVENTS WHERE EVENT_DEFINITION LIKE '%DELETE%'; ``` 如果存在相关事件，可通过`DROP EVENT`命令删除。 - **排查触发器** 使用`SHOW TRIGGERS`查看所有触发器，确认是否有触发器在特定操作（如`INSERT`、`UPDATE`）后触发删除： ```sql SHOW TRIGGERS FROM your_database_name; ``` 若存在可疑触发器，使用`DROP TRIGGER`删除。 - **外键约束导致的级联删除** 检查表结构中的外键是否包含`ON DELETE CASCADE`： ```sql SELECT TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME, REFERENCED_TABLE_NAME, REFERENCED_COLUMN_NAME, DELETE_RULE FROM information_schema.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME IS NOT NULL AND DELETE_RULE = 'CASCADE'; ``` 若需禁用级联删除，需修改外键约束为`ON DELETE NO ACTION`。 --- #### 2. **启用安全防护机制** - **开启安全更新模式** 设置`sql_safe_updates=ON`，禁止无`WHERE`条件或未使用索引的`DELETE`/`UPDATE`操作[^1]： ```sql SET sql_safe_updates = 1; ``` 在配置文件`my.cnf`中添加以下配置以永久生效： ```ini [mysqld] sql_safe_updates = ON ``` - **限制用户权限** 为应用程序账户分配最小权限，避免授予全局`DELETE`权限： ```sql GRANT SELECT, INSERT, UPDATE ON your_database.* TO 'app_user'@'%'; ``` --- #### 3. **数据恢复与备份** - **从备份恢复数据** 若有定期备份（如通过`mysqldump`或物理备份工具），直接还原备份文件： ```bash mysql -u root -p your_database < backup.sql ``` - **通过Binlog恢复** 若未备份但开启了二进制日志，可通过`mysqlbinlog`工具解析并重放日志： ```bash mysqlbinlog --start-datetime="2024-01-01 00:00:00" --stop-datetime="2024-01-02 00:00:00" mysql-bin.000001 | mysql -u root -p ``` 需根据删除操作发生时间定位具体日志文件[^2]。 --- #### 4. **监控与日志分析** - **启用General Log** 临时开启通用查询日志，记录所有SQL语句： ```sql SET GLOBAL general_log = 'ON'; SET GLOBAL log_output = 'TABLE'; ``` 分析`mysql.general_log`表，查找可疑的`DELETE`语句。 - **审计插件（Enterprise版）** 若使用MySQL企业版，可通过审计插件记录高危操作。 --- #### 5. **避免主键冲突导致的数据异常** 若因主键不连续导致数据插入异常（如自增主键跳跃），可重置自增值： ```sql ALTER TABLE your_table AUTO_INCREMENT = 1; ``` 但需注意这可能与现有数据冲突[^3]。 ---
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值