因为MySQL中的自增字段与Oracle数据库是不一样的，所以在这里记录一下MySQL的自增字段。
松哥最近工作中刚好用到这块内容，于是调研了市面上几种常见的全局 ID 生成策略，稍微做了一下对比，供小伙伴们参考。
单主模式：只有一个成员对外提供服务。单主模式和异步模式比较类似，有了主从复制的经验，维护单主模式的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'); 添加自增字段并设置新数据的起始值 /*增加一个自增主键
A表带自增键，B表不带，通过程序从A表同步数据到B表,同步完成后会通过delete删除A表数据，今天插入B表会出现duplicate primary key问题。
表的主键指的针对一张表中的一列或者多列，其结果必须能标识表中每行记录的唯一性。InnoDB 表是索引组织表，主键既是数据也是索引。
业务量小于500W或数据容量小于2G的时候单独一个mysql即可提供服务，再大点的时候就进行读写分离也可以应付过来。但当主从同步也扛不住的时候就需要分表分库了，但分库分表后需要有一个唯一ID来标识一条数据，且这个唯一ID还必须有规则，能辅助我们解决分库分表的一些问题。
通常，我们都会在数据库表中设置一个自增字段作为主键，该字段的值会随着添加新记录而自增。 同时也必须注意，这个自增字段的值只会一直增加，即使把记录删除了，该自增字段的值也不会变小。 因此，就会产生一个现象：假如某些记录被物理删除了，那么表中记录的这个自增字段值就不是连续的。 即：通过某个自增值去查询的时候表里并不存在该记录。
在MySQL数据库中，主键自增是一种常见的技术，用于自动为表中的主键字段生成唯一的递增值。本文将深入讨论MySQL主键自增的原理、用途、使用方法，以及在实践中的注意事项和最佳实践。
在 MySQL 中，DATABASE 和 SCHEMA 在语法上是等效的，它们都用于创建数据库。在其他 RDBMS（如 Oracle 和 SQL Server）
通过SET auto_increment_increment=3，标识列可以设置步长。
（MySQL官网下载地址：http://dev.mysql.com/downloads/mysql/）
外键用来在两个表之间建立链接，它可以是一列或多列，一个表可以有一个或多个外键。
真正约束字段的是数据类型，但是数据类型约束很单一，需要有一些额外的约束，更好的保证数据的合法性，从业务逻辑角度保证数据的正确性。比如有一个字段是email，要求是唯一的。表中一定要有各种约束，通过约束，让我们未来插入数据库表中的数据是符合预期的。约束的本质是通过技术收到逼迫程序员插入正确的数据，反过来，站在mysql的视角，凡是插入进来的数据，都是符合数据约束的。约束的最终目标：保证数据的完整性和可预期性所以需要更多的约束。 表的约束很多，这里主要介绍如下几个： null/not null,default, comment, zerofill，primarykey，auto_increment，unique key 。
在数据库中对表中的数据进行限制，保证数据的正确性、有效性和完整性。一个表如果添加了约束，不正确的数据将无法插入到表中。约束在创建表的时候添加比较合适。
ID是数据的唯一标识，传统的做法是利用UUID和数据库的自增ID，在互联网企业中，大部分公司使用的都是Mysql，并且因为需要事务支持，所以通常会使用Innodb存储引擎，UUID太长以及无序，所以并不适合在Innodb中来作为主键，自增ID比较合适，但是随着公司的业务发展，数据量将越来越大，需要对数据进行分表，而分表后，每个表中的数据都会按自己的节奏进行自增，很有可能出现ID冲突。这时就需要一个单独的机制来负责生成唯一ID，生成出来的ID也可以叫做分布式ID，或全局ID。下面来分析各个生成分布式ID的机制。
此配置是我在使用过程中总结出比较实用的配置参数，基于GTID的主从复制场景中使用：
为什么要设置自增主键 id ？ PRIMARY KEY (id) 可以唯一标识一行数据，在 InnoDB 构建索引树的时候会使用主键。 自增 id 是顺序的，可以保证索引树上的数据比较紧凑，有更高的空间利用率以及减少数据页的分裂合并等操作，提高效率。(数字顺序搜索快一点) 一般使用手机号、身份证号作为主键等并不能保证顺序性。 流水号一般相对较长，比如 28 位，32 位等，过长的话会二级索引占用空间较多。同时为了业务需求，流水号具有一定的随机性。 int(11)是什么意思？ “int(11)中,11代表的并不是长度,而是字符的显示宽度 为什么id不能为空NOT NULL？ 如果查询中包含可为 NULL 的列，对 MySQL 来说更难优化 ，因为可为 NULL 的列使 得索引、索引统计和值比较都更复杂 。可为NULL 的列会使用更多的存储空间 ，在 MySQL 里也需要特殊处理 。当可为NULL 的列被索引肘，每个索引记录需要一个额 外的字节，在 MyISAM 里甚至还可能导致固定大小 的索引 （例如只有一个整数列的 索引） 变成可变大小的索引。(为null是占用存储空间的。为空不占用存储空间哦)
3、设置值的唯一性（不允许重复数据，可以为空，但只能有一个空，否则就会被视为重复）
https://cloud.tencent.com/document/product/215/20186
最近有个需要，国内和国外分别开了两台mysql数据库，要求是数据实时同步，不管那边访问，数据都是一样的。 其实好几年前，做过一次MySQL的主主同步，都已经忘记怎么做了。这次做完，顺便记录一下。
这里把自己学的mysql数据库的知识总结一下，当是给自己复习一遍，也是方便以后查询
将两个数据库组成主从模式的集群，正常情况下，是可以解决数据库的可靠性问题，但如果主库挂掉后，数据没有及时同步到从库，这个时候就会出现 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(值只能是结合元素的组合)
前两天粉丝给我留言吐槽最近面试：“四哥，年前我在公司受点委屈一冲动就裸辞了，然后现在疫情严重两个多月还没找到工作，接了几个视频面试也都没下文。好多面试官问完一个问题，紧接着说还会其他解决方法吗？能干活解决bug不就行了吗？那还得会多少种方法？”
最近有同学私信到数据库分布式id设计的时候，咨询这一块是怎么设计的，所以趁着周末，总结了根据现有业务来探讨分布式ID技术与实现。
业务量小于500W或数据容量小于2G的时候单独一个mysql即可提供服务，再大点的时候就进行读写分离也可以应付过来。但当主从同步也扛不住的是就需要分表分库了，但分库分表后需要有一个唯一ID来标识一条数据，数据库的自增ID显然不能满足需求；特别一点的如订单、优惠券也都需要有唯一ID做标识。此时一个能够生成全局唯一ID的系统是非常必要的。那么这个全局唯一ID就叫分布式ID。
前两天公众号有个粉丝给我留言吐槽最近面试：“四哥，年前我在公司受点委屈一冲动就裸辞了，然后现在疫情严重两个多月还没找到工作，接了几个视频面试也都没下文。好多面试官问完一个问题，紧接着说还会其他解决方法吗？能干活解决bug不就行了吗？那还得会多少种方法？”
由于前面前面已经介绍过了mycat的安装以及配置，这里就不在细说，如果下面对mycat的操作不是很清楚，可以看上一篇文章。
# 标识列 /* 又称为自增长列 含义：可以不用手动插入值，系统提供默认的序列值 特点： 1. 标识列必须和键搭配（主键，唯一，外键等） 2. 一个表中只能有一个标识列 3. 标识列的类型只能是数值型（整型+浮点型） */ # 创建表时，设置某列为标识列 DROP TABLE IF EXISTS tab_identify; CREATE TABLE tab_identify( id INT PRIMARY KEY AUTO_INCREMENT, NAME VARCHAR(20) ); TRUN
tokudb引擎的一个大表tb1，存放业务上的机审日志，每天有大量的写入， 并且由于历史原因，这张表是int signed 类型的，最大只能存 2147483647行记录 。
MySQL的自增锁是指在使用自增主键（Auto Increment）时，为了保证唯一性和正确性，系统会对自增字段进行加锁。这样可以确保同时插入多条记录时，每条记录都能够获得唯一的自增值。
表(TABLE) 是一种结构化的文件，可用来存储某种特定类型的数据。表中的一条记录有对应的标题，标题 称之为 表的字段。
分布式系统全局唯一的 id 是所有系统都会遇到的场景，往往会被用在搜索，存储方面，用于作为唯一的标识或者排序，比如全局唯一的订单号，优惠券的券码等，如果出现两个相同的订单号，对于用户无疑将是一个巨大的bug。
default默认值，创建列时可以指定默认值，当插入数据时如果未主动设置，则自动添加默认值
导读：分库分表能有效的环节单机和单库带来的性能瓶颈和压力，突破网络IO、硬件资源、连接数的瓶颈，同时也带来了一些问题。
在说分布式ID的具体实现之前，我们来简单分析一下为什么用分布式ID？分布式ID应该满足哪些特征？
为了便于大家查找问题，了解全貌，整理个目录，我们可以快速全局了解关于mysql数据库，面试官一般喜欢问哪些问题
约束其实就是一种限制,用于修饰表中的列. 通过这种限制来保证表中数据的正确性、有效性和完整性。
自增列（auto_increment）是数据库中常见的一项功能，它提供一种方便高效的方式为行分配唯一标识符，极大简化数据管理的复杂性。当新行插入到表中时，数据库系统会自动选取自增序列中的下一个可用值，并将其分配给指定的列，无需用户手动干预。这种自动化的机制不仅简化了数据管理的流程，更确保了标识符的唯一性，让数据库维护变得更加便捷和可靠。
这么温柔可爱的面试官，应该不会为难我吧。嗯，应该是的，毕竟我这么帅气，面试可能就是走个过场。美女面试官是不是单身？毕竟程序员都不善交流，因为我也是单身，难道我的姻缘就在此注定。孩子的名字我都想好了。一冰！好名字。
在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识。比如我们所熟知的美团、饿了么，携程、飞猪等app，它们的支付订单、餐饮、酒店、代金券等产品系统中，随着数据日渐增长，就会产生分表、分库的需求，这样也就需要一个唯一的ID来标识一条数据或消息，数据库的自增ID显然不能满足需求。
传统的单体架构的时候，我们基本是单库然后业务单表的结构。每个业务表的ID一般我们都是从1增，通过 AUTO_INCREMENT=1设置自增起始值，但是在分布式服务架构模式下分库分表的设计，使得多个库或多个表存储相同的业务数据。这种情况根据数据库的自增ID就会产生相同ID的情况，不能保证主键的唯一性。
Comparison among different ways of storing data：
在网上看见关于一首歌的评论，共勉：十年前，你周围的人会根据你父母对待你。十年后，你周围的人会根据你对待你的父母和你的孩子！没有不弯的路，没有不谢的花。通往成功的路不会平坦宽阔，实现自已的梦想不会一帆风顺，人生不如意十有八九，但这些都是暂时的。花开花落，潮起潮落，一切都会有终结的！
墨墨导读：为了达到标识的目的，许多应用程序需要生成唯一编号，比如：商品编号、交易流水号等。MySQL数据库同样能够支持这样的需求场景，AUTO_INCREMENT就是为MySQL实现序列的方式，它会自动生成序列编号。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
