每日数据库知识-主键使用定长字符的优劣是什么?

最近,我看到一个系统设置表的主键的时候,都使用了定长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 :若无特殊需求,使用INTBIGINT作为主键,性能优势明显。
  • 慎用CHAR(20):仅在主键必须为业务标识且长度固定时使用,避免因字符集导致空间浪费。
  • 自增 vs UUID :若需字符串主键,考虑有序UUID(如MySQL 8.0的UUID_TO_BIN)减少随机写入问题。

通过合理选择主键类型,可以显著优化数据库的存储效率和查询性能。

字串的优势在于便于识别,当一个表的内容比较小的时候,可以使用。

相关推荐
Piper蛋窝2 小时前
深入 Go 语言垃圾回收:从原理到内建类型 Slice、Map 的陷阱以及为何需要 strings.Builder
后端·go
六毛的毛4 小时前
Springboot开发常见注解一览
java·spring boot·后端
AntBlack4 小时前
拖了五个月 ,不当韭菜体验版算是正式发布了
前端·后端·python
31535669134 小时前
一个简单的脚本,让pdf开启夜间模式
前端·后端
uzong4 小时前
curl案例讲解
后端
一只叫煤球的猫5 小时前
真实事故复盘:Redis分布式锁居然失效了?公司十年老程序员踩的坑
java·redis·后端
大鸡腿同学6 小时前
身弱武修法:玄之又玄,奇妙之门
后端
轻语呢喃8 小时前
JavaScript :字符串模板——优雅编程的基石
前端·javascript·后端
MikeWe8 小时前
Paddle张量操作全解析:从基础创建到高级应用
后端
岫珩8 小时前
Ubuntu系统关闭防火墙的正确方式
后端