共计 1284 个字符，预计需要花费 4 分钟才能阅读完成。
这个问题嘛，不能一概而论：
（1）如果是 InnoDB 存储引擎，主键不宜过长；
（2）如果是 MyISAM 存储引擎，影响不大；
先举个简略的栗子阐明一下前序常识。
假如有数据表：
t(id PK, name KEY, sex, flag);
其中：
（1）id 是主键;
（2）name 建了一般索引;
假如表中有四条记录：
1, shenjian, m, A
3, zhangsan, m, A
5, lisi, m, A
9, wangwu, f, B
如果存储引擎是 MyISAM，其索引与记录的构造是这样的：
《2020 最新 Java 根底精讲视频教程和学习路线！》
（1）有独自的区域存储记录 (record)；
（2）主键索引与一般索引构造雷同，都存储记录的指针（暂且了解为指针）；
画外音：
（1）主键索引与记录不存储在一起，因而它是非汇集索引 (Unclustered Index)；
（2）MyISAM 能够没有 PK；
MyISAM 应用索引进行检索时，会先从索引树定位到记录指针，再通过记录指针定位到具体的记录。
画外音：不论主键索引，还一般索引，过程雷同。
InnoDB 则不同，其索引与记录的构造是这样的：
（1）主键索引与记录存储在一起；
（2）一般索引存储主键（这下不是指针了）；
画外音：
（1）主键索引与记录存储在一起，所以才叫汇集索引 (Clustered Index)；
（2）InnoDB 肯定会有汇集索引；
InnoDB 通过主键索引查问时，可能间接定位到行记录。
但如果通过一般索引查问时，会先查问出主键，再从主键索引上二次遍历索引树。
回归正题，为什么 InnoDB 的主键不宜过长呢？
假如有一个 用户核心 场景，蕴含身份证号，身份证 MD5，姓名，出生年月等业务属性，这些属性上均有查问需要。
最容易想到的设计形式是：
- 身份证作为主键
- 其余属性上建设索引
_user(id_code PK,
id_md5(index),
name(index),
birthday(index));_
此时的索引树与行记录构造如上：
- id_code 汇集索引，关联行记录
- 其余索引，存储 id_code 属性值
身份证号 id_code 是一个比拟长的字符串，每个索引都存储这个值，在数据量大，内存宝贵的状况下，MySQL 无限的缓冲区，存储的索引与数据会缩小，磁盘 IO 的概率会减少。
画外音：同时，索引占用的磁盘空间也会减少。
此时，应该新增一个无业务含意的 id 自增列：
- 以 id 自增列为汇集索引，关联行记录
- 其余索引，存储 id 值
_user(id PK auto inc,
id_code(index),
id_md5(index),
name(index),
birthday(index));_
如此一来，无限的缓冲区，可能缓冲更多的索引与行数据，磁盘 IO 的频率会升高，整体性能会减少。
总结
（1）MyISAM 的索引与数据离开存储，索引叶子存储指针，主键索引与一般索引无太大区别；
（2）InnoDB 的汇集索引和数据行对立存储，汇集索引存储数据行自身，一般索引存储主键；
（3）InnoDB 不倡议应用太长字段作为 PK（此时能够退出一个自增键 PK），MyISAM 则无所谓；
链接：https://juejin.cn/post/690447…
