将两个数据库组成主从模式的集群，正常情况下，是可以解决数据库的可靠性问题，但如果主库挂掉后，数据没有及时同步到从库，这个时候就会出现 ID 重复的问题。
因为MySQL中的自增字段与Oracle数据库是不一样的，所以在这里记录一下MySQL的自增字段。
ID是数据的唯一标识，传统的做法是利用UUID和数据库的自增ID，在互联网企业中，大部分公司使用的都是Mysql，并且因为需要事务支持，所以通常会使用Innodb存储引擎，UUID太长以及无序，所以并不适合在Innodb中来作为主键，自增ID比较合适，但是随着公司的业务发展，数据量将越来越大，需要对数据进行分表，而分表后，每个表中的数据都会按自己的节奏进行自增，很有可能出现ID冲突。这时就需要一个单独的机制来负责生成唯一ID，生成出来的ID也可以叫做分布式ID，或全局ID。下面来分析各个生成分布式ID的机制。
A表带自增键，B表不带，通过程序从A表同步数据到B表,同步完成后会通过delete删除A表数据，今天插入B表会出现duplicate primary key问题。
单主模式：只有一个成员对外提供服务。单主模式和异步模式比较类似，有了主从复制的经验，维护单主模式的MGR其实并不难，下面的图说明了单主模式下的一些特点：
需求： 已有的mysql数据表，希望增加一个自增的字段，并设置新数据的初始值。 实际上不复杂，只是做个备忘。 测试表 CREATE TABLE `t_abc` ( `name` varchar(20) DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 测试数据： INSERT INTO `t_abc` (`name`) VALUES ('mike'), ('tom'), ('jack'); 添加自增字段并设置新数据的起始值 /*增加一个自增主键
业务量小于500W或数据容量小于2G的时候单独一个mysql即可提供服务，再大点的时候就进行读写分离也可以应付过来。但当主从同步也扛不住的时候就需要分表分库了，但分库分表后需要有一个唯一ID来标识一条数据，且这个唯一ID还必须有规则，能辅助我们解决分库分表的一些问题。
松哥最近工作中刚好用到这块内容，于是调研了市面上几种常见的全局 ID 生成策略，稍微做了一下对比，供小伙伴们参考。
通常，我们都会在数据库表中设置一个自增字段作为主键，该字段的值会随着添加新记录而自增。 同时也必须注意，这个自增字段的值只会一直增加，即使把记录删除了，该自增字段的值也不会变小。 因此，就会产生一个现象：假如某些记录被物理删除了，那么表中记录的这个自增字段值就不是连续的。 即：通过某个自增值去查询的时候表里并不存在该记录。
此配置是我在使用过程中总结出比较实用的配置参数，基于GTID的主从复制场景中使用：
先从 MySQL 对数据库复制的能力看，MySQL 支持单向、异步的复制。复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护日志文件的一个索引以跟踪日志循环。当一个从服务器连接到主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知下一次更新。
在实际测试工作过程中，有时因为生产环境已有历史数据原因，需要测试环境数据id从某个值开始递增，此时，我们需要修改数据库中自增ID起始值，下面以MySQL为例：
表的主键指的针对一张表中的一列或者多列，其结果必须能标识表中每行记录的唯一性。InnoDB 表是索引组织表，主键既是数据也是索引。
今天搭建了一套双主复制的架构，这种架构包含两台服务器，每一台都被配置成对方的主库和备库，是一种特殊的主从，架构图如下：
通过SET auto_increment_increment=3，标识列可以设置步长。
在MySQL数据库中，主键自增是一种常见的技术，用于自动为表中的主键字段生成唯一的递增值。本文将深入讨论MySQL主键自增的原理、用途、使用方法，以及在实践中的注意事项和最佳实践。
在 MySQL 中，DATABASE 和 SCHEMA 在语法上是等效的，它们都用于创建数据库。在其他 RDBMS（如 Oracle 和 SQL Server）
假设我们在数据库中使用自增id连续插入两条数据，生成的id分别是1和2，这个时候我把id为2的删除掉，这个时候我再插入一条数据，生成的id为3
MySQL DELETE语句和TRUNCATE TABLE语句功能相似，但是二者究竟有何区别呢？下文就将为您分析MySQL DELETE语句和TRUNCATE TABLE语句的区别，供您参考。 在MySQL中 有两种方法可以删除数据，一种是MySQL DELETE语句，另一种是MySQL TRUNCATE TABLE语句。DELETE语句可以通过WHERE对要删除的记录进行选择。而使用TRUNCATE TABLE将删除表中的所有记录。因此，DELETE语句更灵活。 如果要清空表中的所有记录，可以使用下面
（MySQL官网下载地址：http://dev.mysql.com/downloads/mysql/）
例如当前表中有ID为1,2,3三条记录，把3删除，重启MySQL，新插入记录的ID从哪儿开始？
前两天粉丝给我留言吐槽最近面试：“四哥，年前我在公司受点委屈一冲动就裸辞了，然后现在疫情严重两个多月还没找到工作，接了几个视频面试也都没下文。好多面试官问完一个问题，紧接着说还会其他解决方法吗？能干活解决bug不就行了吗？那还得会多少种方法？”
业务量小于500W或数据容量小于2G的时候单独一个mysql即可提供服务，再大点的时候就进行读写分离也可以应付过来。但当主从同步也扛不住的是就需要分表分库了，但分库分表后需要有一个唯一ID来标识一条数据，数据库的自增ID显然不能满足需求；特别一点的如订单、优惠券也都需要有唯一ID做标识。此时一个能够生成全局唯一ID的系统是非常必要的。那么这个全局唯一ID就叫分布式ID。
前两天公众号有个粉丝给我留言吐槽最近面试：“四哥，年前我在公司受点委屈一冲动就裸辞了，然后现在疫情严重两个多月还没找到工作，接了几个视频面试也都没下文。好多面试官问完一个问题，紧接着说还会其他解决方法吗？能干活解决bug不就行了吗？那还得会多少种方法？”
分布式系统全局唯一的 id 是所有系统都会遇到的场景，往往会被用在搜索，存储方面，用于作为唯一的标识或者排序，比如全局唯一的订单号，优惠券的券码等，如果出现两个相同的订单号，对于用户无疑将是一个巨大的bug。
在EDI术语中，ICN# 的全称为Interchange Control Number，是文件的发送方分配的唯一标识符，可以识别每一个文件。
tokudb引擎的一个大表tb1，存放业务上的机审日志，每天有大量的写入， 并且由于历史原因，这张表是int signed 类型的，最大只能存 2147483647行记录 。
A上同步到B,B上写,就会报duplicate,这还比较好,至少两边数据还是一致的
在说分布式ID的具体实现之前，我们来简单分析一下为什么用分布式ID？分布式ID应该满足哪些特征？
https://cloud.tencent.com/document/product/215/20186
真正约束字段的是数据类型，但是数据类型约束很单一，需要有一些额外的约束，更好的保证数据的合法性，从业务逻辑角度保证数据的正确性。比如有一个字段是email，要求是唯一的。表中一定要有各种约束，通过约束，让我们未来插入数据库表中的数据是符合预期的。约束的本质是通过技术收到逼迫程序员插入正确的数据，反过来，站在mysql的视角，凡是插入进来的数据，都是符合数据约束的。约束的最终目标：保证数据的完整性和可预期性所以需要更多的约束。 表的约束很多，这里主要介绍如下几个： null/not null,default, comment, zerofill，primarykey，auto_increment，unique key 。
MySQL多主复制是一种常见的高可用性解决方案，它可以实现数据的分散和负载均衡，提高系统的可扩展性和可用性。下面是一个简要的MySQL多主复制部署文档，包括几个主要步骤。
为什么要设置自增主键 id ？ PRIMARY KEY (id) 可以唯一标识一行数据，在 InnoDB 构建索引树的时候会使用主键。 自增 id 是顺序的，可以保证索引树上的数据比较紧凑，有更高的空间利用率以及减少数据页的分裂合并等操作，提高效率。(数字顺序搜索快一点) 一般使用手机号、身份证号作为主键等并不能保证顺序性。 流水号一般相对较长，比如 28 位，32 位等，过长的话会二级索引占用空间较多。同时为了业务需求，流水号具有一定的随机性。 int(11)是什么意思？ “int(11)中,11代表的并不是长度,而是字符的显示宽度 为什么id不能为空NOT NULL？ 如果查询中包含可为 NULL 的列，对 MySQL 来说更难优化 ，因为可为 NULL 的列使 得索引、索引统计和值比较都更复杂 。可为NULL 的列会使用更多的存储空间 ，在 MySQL 里也需要特殊处理 。当可为NULL 的列被索引肘，每个索引记录需要一个额 外的字节，在 MyISAM 里甚至还可能导致固定大小 的索引 （例如只有一个整数列的 索引） 变成可变大小的索引。(为null是占用存储空间的。为空不占用存储空间哦)
在数据库中对表中的数据进行限制，保证数据的正确性、有效性和完整性。一个表如果添加了约束，不正确的数据将无法插入到表中。约束在创建表的时候添加比较合适。
外键用来在两个表之间建立链接，它可以是一列或多列，一个表可以有一个或多个外键。
最近有个需要，国内和国外分别开了两台mysql数据库，要求是数据实时同步，不管那边访问，数据都是一样的。 其实好几年前，做过一次MySQL的主主同步，都已经忘记怎么做了。这次做完，顺便记录一下。
3.设置一个布尔变量 from，初始值为 true，用于判断当前是奇数行还是偶数行。
我们接着上一个文档继续做！由于还要用到上面装的mysql数据库，在这个进行一些配置
MySQL的自增锁是指在使用自增主键（Auto Increment）时，为了保证唯一性和正确性，系统会对自增字段进行加锁。这样可以确保同时插入多条记录时，每条记录都能够获得唯一的自增值。
前言 MMM(Master-Master replication managerfor Mysql，Mysql主主复制管理器)是一套灵活的脚本程序，基于perl实现，用来对mysql replication进行监控和故障迁移，并能管理mysql Master-Master复制的配置(同一时间只有一个节点是可写的)。 MMM 优缺点 优点：高可用性，扩展性好，出现故障自动切换，对于主主同步，在同一时间只提供一台数据库写操作，保证的数据的一致性。 缺点：Monitor节点是单点，可以结合Keepalived实现
这里把自己学的mysql数据库的知识总结一下，当是给自己复习一遍，也是方便以后查询
墨墨导读：为了达到标识的目的，许多应用程序需要生成唯一编号，比如：商品编号、交易流水号等。MySQL数据库同样能够支持这样的需求场景，AUTO_INCREMENT就是为MySQL实现序列的方式，它会自动生成序列编号。
这么温柔可爱的面试官，应该不会为难我吧。嗯，应该是的，毕竟我这么帅气，面试可能就是走个过场。美女面试官是不是单身？毕竟程序员都不善交流，因为我也是单身，难道我的姻缘就在此注定。孩子的名字我都想好了。一冰！好名字。
传统的单体架构的时候，我们基本是单库然后业务单表的结构。每个业务表的ID一般我们都是从1增，通过 AUTO_INCREMENT=1设置自增起始值，但是在分布式服务架构模式下分库分表的设计，使得多个库或多个表存储相同的业务数据。这种情况根据数据库的自增ID就会产生相同ID的情况，不能保证主键的唯一性。
create user ‘用户名’ @‘ip’ identified by ‘密码’; 创建用户 drop user 用户名@ip 删除用户 show databases; 查数据库 show tables; 看表 create database 数据库名 default charset utf8; 创建数据库 create table 表名(列名 数据类型 约束···，列名 数据类型 约束···）engine=innodb default charset=utf8 创建表 其中数据类型种类 数字(int，tinyint,smallint,float,double),字符串(char(个数)varchar(个数))时间(DATE,TIME,DATETIME),枚举enum(值只能是枚举中的元素），集合set(值只能是结合元素的组合)
一、何谓分库分表？ 把原本存储于一个库的数据分块存储到多个库（主机）上，把原本存储于一个表的数据分块存储到多个表上。 二、为什么要分库分表？ 数据库中的数据量不一定是可控的，在未进行分库分表的情况下，随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作，增删改查的开销也会越来越大。 另外，由于无法进行分布式式部署，而一台服务器的资源（CPU、磁盘、内存、IO等）是有限的，最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。 三、分库分表的实施策略 分库分表有垂直切分和水平
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
