什么？Mysql不设置主键竟然这么多问题

原创

銘聊技术 2024-01-13 00:08:47 ©著作权

©著作权归作者所有：来自51CTO博客作者銘聊技术的原创作品，请联系作者获取转载授权，否则将追究法律责任

什么？Mysql不设置主键竟然这么多问题

大家好，我是銘，全栈开发程序员。

Mysql大家不陌生吧，平时用的最多的数据库差不多就是它了，创建表的时候，没有主键好似也没啥问题，那今天我们聊一聊Mysql如果不设置主键会怎么样。

InnoDB索引

在聊这个话题之前，先说一下InnoDB索引，当Mysql数据表使用InnoDB作为存储引擎的时候，数据结构使用的就是B+树，而表的所有数据存储在主键索引上，也就是通常说的聚簇索引，也就是每个表需要有个聚簇索引树，对于InnoDB，主键对应的索引就是聚簇索引，而除了聚簇索引的其他索引存储的只是主键的引用，所以，查询的时候对于普通索引需要进行回表才能取到具体数据。

创建表没有主键，Mysql怎么处理呢

既然InnoDB对于数据的存储必须依赖主键，那没有主键的表，Mysql该怎么办呢？

当使用InnoDB作为引擎时，如果定义了主键，那么InnoDB会使用主键作为聚簇索引，如果没有定义主键，那么会使用第一非空的唯一索引NOT NULL and UNIQUE INDEX）作为聚簇索引，如果既没有主键，也没有合适的非空索引，那么InnoDB会自动生成一个包含ROW_ID值的列作为聚簇索引（就是InnoDB会自动帮我们生成一个隐藏列充当主键），插入新数据时，就会生成一个新的递增的ROW_ID，所以根据ROW_ID排序的行，本质上是按照插入顺序排序，很明显，没有主键的表，InnoDB就会内置一列用于聚簇索引来组织数据，没有建立主键的话就没法通过主键来进行索引，查询的时候是全表扫面的，数据量小的时候没问题，数据量多了性能就会出现问题。

隐式ROW_ID怎么实现

InnoDB帮我们生成的ROW_ID的列（就是隐藏的主键），既不能被任何查询访问，也不能被内部使用，。更坑爹的是，\所有用ROW_ID列的表，共享同一个被保存在数据字典中的全局序列数\，且下一个将要使用的值被保存在系统表空间的page 7（type SYS），数据字段头里（字段名为DICT_HDR_ROW_ID）。

这个全局序列计数器被dict_sys->mutex保护它的线程安全问题，在include/dict0boot.ic中的核心实现源码如下：

UNIV_INLINE
row_id_t
dict_sys_get_new_row_id(void)
/*=========================*/
{
    row_id_t        id;
    mutex_enter(&(dict_sys->mutex));
    id = dict_sys->row_id;
    if (0 == (id % DICT_HDR_ROW_ID_WRITE_MARGIN)) {
            dict_hdr_flush_row_id();
    }
    dict_sys->row_id++;
    mutex_exit(&(dict_sys->mutex));
    return(id);
}

很多小伙伴可能注意到了，这段代码对row_id只是一味的递增，没有任何48位溢出的保护。事实上也没有必要，因为即使只有48位，假设每秒插入10万次，需要90年才会耗尽ROW_ID的48位空间。所以，基本上够用！

另外我们从这段代码可知，每生成256次ROW_ID，计数器就会被刷到磁盘持久化（dict_hdr_flush_row_id()），这个频率通过字段DICT_HDR_ROW_ID_WRITE_MARGIN定义，并且被保存在事务日志中。在启动的时候，InnoDB将保存在磁盘上的DICT_HDR_ROW_ID增加256，这样就能确保已经生成的ID，不管是否被持久化到磁盘上，都会小于新生成的值，所以生成的ID不会有任何冲突。

InnoDB中很多地方的代码，包括刚才提到的ROW_ID的生成都是通过dict_sys->mutex保证线程安全问题，因此，我可以说任何用ROW_ID作为隐式聚簇索引键的表，都可能随机性的碰到插入停顿问题。多张这种表并行插入就会遇到性能限制，因为共享计数器的共享互斥锁和缓存争用是串行的。此外，每生成256个ID就会需要日志写入和刷新，这些都会引起性能毛刺问题。