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

最近,我看到一个系统设置表的主键的时候,都使用了定长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)减少随机写入问题。

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

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

相关推荐
M1A130 分钟前
TCP/IP协议精解:IP协议——互联网世界的邮政编码系统
后端·网络协议·tcp/ip
逸风尊者37 分钟前
开发易掌握的知识:GeoHash查找附近空闲车辆
java·后端
程序猿阿越2 小时前
Kafka源码(一)Controller选举与创建Topic
java·后端·源码
程序员爱钓鱼2 小时前
Go语言项目工程化 — 常见开发工具与 CI/CD 支持
开发语言·后端·golang·gin
Jiude2 小时前
MinIO 社区版被故意阉割,Web管理功能全面移除。我来试试国产RustFS
后端·docker·架构
仰望星空@脚踏实地2 小时前
Spring Boot Web 服务单元测试设计指南
spring boot·后端·单元测试
羊小猪~~3 小时前
数据库学习笔记(十七)--触发器的使用
数据库·人工智能·后端·sql·深度学习·mysql·考研
用户8324951417323 小时前
JAVA 版本多版本切换 - 傻瓜式操作工具
后端
estarlee3 小时前
随机昵称网名API接口教程:轻松获取百万创意昵称库
后端
明天好,会的3 小时前
跨平台ZeroMQ:在Rust中使用zmq库的完整指南
开发语言·后端·rust