背景
之前做了一个项目设计表的时候，不知道怎么脑子抽抽了下，也处于好奇（毕竟喜欢在写代码的时候试错、作死），没有添加自增主键id，结果上周运维使用阿里云排查SQL语句，得出一个有问题的列表，非常荣幸我上榜了，阿里云给出语句优化建议：表无主键，建议添加主键；执行时间也蛮快的，锁等待时间也没有，但就是不行，贼尴尬！麻溜加上自增主键id，在此记录，以自省。
主键
表中每一行都应该有可以唯一标识自己的一列（或一组列）。
主键（primary key） 一列（或一组列），其值能够唯一区分表中的每个行。
唯一标识表中每行的这个列（或这组列）称为主键。没有主键，更新或删除表中特定行很困难，因为没有安全的方法保证只涉及相关的行。
虽然并不总是都需要主键，但大多数数据库设计人员都应保证他们创建的每个表有一个主键，以便于以后数据操纵和管理。
表中的任何列都可以作为主键，只要它满足一下条件：
- 任何两行都不具有相同的主键值;
- 每个行都必须具有一个主键值（主键列不允许NULL值）;
主键值规范：这里列出的规则是MySQL本身强制实施的。
除MySQL强制实施的规则外，应该坚持的几个普遍认为主键的最好习惯为：
- 不更新主键列的值;
- 不重用主键列的值;
- 不在主键列中使用可能会更改的值（例如，如果使用一个名字作为主键以标识某个供应商，该供应商合并和更改其名字时，必须更改这个主键）;
总之：不应该使用一个具有意义的column（id 本身并不保存表有意义信息） 作为主键，并且一个表必须要有一个主键，为方便扩展、松耦合，高可用的系统做铺垫。
InnoDB引擎表是基于B+Tree的索引组织表
B+Tree的特点：
- 所有关键字都出现在叶子结点的链表中(稠密索引)，且链表中的关键字恰好是有序的;
- 不可能在非叶子结点命中;
- 非叶子结点相当于是叶子结点的索引(稀疏索引)，叶子结点相当于是存储(关键字)数据的数据层;
如果我们定义了主键(PRIMARY KEY)，那么InnoDB会选择主键作为聚集索引、如果没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引、如果也没有这样的唯一索引，则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增，这个ROWID不像ORACLE的ROWID那样可引用，是隐含的)。
数据记录本身被存于主索引（一颗B+Tree）的叶子节点上。这就要求同一个叶子节点内（大小为一个内存页或磁盘页）的各条数据记录按主键顺序存放，因此每当有一条新的记录插入时，MySQL会根据其主键将其插入适当的节点和位置，如果页面达到装载因子（InnoDB默认为15/16），则开辟一个新的页（节点）
如果表使用自增主键，那么每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置，当一页写满，就会自动开辟一个新的页。如下图所示：
这样就会形成一个紧凑的索引结构，近似顺序填满。由于每次插入时也不需要移动已有数据，因此效率很高，也不会增加很多开销在维护索引上。
如果使用非自增主键（比如身份证号或学号等），由于每次插入主键的值近似于随机，因此每次新纪录都要被插到现有索引页的中间某个位置，此时MySQL不得不为了将新记录插到合适位置而移动数据，甚至目标页面可能已经被回写到磁盘上而从缓存中清掉，此时又要从磁盘上读回来，这增加了很多开销，同时频繁的移动、分页操作造成了大量的碎片，得到了不够紧凑的索引结构，后续不得不通过OPTIMIZE TABLE来重建表并优化填充页面。
因此，在使用InnoDB存储引擎时，如果没有特别的需要，请永远使用一个与业务无关的自增字段作为主键；因为使用自增列(INT/BIGINT类型)做主键，这时候写入顺序是自增的，和B+Tree叶子节点分裂顺序一致，存取效率最高。
如果一个InnoDB表没有显示主键，又有可以被选择为主键的唯一索引，但该唯一索引可能不是递增关系时(例如字符串、多字段联合唯一索引的情况)，MySQL在频繁的更新、删除操作，会产生碎片。而含碎片比较大的表，查询效率会降低，存取效率极差。
说到主键，大家第一反应肯定就是，自增，int(11)，非空的字段来做主键，但也有特殊需要的会用varchar类型字段做主键也没什么，在性能上的表现是不明显的，通常说明这个字段含有业务含义，且业务能保证该字段唯一，有时候int范围太小，存的数据不够多，会用long类型，就性能而言，还是整型值的效率会高些（但很有限），整型值比字符型另一个优点就是可以通过数据库实现自增加列，减少编程的复杂性。
