MySQL 主从 AUTO_INCREMENT 不一致问题分析

本文介绍了 MySQL5.7 中常见的replace into 操作造成的主从auto_increment不一致现象，一旦触发了主从切换，业务的正常插入操作会触发主键冲突的报错提示。

一、问题描述

1.1 问题现象

在 MySQL 5.7 版本中，REPLACE INTO 操作在表存在自增主键的情况下，可能会出现表的auto_increment值主从不一致现象，如果在此期间发生主从故障切换，当原来的slave节点变成了新的master节点，由于表的auto_increment值是小于原主库的，当业务继续写入时，就会收到主键冲突的报错提示。

相关报错信息如下：

! 报错提示

ERROR 1062 (23000): Duplicate entry 'XXX' for key 'PRIMARY'

1.2 影响评估

在业务逻辑中使用了Replace into,或者INSERT...ON DUPLICATE KEY UPDATE。

一旦出现了表的auto_increment值主从不一致现象，在出现MySQL主从故障切换后，业务的正常写入会报主键冲突的错误，当auto_increment相差不多，或许在业务重试的时候会跳过报错，但是auto_increment相差较多时，会超出业务重试的次数，这样造成的影响会更大。

二、问题复现

2.1 环境搭建

这里在测试环境中，搭建MySQL社区版 5.7 版本，一主一从的架构。

【OS】：CentOS Linux release 7.3

【MySQL】：社区版本 5.7

【主从架构】：一主一从

【库表信息】：库名：test2023

 表名：test_autoincrement

表结构如下：

