最近，我看到一个系统设置表的主键的时候，都使用了定长20的字符串，我想到了我以前做大规模数据的优化的时候的一个经历，重新认真想了想这个事。
因此详细记录一下。
另外，关于优化，我补充一下：不要为了优化而优化，优化的前提是它真的慢下来了，如果一个系统的数据量不大，那么可以不用优化。
MySQL数据库优化和JVM优化一样，都是数据或者性能达到极限，已经没有其他更加廉价或者有效的办法的时候的选择。
在MySQL中，选择主键时使用Integer类型（如INT）与CHAR(20)的区别主要体现在存储效率、性能、索引结构等方面。
以下是详细对比：
1. Integer主键的特性
-
存储空间：
INT类型占用4字节存储空间（范围：-2³¹ ~ 2³¹-1，无符号为0 ~ 4,294,967,295）。BIGINT占用8字节（范围更大）。- 如果使用
INT(11)，这里的11是显示宽度，仅影响输出格式（如补零），不影响实际存储。
-
性能优势：
- 查询速度快：整数的比较和哈希计算效率远高于字符串。
- 索引更小：主键索引（B+树）的节点能存储更多键值，减少树的高度，提升查询效率。
- 写入友好 ：若使用
AUTO_INCREMENT（自增），插入数据时直接追加到索引末尾，减少页分裂和碎片。
-
适用场景：
- 无业务含义的代理主键（如用户ID、订单ID）。
- 高并发写入场景（如日志表）。
2. CHAR(20)主键的特性
-
存储空间：
CHAR(20)是定长字符串，占用空间取决于字符集：latin1：20字节（每个字符1字节）。utf8mb4：最多80字节（每个字符4字节，如存储Emoji）。
- 实际存储可能包含空格填充（定长特性）。
-
性能劣势：
- 查询较慢：字符串比较需逐个字符计算，效率低于整数。
- 索引更大：主键索引的节点存储更少键值，树的高度增加，降低查询速度。
- 写入随机性：若使用UUID等随机字符串，会导致索引页分裂，影响写入性能。
-
适用场景：
- 主键本身是业务标识（如身份证号、固定格式的订单号）。
- 需要兼容外部系统定义的键（如第三方API的ID）。
3. 对比总结
| 特性 | INT/BIGINT | CHAR(20) |
|---|---|---|
| 存储空间 | 4~8字节 | 20~80字节（依赖字符集） |
| 查询性能 | 快（二进制比较） | 慢（逐字符比较） |
| 索引效率 | 高（索引更小） | 低（索引更大） |
| 写入性能 | 高（顺序追加） | 低（随机写入导致页分裂） |
| 业务相关性 | 无意义代理键 | 可能有业务含义的自然键 |
| 扩展性 | 范围有限（BIGINT足够大） | 灵活但浪费空间 |
4. 建议
- 优先选择Integer ：若无特殊需求，使用
INT或BIGINT作为主键，性能优势明显。 - 慎用CHAR(20)：仅在主键必须为业务标识且长度固定时使用，避免因字符集导致空间浪费。
- 自增 vs UUID ：若需字符串主键，考虑有序UUID（如MySQL 8.0的
UUID_TO_BIN）减少随机写入问题。
通过合理选择主键类型，可以显著优化数据库的存储效率和查询性能。
字串的优势在于便于识别，当一个表的内容比较小的时候，可以使用。