自增主键优点
1.数据库AUTO_INCREMENT，innodb的索引特性导致了自增id做主键是效率最好的，而且是增量增长，按顺序存放，对于检索非常有利；
用户表user百万记录，主键为UUID和主键为自增Id，作基准测试 ，机器不同可能结果会有差异
1） 普通单条或者20条左右的记录检索，uuid为主键的相差不大几乎效率相同；
2）范围查询特别是上百成千条的记录查询，自增id的效率要大于uuid；
3）在范围查询做统计汇总的时候，自增id的效率要大于uuid；
4）在存储上面，自增id所占的存储空间是uuid的1/2；
5）在备份恢复上，自增ID主键稍微优于UUID。
用户表1000W记录测试：
1）普通单条或者20条左右的记录检索，自增主键效率是uuid主键的2到3倍；
2）但是范围查询特别是上百成千条的记录查询，自增id的效率要大于uuid；
3）在范围查询做统计汇总的时候，自增id主键的效率是uuid主键1.5到2倍；
4）在存储上面，自增id所占的存储空间是uuid的1/2；
5）在写入上面，自增ID主键的效率是UUID主键的3到10倍，相差比较明显，特别是update小范围之内的数据上面。
6）在备份恢复上，自增ID主键稍微优于UUID。
2.数字型，占用空间小，易排序；
3.如果通过非系统增加记录时，可以不用指定该字段，不用担心主键重复问题。
缺点以及解决方案
1.因为自动增长，在手动要插入指定ID的记录时会显得麻烦
此处的id在生成之前应该没有业务含义
2.是当系统与其它系统集成时需要数据导入时，很难保证原系统的ID不发生主键冲突（前提是老系统也是数字型的）特别是在新系统上线时，新旧系统并行存在，并且是异库异构的数据库的情况下，需要双向同步时，自增主键将是你的噩梦。
当数据依然时单库，数据迁移时，必然数据量不大，增量也不大，此时可以预估未来一段时间的id增长个数，然后以远高于以前id编号的数字，开始自增，这样可以允许新旧系统并行一段时间，但是需要尽快迁移。异构数据库现在其实很少遇到这样的案例，一般都统一为mysql，如果不是，可以重新思考解决方案
3.若系统也是数字型的，在导入时，为了区分新老数据，可能想在老数据主键前统一加一个字符标识（例如“o”，old）来表示这是老数据，那么自动增长的数字型又面临一个挑战。
同2所示，老数据数据较小，直接可以区分
4.表锁
在MySQL5.1.22之前，InnoDB自增值是通过其本身的自增长计数器来获取值，该实现方式是通过表锁机制来完成的（AUTO-INC LOCKING）。锁不是在每次事务完成后释放，而是在完成对自增长值插入的SQL语句后释放，要等待其释放才能进行后续操作。比如说当表里有一个auto_increment字段的时候，innoDB会在内存里保存一个计数器用来记录auto_increment的值，当插入一个新行数据时，就会用一个表锁来锁住这个计数器，直到插入结束。如果大量的并发插入，表锁会引起SQL堵塞。
在5.1.22之后，InnoDB为了解决自增主键锁表的问题，引入了参数innodb_autoinc_lock_mode，该实现方式是通过轻量级互斥量的增长机制完成的。它是专门用来在使用auto_increment的情况下调整锁策略的，目前有三种选择：
插入类型说明：
INSERT-LIKE：指所有的插入语句，比如 INSERT、REPLACE、INSERT…SELECT、REPLACE…SELECT,LOAD DATA等
Simple inserts：指在插入前就能确定插入行数的语句，包括INSERT、REPLACE，不包含INSERT…ON DUPLICATE KEY UPDATE这类语句。
Bulk inserts：指在插入前不能确定得到插入行的语句。如INSERT…SELECT,REPLACE…SELECT,LOAD DATA.
Mixed-mode inserts:指其中一部分是自增长的，有一部分是确定的。
---查看show variables like 'innodb_autoinc_lock_mode';
0：通过表锁的方式进行，也就是所有类型的insert都用AUTO-inc locking。
---1：默认值，对于simple insert 自增长值的产生使用互斥量对内存中的计数器进行累加操作，对于bulk insert 则还是使用表锁的方式进行。
2：对所有的insert-like 自增长值的产生使用互斥量机制完成，性能最高，并发插入可能导致自增值不连续，可能会导致Statement 的 Replication 出现不一致，使用该模式，需要用 Row Replication的模式。
尽量减少Bulk inserts的使用，一般情况下也很少用到，而且现在主流mysql都在5.6+
5.自增在bulk insert时不连续
mysql> show variables like 'innodb_autoinc_lock_mode';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| innodb_autoinc_lock_mode | 1 |
+--------------------------+-------+
mysql> show create table health_package;
health_package | CREATE TABLE `health_package` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '序号',
`package_id` int(11) NOT NULL COMMENT '套系 id',
`module_id` int(11) NOT NULL COMMENT '模块 id',
`gmt_create` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Create time, common column by DB rules',
`gmt_modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 'Modified time,common column by DB rules ',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1761 DEFAULT CHARSET=utf8 COMMENT='This table stores module and package of health for ...'ql> insert into health_package(package_id,module_id) select package_id,module_id from health_package limit 10;
Query OK, 10 rows affected (0.00 sec)
Records: 10 Duplicates: 0 Warnings:现在我的表是从1761开始自增，现在使用bulk insert，插入了10条数据
mysql> show create table health_package;
health_package | CREATE TABLE `health_package` (
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '序号',
`package_id` int(11) NOT NULL COMMENT '套系 id',
`module_id` int(11) NOT NULL COMMENT '模块 id',
`gmt_create` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Create time, common column by DB rules',
`gmt_modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 'Modified time,common column by DB rules ',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1776 DEFAULT CHARSET=utf8 COMMENT='This table stores module and package of health for ...'mysql> select * from health_package limit 1760,15
-> ;
+------+------------+-----------+---------------------+---------------------+
| id | package_id | module_id | gmt_create | gmt_modified |
+------+------------+-----------+---------------------+---------------------+
| 1761 | 1 | 1 | 2018-02-11 19:40:08 | 2018-02-11 19:40:08 |
| 1762 | 10001 | 5 | 2018-02-11 19:40:08 | 2018-02-11 19:40:08 |
| 1763 | 10001 | 5 | 2018-02-11 19:40:08 | 2018-02-11 19:40:08 |
| 1764 | 10001 | 5 | 2018-02-11 19:40:08 | 2018-02-11 19:40:08 |
| 1765 | 10001 | 5 | 2018-02-11 19:40:08 | 2018-02-11 19:40:08 |
| 1766 | 10001 | 5 | 2018-02-11 19:40:08 | 2018-02-11 19:40:08 |
| 1767 | 10001 | 5 | 2018-02-11 19:40:08 | 2018-02-11 19:40:08 |
| 1768 | 10001 | 5 | 2018-02-11 19:40:08 | 2018-02-11 19:40:08 |
| 1769 | 10001 | 5 | 2018-02-11 19:40:08 | 2018-02-11 19:40:08 |
| 1770 | 10001 | 5 | 2018-02-11 19:40:08 | 2018-02-11 19:40:08 |
+------+------------+-----------+---------------------+---------------------+
10 rows in set (0.00 sec)
此时再看一下，自增已经是1776了，查询数据库，发现数据库里面只是多了10条数据，如果你再插入一条数据，此时已经从1776开始了。这是因为参数innodb_autoinc_lock_mode = 1时，每次会“预申请”多余的id(handler.cc:compute_next_insert_id)，而insert执行完成后，会特别将这些预留的id空出，就是特意将预申请后的当前最大id回写到表中(dict0dict.c:dict_table_autoinc_update_if_greater)。
这个预留的策略是“不够时多申请几个”， 实际执行中是分步申请。至于申请几个，是由当时“已经插入了几条数据N”决定的。当auto_increment_offset＝1时，预申请的个数是 N-1。
所以，如果N为1，则不预申请，N为2，则预申请1个(3),N为3，已经预申请了，N为4，预申请3个(5,6,7),5,6,7已经预申请了，N为8，预申请个7个(9,10,11,12,13,14,15),所以最终的结果就是1761+15=1776，当然可以继续往后推此处不做例子，下来可以自己去试试。
6.主从复制
- 在 statement 模式下，由于他是记录的执行语句，所以，为了让这些语句在 slave 端也能正确执行，那么他还必须记录每条语句在执行的时候的一些相关信息，也就是上下文信息，以保证所有语句在 slave 端杯执行的时候能够得到和在 master 端执行时候相同的结果。在自增主键上面，有可能会出现不一致的情况
- 在 row 模式下，bin-log 中可以不记录执行的 SQL 语句的上下文相关的信息，仅仅只需要记录哪一条记录被修改了，修改成什么样了。所以 row 的日志内容会非常清楚的记录下每一行数据修改的细节，非常容易理解。所有自增主键也不会出现问题
- 但是在 row 模式下，所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容
除以下几种情况外，在运行时可以动态改变 binlog 的格式：
·存储流程或者触发器中间；
·启用了 NDB；
·当前会话使用 row 模式，并且已打开了临时表；
3.Mixed 模式，那么在以下几种情况下会自动将 binlog 的模式由 statement 模式变为 row 模式：
·当 DML 语句更新一个 NDB 表时；
·当函数中包含 UUID() 时；
· 2 个及以上包含 AUTO_INCREMENT 字段的表被更新时；
· 执行 INSERT DELAYED 语句时；
· 用 UDF 时；
· 视图中必须要求运用 row 时，例如建立视图时使用了 UUID() 函数；
这个问题我自己没有遇到过，其实很多复杂情况下都会出现主从不一致的情况，不同的模式都有可能，只要不写很复杂的sql语句，互联网公司也是禁止的，一般问题不大
7.主主双向复制
因为多主都可以对服务器有写权限，主键自增长一定会出现重复。
必须保证两台服务器上插入的自增长数据不同
A查奇数ID，B插偶数ID，步长不一样
在这里我们在A,B上加入参数，以实现奇偶插入
A：my.cnf上加入参数
auto_increment_offset = 1
auto_increment_increment = 2
这样A的auto_increment字段产生的数值是：1, 3, 5, 7, …等奇数ID了
B：my.cnf上加入参数
auto_increment_offset = 2
auto_increment_increment = 2
这样B的auto_increment字段产生的数值是：2, 4, 6, 8, …等偶数ID了
在每个集群节点组的master上面，设置（auto_increment_increment），让目前每个集群的起始点错开 1，步长选择大于将来基本不可能达到的切分集群数，达到将 ID 相对分段的效果来满足全局唯一的效果。
8.自增ID主键+步长
在每个集群节点组的master上面，设置（auto_increment_increment），让目前每个集群的起始点错开 1，步长选择大于将来基本不可能达到的切分集群数，达到将 ID 相对分段的效果来满足全局唯一的效果。
优点是：实现简单，后期维护简单，对应用透明。
缺点是：第一次设置相对较为复杂，因为要针对未来业务的发展而计算好足够的步长;
规划：
比如计划总共N个节点组，那么第i个节点组的my.cnf的配置为：
auto_increment_offset i
auto_increment_increment N
假如规划48个节点组，N为48，现在配置第8个节点组，这个i为8，第8个节点组的my.cnf里面的配置为：
auto_increment_offset 8
auto_increment_increment 48
不可取，禁止使用。一般情况下涉及到多库时，分库分表肯定是基于业务的考量，例如我可以根据城市来分，当某个城市数据量大了之后，我可能需要调整城市的分布。id一般会根据业务字段来生成，我只要拿到id就知道插入哪个表。如果id没有分片信息，如果要获取多余的字段，就会多增加几次sql操作，这会降低效率。使用uuid效果一样，并且还会降低效率，但是实现简单。
结论
1.小型系统或者系统架构初期，数据没有超过百万或者千万，可以使用自增主键
2.当数据成长到几百万或者超过千万时，并且增量很高时，这时就涉及到分库分表，这时就必须使用自动生成id方案
作者：glowd
原文：https://blog.csdn.net/zengqiang1/article/details/79312774
