摘要：
mysql事务id是连续的吗？MySQL的事务ID不是连续的。每个事务都有一个唯一的ID，但这个ID不是连续的。每个新开始的事务都将获得一个新的、独特的ID。这使得事务在数据库中独... mysql事务id是连续的吗？
MySQL的事务ID不是连续的。每个事务都有一个唯一的ID，但这个ID不是连续的。每个新开始的事务都将获得一个新的、独特的ID。这使得事务在数据库中独立，有助于错误恢复和问题追踪。
MySQL怎么样让自动增加的id字段从0开始计数啊？
有时候我们在测试网站的时候，删除测试数据导致id不是从0开始，那如果想id是从0开始怎么办呢？
mysql默认自增ID是从1开始了,但当我们如果有插入表或使用delete删除id之后ID就会不会从1开始了.
使用mysql时,通常表中会有一个自增的id字段,但当我们想将表中的数据清空重新添加数据时,希望id重新从1开始计数,用以下两种方法均可.
通常的设置自增字段的方法,创建表格时添加:
create table table1(id int auto_increment primary key,…)
创建表格后添加:
alter table table1 add id int auto_increment primary key 自增字段,一定要设置为primary key.
例子,代码如下:
alter table tablename drop column id;
alter table tablename add id mediumint(8) not null primary key auto_increment first;方法二:alter table tablename auto_increment=0
1. 可以实现自动从0开始计数。
2. MySQL有一个叫做AUTO_INCREMENT的属性，该属性默认从1开始计数。
我们可以通过修改该属性的值，来实现自动增加的id字段从0开始计数的需求。
3. 具体操作为，先将该id字段的AUTO_INCREMENT属性值设置为0，然后先插入一条带有该id字段的数据，此时id字段的值就会自动变成0，之后再将AUTO_INCREMENT属性设置为1即可。
mysql怎么获取insert的id？
useGeneratedKeys="true" 可以获取自增长的ID 只支持具有自增长方式的那种数据库(mysql, mssql 等 但 oracle 就不支持了 ) 所以可以使用selectKey来获取
MySQL分库分表之后，id主键如何处理？
我从分库分表存在的问题和怎么做来回答一下这个问题。。
一，分库分表的ID主键不能依赖于数据库的自增，因为多库中会重复！
通常使用外接的数据组件获取全局唯一的ID：比如加强型UUID（根据Ip，时间戳等得到）和使用Redis(RedisAtomicLong)和zookeeper的API获取，Twitter的雪花算法等等！
二，分库分表之后的连接查询比较困难！
问题没法避免，通常拆分SQL，使用多次查询，用查到的结果再分别查别的结果！
三，分布式事务的数据一致性很难保证！
可以使用TCC编程模型保证两处的事务都能正确提交，但是这种方式对代码的侵入比较重！也可以使用基于消息的数据一致性保证！
四，多数据的排序，分组，统计会比较困难！
1，用多线程，对多个节点分别查询，然后汇总！
2，也可以提前冗余查询表，将所有的经常查询的重点数据提前统一到个库表里！
分库分表涉及到的知识点比较多，建议使用专门的分库分表组件！本人有mycat使用经验，如果您有相关问题，欢迎前来探讨！
数据库在做了分库分表之后，关于ID主键，我认为需要考虑这几点：
生成算法
当我们的数据库是单台的时候，是不用太操心主键的生成，但是当数据库进行了分库分表之后，那么主键的生成就需要注意了，至少不能使用数据库内部的自增长序列了，通常要引入分布式唯一标识码的生成算法。
利用数据库生成：先说最笨的方法，利用数据库的自增长序列生成，数据库内唯一，有人会说，刚说完不能用数据库的自增长序列，这么快就要被打脸了么？其实这个的意思是，先利用（额外）的一台数据库，通过其自增长序列得到主键，然后作为分库分表的主键；
利用Redis/MongoDB/zookeeper生成：Redis的单线程的，利用incr和increby；MongoDB的ObjectId；ZK通过znode数据版本；都可以生成全局的唯一标识码；
UUID：生成唯一标识码最常用的算法之一；
Snowflake：Twitter开源，基于zk，41位时间戳（毫秒数）+10位机器的ID+12位毫秒内的流水号+1位符号位（永远是0）；
UidGenerator：百度开源，基于snowflake算法；
Leaf：美团开源，能保证全局唯一性、高可用、趋势递增（不太安全，比如泄露公司订单数量）、单调递增等。
扩容会比较麻烦
分库分表通常的方案都用主键mod分表的数量，来把数据路由到某一个数据库分片上。例如分了10张表，那么就是ID%10，得到结果0-9，代表不同的表；但是当数据量进一步增多的时候，单库的数据量达到了一定的级别之后，那么就需要分更多的表，那么这时候有哪些处理方案呢？
做数据迁移：最简单暴力，也是最麻烦的一个方案；因为当分表（分库）数量增多的时候，因为分片规则的变化，每个表的数据都要被重新分配到多个新的表；
如果id是一个增长的全局序列，当前有十张表，那么分表的算法为：id%10，根据0-9路由到10个表中；当表扩到20张的时候，扩容那一刻取max_id，那么未来分库的算法也就变成了：
if(id<max_id){id%10} else {id%20};
有些分表的算法本身就带时间戳，可以基于id中的时间戳来实现，比如Snowflake算法（见上文），这个算法是一个64位的Long值，前42位就是一个精确到毫秒的时间戳，那么我们的分库算法也就可以以某个时间点来判断：
if(id中的时间<增加分表那一刻的时间){id%10} else {id%20};
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
