数值型与字符型主键的查询效率对比及单条查询耗时咨询

1. 查询两张表特定单行数据的大致耗时 #

实际耗时没有绝对固定值，得看数据库引擎、硬件配置、缓存命中率、索引碎片这些因素，给你个大致范围参考：

• Int 11自增主键表：如果是InnoDB引擎（大部分生产环境用这个），主键是聚簇索引，要是数据在缓存里，查单行大概0.1_{1毫秒**；如果没命中缓存需要读磁盘，耗时大概**5}20毫秒。
• Char 32主键表：同样InnoDB的话，字符型主键的索引体积比数值型大很多，缓存命中率可能更低。命中缓存时大概0.2_{2毫秒**；没命中磁盘IO的话，大概**10}30毫秒上下。

2. 数值型主键的查询速度是否快于字符型主键 #

肯定更快，主要原因有这几点：

• 存储空间更小：Int只占4字节，Char32要占32字节，索引树的层级会更少，查询时遍历索引的磁盘IO次数就少，速度自然快。
• 比较效率高：数值比较是直接的二进制运算，字符比较得按编码逐字节对比，耗时更长。
• 缓存利用率高：同样的内存空间，能缓存更多数值型主键的索引条目，命中率更高，查询也就更快。

不想用Int自增主键的替代方案 #

如果不想用Int自增主键，可以试试这些方案：

• BigInt自增主键：逻辑和Int自增一样，但支持的范围大得多（最大能到9e18），能避开Int的上限问题（Int最大约2e9）。
• 优化后的UUID：用带时间戳的UUID_v1，或者把UUID字符串转成二进制存储（占16字节，比Char32省一半空间），别用完全随机的UUID，不然索引碎片会特别严重。
• 雪花算法ID：生成的ID包含时间戳、机器标识、序列号，既全局唯一又有一定有序性，能减少索引碎片，性能比随机UUID好不少，用BigInt存储就行。
• 业务唯一ID：比如结合用户ID+时间戳+序列号生成唯一ID，但得确保生成逻辑不会冲突，而且性能要跟得上。

内容的提问来源于stack exchange，提问作者Taha Sami