MySQL主键可以使用VARCHAR，但强烈建议不要使用。VARCHAR是可变长度的字符串类型，会降低引擎效率，索引优化效果不佳，并且占用更多存储空间。INT类型主键是固定长度的整数类型，B+树索引利用率高，查找速度快，且占用空间较少。除非有特殊需要，否则建议使用INT、BIGINT或自增长的序列作为主键。
MySQL主键能用VARCHAR？听听过来人的肺腑之言
很多新手，甚至一些老手，都对MySQL主键用VARCHAR这事儿有点迷糊。答案是：能，但强烈不建议！ 这篇文章就来掰扯掰扯为啥。读完后，你不仅能明白为啥不建议用VARCHAR做主键，还能对数据库设计有更深层次的理解，避免掉进那些让人头疼的坑里。
咱们先从基础说起。主键，顾名思义，是数据库表里独一无二的标识符，用来快速定位记录。VARCHAR，则是可变长度的字符串类型。表面上看，用VARCHAR做主键似乎也没啥问题，毕竟能保证唯一性嘛。
但问题就出在“可变长度”这四个字上。MySQL引擎在处理VARCHAR主键时，效率会大打折扣。为啥？因为引擎需要额外的时间去计算字符串长度，进行比较和排序。想想看，如果你的表有百万甚至千万条记录，每次查询都需要进行大量的字符串比较，这性能开销有多大？这就像用拖拉机去跑F1赛道，你懂的。
更糟糕的是，InnoDB引擎（大多数情况下都是用的它）对VARCHAR主键的索引优化效果并不好。它会使用B+树索引，而B+树的节点大小是固定的。VARCHAR长度不固定，导致B+树节点的利用率低，增加磁盘IO操作，进而影响查询速度。这就好比用一个大小不一的盒子装东西，空间利用率极低，效率自然低下。
那INT类型的主键为啥效率高？因为INT是固定长度的整数类型，B+树节点利用率高，查找速度快。就像用标准尺寸的盒子装东西，空间利用率高，效率自然高。
再说说实际应用中的坑。假设你用UUID（一个常用的VARCHAR主键生成方式）做主键，它的长度通常是36个字符。试想一下，每条记录都要存储36个字符，占用的空间比INT类型大得多。如果你的表很大，这空间开销也是相当可观的。
SmartB2B 是一款基于PHP、MySQL、Smarty的B2B行业电子商务网站管理系统，系统提供了供求模型、企业模型、产品模型、人才招聘模型、资讯模型等模块，适用于想在行业里取得领先地位的企业快速假设B2B网站，可以运行于Linux与Windows等多重服务器环境，安装方便，使用灵活。 系统使用当前流行的PHP语言开发，以MySQL为数据库，采用B/S架构，MVC模式开发。融入了模型化、模板
当然，也不是说绝对不能用VARCHAR做主键。在一些特殊的场景下，比如需要保证主键的可读性，或者主键本身就是字符串类型，可以考虑使用VARCHAR。但这种情况非常少见，而且需要仔细权衡利弊。
下面，咱们来看点代码，感受一下INT主键和VARCHAR主键的性能差异：
-- 创建INT主键表
CREATE TABLE int_primary_key (
id INT PRIMARY KEY,
name VARCHAR(255)
);
-- 创建VARCHAR主键表
CREATE TABLE varchar_primary_key (
id VARCHAR(36) PRIMARY KEY,
name VARCHAR(255)
);
-- 插入大量数据 (这里省略了插入数据的代码，你可以自己动手试试)
-- 查询性能测试 (这里也省略了性能测试代码，建议用工具进行测试，例如MySQL自带的性能测试工具)自己动手跑一下测试，你会发现INT主键的查询速度明显快于VARCHAR主键。
最后，我的建议是：除非有非常特殊的需求，否则坚决不要使用VARCHAR作为主键。选择INT、BIGINT或者自增长的序列作为主键，才能保证数据库的性能和效率。记住，数据库设计是一个系统工程，选择合适的数据类型，对系统的整体性能至关重要。不要为了图一时方便，而埋下隐患。 经验之谈，切记切记！