CREATE TABLE `test_autoincrement` (`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增主键',`name` varchar(100) NOT NULL DEFAULT 'test' COMMENT '测试名字',`uid` int(11) NOT NULL COMMENT '测试表唯一键',PRIMARY KEY (`id`),UNIQUE KEY `uid` (`uid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

2.2 准备测试数据

MySQL [test2023]> insert into test_autoincrement(name,uid) select '张三',1001;
Query OK, 1 row affected (0.08 sec)
Records: 1  Duplicates: 0  Warnings: 0MySQL [test2023]> insert into test_autoincrement(name,uid) select '李四',1002;
Query OK, 1 row affected (0.06 sec)
Records: 1  Duplicates: 0  Warnings: 0MySQL [test2023]>
MySQL [test2023]> insert into test_autoincrement(name,uid) select '王五',1003;
Query OK, 1 row affected (0.08 sec)
Records: 1  Duplicates: 0  Warnings: 0

正常情况下，插入一行数据，影响的行数是1。

此时查看主从节点表的autoincrement值，可以看到此时主从的AUTO_INCREMENT是一致的，都是4，即自增主键下一次申请的值是4。

图片

2.3 问题复现模拟

2.3.1 模拟REPLACE INTO操作

MySQL [test2023]> REPLACE INTO test_autoincrement (name,uid) values('张三丰',1001);
Query OK, 2 rows affected (0.01 sec)

这里通过REPLACE INTO操作判断，如果存在唯一ID为1001的记录，那么将name字段的值更改为"张三丰",可发现此时影响的行数是2。现在我们再次查看主从节点表的autoincrement值。

图片

此时出现了主从节点表的AUTO_INCREMENT不一致现象。

2.3.2 模拟主从切换

由于是在测试环境，这里就直接进行了主从关系的更改。

（1）停止当前slave节点的复制线程

MySQL [test2023]> stop slave;
Query OK, 0 rows affected (0.08 sec)

（2）查看当前slave节点的Executed_Gtid_Set值

MySQL [test2023]> show master status\G
*************************** 1. row ***************************File: binlog.000002Position: 4317Binlog_Do_DB:Binlog_Ignore_DB:
Executed_Gtid_Set: 9cc90407-ff89-11ed-8b7a-fa163e2d11e1:1-82,
a0c1d6ff-5764-11ee-94ea-fa163e2d11e1:1-11
1 row in set (0.01 sec)

（3）重做主从关系

MySQL [test2023]> CHANGE MASTER TO MASTER_HOST = '原slave节点的IP地址', MASTER_USER = '复制账户', MASTER_PASSWORD = '密码', MASTER_PORT = 端口, MASTER_AUTO_POSITION = 1 ;
Query OK, 0 rows affected, 2 warnings (0.21 sec)MySQL [test2023]> start slave;
Query OK, 0 rows affected (0.05 sec)
MySQL [test2023]> show slave status\G
*************************** 1. row ***************************Slave_IO_State: Waiting for master to send eventMaster_Host: XXXMaster_User: XXXMaster_Port: XXXConnect_Retry: 60Master_Log_File: binlog.000002Read_Master_Log_Pos: 4317Relay_Log_File: relay.000004Relay_Log_Pos: 445Relay_Master_Log_File: binlog.000002Slave_IO_Running: YesSlave_SQL_Running: YesReplicate_Do_DB:Replicate_Ignore_DB:Replicate_Do_Table:Replicate_Ignore_Table:Replicate_Wild_Do_Table:Replicate_Wild_Ignore_Table:Last_Errno: 0Last_Error:Skip_Counter: 0Exec_Master_Log_Pos: 4317Relay_Log_Space: 726Until_Condition: NoneUntil_Log_File:Until_Log_Pos: 0Master_SSL_Allowed: NoMaster_SSL_CA_File:Master_SSL_CA_Path:Master_SSL_Cert:Master_SSL_Cipher:Master_SSL_Key:Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: NoLast_IO_Errno: 0Last_IO_Error:Last_SQL_Errno: 0Last_SQL_Error:Replicate_Ignore_Server_Ids:Master_Server_Id: 461470011Master_UUID: a0c1d6ff-5764-11ee-94ea-fa163e2d11e1Master_Info_File: mysql.slave_master_infoSQL_Delay: 0SQL_Remaining_Delay: NULLSlave_SQL_Running_State: Slave has read all relay log; waiting for more updatesMaster_Retry_Count: 86400Master_Bind:Last_IO_Error_Timestamp:Last_SQL_Error_Timestamp:Master_SSL_Crl:Master_SSL_Crlpath:Retrieved_Gtid_Set: a0c1d6ff-5764-11ee-94ea-fa163e2d11e1:11Executed_Gtid_Set: 9cc90407-ff89-11ed-8b7a-fa163e2d11e1:1-82,
a0c1d6ff-5764-11ee-94ea-fa163e2d11e1:1-11Auto_Position: 1Replicate_Rewrite_DB:Channel_Name:Master_TLS_Version:
1 row in set (0.00 sec)

2.3.3 模拟业务正常写入

MySQL [test2023]> insert into test_autoincrement(name,uid) select '赵六',1004;
ERROR 1062 (23000): Duplicate entry '4' for key 'PRIMARY'

到这里我们看到了预期的报错现象，如果是正常业务系统，这里的主从节点表的AUTO_INCREMENT可能会相差非常大，业务的正常插入就会持续报错了。

意味着真实的操作是先做delete操作，然后再进行insert。

三、原因分析

3.1 为什么从库节点的 autoincrement 没有变化？

# at 10790
#230927 16:23:45 server id 46147000  end_log_pos 10863 CRC32 0x85c60fb7         Update_rows: table id 122 flags: STMT_END_FBINLOG '
keYTZRO4JcACRQAAACYqAAAAAHoAAAAAAAEACHRlc3QyMDIzABJ0ZXN0X2F1dG9pbmNyZW1lbnQA
AwMPAwKQAQCCO6qB
keYTZR+4JcACSQAAAG8qAAAAAHoAAAAAAAEAAgAD///4AQAAAAYA5byg5LiJ6QMAAPgEAAAACQDl
vKDkuInkuLDpAwAAtw/GhQ==
'/*!*/;
### UPDATE `test2023`.`test_autoincrement`
### WHERE
###   @1=1 /* INT meta=0 nullable=0 is_null=0 */
###   @2='张三' /* VARSTRING(400) meta=400 nullable=0 is_null=0 */
###   @3=1001 /* INT meta=0 nullable=0 is_null=0 */
### SET
###   @1=4 /* INT meta=0 nullable=0 is_null=0 */
###   @2='张三丰' /* VARSTRING(400) meta=400 nullable=0 is_null=0 */
###   @3=1001 /* INT meta=0 nullable=0 is_null=0 */
# at 10863
#230927 16:23:45 server id 46147000  end_log_pos 10894 CRC32 0xe204d99b         Xid = 331
COMMIT/*!*/;

这里可以看到REPLACE INTO操作对应的binlog日志记录其实是update操作，从库节点在应用update操作时，发现命中数据时，对应的autoincrement是没有变化的。

3.2 REPLACE INTO 操作的官方定义是什么？

官方对于 REPLACE INTO 的定义如下：

摘选自MySQL :: MySQL 5.7 Reference Manual :: 13.2.8 REPLACE Statement

REPLACE works exactly like INSERT, except that if an old row in the table has the same value as a new row for a PRIMARY KEY or a UNIQUE index, the old row is deleted before the new row is inserted. See Section 13.2.5, “INSERT Statement”.

REPLACE is a MySQL extension to the SQL standard. It either inserts, or deletes and inserts. For another MySQL extension to standard SQL—that either inserts or updates—see Section 13.2.5.2, “INSERT ... ON DUPLICATE KEY UPDATE Statement”.

这里可以看到一张表包含主键或者唯一键的情况下，replace操作会判断原有的数据行是否存在，如果存在的话，就先删除旧的数据，然后进行insert操作，如果不存在的话，就和insert操作时一样的。

第二段也提到了INSERT ... ON DUPLICATE KEY UPDATE Statement ，其实这个操作也会造成上面的主从autoincrement不一致现象，这里就不展开讨论了。

! Note

REPLACE makes sense only if a table has a PRIMARY KEY or UNIQUE index. Otherwise, it becomes equivalent to INSERT, because there is no index to be used to determine whether a new row duplicates another.

3.3  为什么REPLACE INTO操作在binlog日志中记录的是update操作？

这里我们通过源码文件sql_insert.cc和log_event.cc进行分析。

sql_insert.cc:
...
/* Check if there is more uniq keys after field */static int last_uniq_key(TABLE *table,uint keynr)
{/*When an underlying storage engine informs that the unique keyconflicts are not reported in the ascending order by settingthe HA_DUPLICATE_KEY_NOT_IN_ORDER flag, we cannot rely on thisinformation to determine the last key conflict.The information about the last key conflict will be used todo a replace of the new row on the conflicting row, ratherthan doing a delete (of old row) + insert (of new row).Hence check for this flag and disable replacing the last rowby returning 0 always. Returning 0 will result in doinga delete + insert always.*/if (table->file->ha_table_flags() & HA_DUPLICATE_KEY_NOT_IN_ORDER){return 0;}while (++keynr < table->s->keys){if (table->key_info[keynr].flags & HA_NOSAME){return 0;}}return 1;
}
.../*The manual defines the REPLACE semantics that it is eitheran INSERT or DELETE(s) + INSERT; FOREIGN KEY checks inInnoDB do not function in the defined way if we allow MySQLto convert the latter operation internally to an UPDATE.We also should not perform this conversion if we havetimestamp field with ON UPDATE which is different from DEFAULT.Another case when conversion should not be performed is whenwe have ON DELETE trigger on table so user may notice thatwe cheat here. Note that it is ok to do such conversion fortables which have ON UPDATE but have no ON DELETE triggers,we just should not expose this fact to users by invokingON UPDATE triggers.*/if (last_uniq_key(table,key_nr) &&!table->file->referenced_by_foreign_key() &&(!table->triggers || !table->triggers->has_delete_triggers())){if ((error=table->file->ha_update_row(table->record[1],table->record[0])) &&error != HA_ERR_RECORD_IS_THE_SAME)goto err;if (error != HA_ERR_RECORD_IS_THE_SAME)info->stats.deleted++;elseerror= 0;thd->record_first_successful_insert_id_in_cur_stmt(table->file->insert_id_for_cur_row);/*Since we pretend that we have done insert we should callits after triggers.*/goto after_trg_n_copied_inc;}else{
...}
...

上述源码中可以看到在主库中replace 操作其实是insert 或者 delete + insert 

The manual defines the REPLACE semantics that it is either an INSERT or DELETE(s) + INSERT;

而 MySQL 在主从同步的binlog日志中，将replace操作转换为update操作的条件为：当发生冲突的键是最后一个唯一键，且没有外键约束，且没有触发器，由于我们的测试表中是没有外键约束，也没有触发器的，所以从库接收到的binlog日志中转化为update的条件即为最后一个唯一键。

这里，我们再进行测试一下（去掉表中的唯一索引uid）。

（1）创建新表

CREATE TABLE `test_autoincrement_2` (`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增主键',`name` varchar(100) NOT NULL DEFAULT 'test' COMMENT '测试名字',PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4

（2）插入测试数据

insert into test_autoincrement_2(name) select '孙七';insert into test_autoincrement_2(name) select '周八';insert into test_autoincrement_2(name) select '吴九';#此时主从表结构是一致的，如下：CREATE TABLE `test_autoincrement_2` (`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增主键',`name` varchar(100) NOT NULL DEFAULT 'test' COMMENT '测试名字',PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4

（3）replace into 操作验证主库和从库的AUTO_INCREMENT

MySQL [test2023]> REPLACE INTO test_autoincrement_2 (id,name) values(3,'郑十');
Query OK, 2 rows affected (0.08 sec)

这里我们把id=3的这一行数据对应的name修改为’郑十’，可发现上述影响的行数是2。

再次验证主库和从库的AUTO_INCREMENT，发现并没有发生变化，还是4。

CREATE TABLE `test_autoincrement_2` (`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增主键',`name` varchar(100) NOT NULL DEFAULT 'test' COMMENT '测试名字',PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4

（4）分析binlog日志文件

# at 8089
#230928 15:52:08 server id 461470011  end_log_pos 8151 CRC32 0xc2ff85bb         Update_rows: table id 481 flags: STMT_END_FBINLOG '
qDAVZRM7eYEbRgAAAJkfAAAAAOEBAAAAAAEACHRlc3QyMDIzABR0ZXN0X2F1dG9pbmNyZW1lbnRf
MgACAw8CkAEAFSqQxg==
qDAVZR87eYEbPgAAANcfAAAAAOEBAAAAAAEAAgAC///8AwAAAAYA5ZC05Lmd/AMAAAAGAOmDkeWN
gbuF/8I=
'/*!*/;
### UPDATE `test2023`.`test_autoincrement_2`
### WHERE
###   @1=3 /* INT meta=0 nullable=0 is_null=0 */
###   @2='吴九' /* VARSTRING(400) meta=400 nullable=0 is_null=0 */
### SET
###   @1=3 /* INT meta=0 nullable=0 is_null=0 */
###   @2='郑十' /* VARSTRING(400) meta=400 nullable=0 is_null=0 */
# at 8151
#230928 15:52:08 server id 461470011  end_log_pos 8182 CRC32 0xaa39d2a4         Xid = 699
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

总结：可发现binlog日志记录的同样是update 操作。只是当表中除了主键外没有额外的唯一键时，replace into的操作并不会触发从库的auto_increment的异常问题。比如上述的案例REPLACE INTO test_autoincrement_2 (id,name) values(3,'郑十');，这里仅更改了name字段，由‘吴九‘修改为’郑十’。但是主键id是没有变化的，当然也就不需要再次使用auto_increment，这里也可以看到主库的auto_increment当然也没有发现变化（当表中除了主键外含有额外的唯一键时，是会触发申请auto_increment的），binlog接收的仍然是update操作，所以从库的auto_increment也是没有变化的，这样就没法造成auto_increment和主库不一致的问题了。

四、解决方案

到这里，我们是明白了replace into 会造成主从的auto_increment 不一致，但是怎么去解决呢？

4.1 升级到 MySQL 8.0 版本

在 MySQL 8.0 版本中已将AUTO_INCREMENT值做了持久化，且在做更新操作时，会将表上的自增列被更新为比auto_increment更大的值，auto_increment值也将被更新。

4.2 修改 AUTO_INCREMENT 值

线上环境可能已经有很多这种情况，在没有触发业务报错的情况下，一般是很难发现这个隐患，如何在日常巡检中找到这些问题才是关键。

巡检逻辑一：这里可以通过巡检判断从库的max(id) >= AUTO_INCREMENT的方式来找出已经存在问题的表信息。然后通过SQL语句：ALTER TABLE table_name AUTO_INCREMENT = new_value;  进行修改。

巡检步骤可参考：

（1）仅检测某从节点，包含auto_increment 属性的表，过滤SQL如下：

select TABLE_SCHEMA,TABLE_NAME,AUTO_INCREMENT from information_schema.tables where table_schema not in ('information_schema','mysql','performance_schema','sys') AUTO_INCREMENTis not null \G

（2）加锁后读表信息，语句如下：

① 给表加锁

lock tables table_name write;

②读取数据和表auto_increment值进行比对

MAXID=select max(id) from table_name;
AUTO_INCREMENT=select AUTO_INCREMENT from information_schema.tables where TABLE_NAME='t1' ;

③ 判断条件

如果MAXID >= AUTO_INCREMENT , 判断为异常

巡检逻辑二：可以在高可用切换的时候增加AUTO_INCREMENT值判断，如果AUTO_INCREMENT值不一致，则不发生切换，不过这里的slave节点AUTO_INCREMENT的值本身可能因为延迟等问题，就会稍落后maste主节点，正常的巡检还是有难度的，还有就是当MySQL主从切换触发时，如果是因为原主库宕机了，不触发切换也会有问题，所以还是需要提前尽快把这个隐患排除掉。

4.3 禁用 replace into 操作

业务侧禁用replace into 或 insert ... on duplicate  key update ,实现方式可以通过代码逻辑来实现。

4.4 replace into操作的表不增加其他唯一索引

这里其实实现还是有难度的，自增id是不可控的，业务一般是不会使用数据库自带的自增id。

五、问题总结

1. REPLACE INTO 操作在表存在自增主键且包含唯一索引的情况下，当出现数据冲突的时候，会触发AUTO_INCREMENT在主从节点的不一致，一旦主从发生切换，就会造成业务的写入报主键冲突的错误。解决建议：业务更改实现方式，避免使用replace into，或者使用MySQL8.0 及以上的版本来解决该问题。

2. 该问题是一个官方的BUG，不过并没有在MySQL5.7的版本中得到修复 。

文章转载自：vivo互联网技术

原文链接：https://www.cnblogs.com/vivotech/p/18118665

体验地址：引迈 - JNPF快速开发平台_低代码开发平台_零代码开发平台_流程设计器_表单引擎_工作流引擎_软件架构

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.hqwc.cn/news/600794.html

如若内容造成侵权/违法违规/事实不符，请联系编程知识网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

基于javassm实现的旅游景点线路网站

基于javassm实现的旅游景点线路网站

开发语言&#xff1a;Java 框架&#xff1a;ssm 技术&#xff1a;JSP JDK版本&#xff1a;JDK1.8 服务器&#xff1a;tomcat7 数据库&#xff1a;mysql 5.7 数据库工具&#xff1a;Navicat11 开发软件&#xff1a;eclipse/myeclipse/idea Maven包&#xff1a;Maven3.3.…
阅读更多...
【CVE复现计划】CVE-2024-0195

【CVE复现计划】CVE-2024-0195

CVE-2024-0195 简介&#xff1a; SpiderFlow是新一代开源爬虫平台&#xff0c;以图形化方式定义爬虫流程&#xff0c;不写代码即可完成爬虫。基于springbootlayui开发的前后端不分离,也可以进行二次开发。该系统/function/save接口存在RCE漏洞&#xff0c;攻击者可以构造恶意命…
阅读更多...
【大功率汽车大灯升压方案】LED恒流驱动芯片FP7208升压车灯调光应用，PWM内部转模拟，调光深度1%，无频闪顾虑，低亮无抖动

【大功率汽车大灯升压方案】LED恒流驱动芯片FP7208升压车灯调光应用，PWM内部转模拟，调光深度1%，无频闪顾虑，低亮无抖动

宝马X5前中排座椅宽大舒适&#xff0c;车厢内储物空间丰富。操控性能极佳&#xff0c;底盘稳扎精良。原车为氙气灯&#xff0c;其实宝马的氙气大灯配的比其他车型要好&#xff0c;照明效果是没得说的。但是不管什么灯久了都会出现光衰的情况。下面这辆宝马X5车灯已老化严重。 宝…
阅读更多...
Jmeter ServerAgent windows启动报错 NoClassDefFoundError

Jmeter ServerAgent windows启动报错 NoClassDefFoundError

下载ServerAgent-2.2.3 后执行startAgent.bat 报错如下&#xff1a; 尝试解决方案一&#xff1a; 将整个ServerAgent-2.2.3文件夹复制到jdk目录下的bin目录下&#xff0c;然后重新进入目录执行startAgent.bat
阅读更多...
MySQL如何创建存储过程

MySQL如何创建存储过程

工作中有时候需要自己去创建存储过程&#xff0c;然后调用存储去获得一些数据等&#xff0c;接下来就给大家介绍下MySQL如何创建存储过程。 语法&#xff1a; CREATE PROCEDURE 存储程名([[IN|OUT|INOUT] 参数名 数据类型[,[IN|OUT|INOUT] 参数名 数据类型…]]) [特性 …] 过…
阅读更多...
python 如何生成uuid

python 如何生成uuid

UUID&#xff08;Universally Unique Identifier&#xff09;是通用唯一识别码&#xff0c;在许多领域用作标识&#xff0c;比如我们常用的数据库也可以用它来作为主键&#xff0c;原理上它是可以对任何东西进行唯一的编码的。作为新手一看到类似varchar(40)这样的主键就觉得有…
阅读更多...
西圣、漫步者、万魔开放式耳机怎么样？无广真实测评对比推荐

西圣、漫步者、万魔开放式耳机怎么样？无广真实测评对比推荐

开放式耳机因其独特的音质体验和佩戴舒适度&#xff0c;受到了越来越多消费者的青睐。西圣、漫步者、万魔作为国内知名的耳机品牌&#xff0c;各自都推出了自家的开放式耳机产品&#xff0c;那么&#xff0c;这三款耳机究竟如何呢&#xff1f;身为开放式耳机党的我&#xff0c;…
阅读更多...
python开发poc2，爆破脚本

python开发poc2，爆破脚本

#本课知识点和目的&#xff1a; ---协议模块使用&#xff0c;Request 爬虫技术&#xff0c;简易多线程技术&#xff0c;编码技术&#xff0c;Bypass 后门技术 下载ftp服务器模拟器 https://lcba.lanzouy.com/iAMePxl378h 随便创建一个账户&#xff0c;然后登录进去把ip改成…
阅读更多...
RuleEngine规则引擎底层改造AviatorScript 之函数执行

RuleEngine规则引擎底层改造AviatorScript 之函数执行

https://gitee.com/aizuda/rule-engine-open 需求&#xff1a;使用上述开源框架进行改造&#xff0c;底层更换成AviatorScript &#xff0c;函数实现改造。 原本实现方式 Overridepublic Object run(ExecuteFunctionRequest executeTestRequest) {Integer functionId executeT…
阅读更多...
谷歌关键词优化seo需要怎么做？

谷歌关键词优化seo需要怎么做？

如果你想要提升你的网站在谷歌搜索中的排名&#xff0c;我们的指定关键词SEO套餐能够提供你需要的一切 我们会对你的网站进行彻底的技术审查&#xff0c;确保它的加载速度、代码结构、URL布局等都符合谷歌的规范&#xff0c;这是基础&#xff0c;但非常重要&#xff0c;因为一个…
阅读更多...
C语言——顺序表

C语言——顺序表

文章目录 一、线性表二、顺序表顺序表和数组的区别顺序表的分类1.静态顺序表2.动态顺序表 三、动态顺序表的实现1.动态顺序表头文件2.动态顺序表源文件3.测试源文件 一、线性表 线性表&#xff08;linear list&#xff09;是n个具有相同特性的数据元素的有限序列。线性表是⼀种…
阅读更多...
Unity类银河恶魔城学习记录12-4 p126 Item Tooltip源代码

Unity类银河恶魔城学习记录12-4 p126 Item Tooltip源代码

Alex教程每一P的教程原代码加上我自己的理解初步理解写的注释&#xff0c;可供学习Alex教程的人参考 此代码仅为较上一P有所改变的代码 【Unity教程】从0编程制作类银河恶魔城游戏_哔哩哔哩_bilibili UI.cs using System.Collections; using System.Collections.Generic; usi…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023