偶然的机会，得知mysql主键的类型采用 varchar 存uuid 的查询性能没有int型做主键好。网上查询大量资料，都是停留在理论上的，因此，自己写了代码进行实测，以下结果仅供参考，不具备权威性。
三个表的字段，除了主键ID 分别采用varchar，bigint 和自动增长bigint不同外，其他三个字段都为 varchar 36位
数据库：mysql5.5
表类型：InnoDB
数据量：100W条
第一种情况：
主键采用uuid 32位。
运行查询语句1：SELECT COUNT(id) FROM test_varchar;
运行查询语句2：SELECT * FROM test_varchar WHERE vname='00004629-b052-11e1-96aa-002655b28d7b';
运行查询语句3：SELECT * FROM test_varchar WHERE id='00004599b05211e196aa002655b28d7b';
语句1消耗时间平均为：2.7秒；
语句2消耗时间平均为：3秒；
语句3消耗时间平均为：0秒；（多方测试，条件里只要有主键ID，查询速度毫秒级都显示000。测试的ID值，有前一百条的，也有后90多万条的。查询时间完全一样，毫秒级都为000）
第二种情况：
主键采用bigint，使用uuid_short()产生数据，数据为有序列的纯数字（22461015967875697）。（其相当于自动增长，只是固定的基数值较大而已。）
运行查询语句1：SELECT COUNT(id) FROM test_long;
运行查询语句2：SELECT * FROM test_long WHERE vname='d7f28a24-b053-11e1-96aa-002655b28d7b';
运行查询语句3：SELECT * FROM test_long WHERE id='22461015967875702';
语句1消耗时间平均为：1.2秒；
语句2消耗时间平均为：1.40秒；
语句3消耗时间平均为：0秒；（多方测试，条件里只要有主键ID，查询速度毫秒级都显示000。测试的ID值，有前一百条的，也有后90多万条的。查询时间完全一样，毫秒级都为000）
第三种情况：
运行查询语句1：SELECT COUNT(id) FROM test_int;
运行查询语句2：SELECT * FROM test_int WHERE vname='c80f8427-b059-11e1-96aa-002655b28d7b';
运行查询语句3：SELECT * FROM test_int WHERE id=900000;
主键采用mysql自带的自动增长，数据为纯数字（1，2，3，4，5……）。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
查询语句1消耗时间平均为：1.07秒；
查询语句2消耗时间平均为：1.31秒;
查询语句3消耗时间平均为：0秒；（多方测试，条件里只要有主键ID，查询速度毫秒级都显示000。测试的ID值，有前一百条的，也有后90多万条的。查询时间完全一样，毫秒级都为000）
总结：由此可见，mysql InnoDB 主键采用自动增长性能较高。
笔者自语：平时的项目开发，sql语句的条件里有ID的，占多数，没有的占少数。虽然以上的测试表明只要条件语句里有主键ID，主键类型不一样，查询时间完全一样。但是，你不能保证你的项目中所有sql语句的条件里都有ID，因此…………主键的类型该采用哪种，相信各位看官已经明白。
数据库：mysql5.5
表类型：MyISAM
数据量：100W条
为了少写一些字，节省时间，此测试所使用的表和sql语句同上，此处只记录消耗时间。
第一种情况：
主键采用uuid 32位。
语句1消耗时间平均为：0秒；
语句2消耗时间平均为：0.53秒；
语句3消耗时间平均为：0秒；（多方测试，条件里只要有主键ID，查询速度毫秒级都显示000。测试的ID值，有前一百条的，也有后90多万条的。查询时间完全一样，毫秒级都为000）
第二种情况：
主键采用bigint，使用uuid_short()产生数据，数据为有序列的纯数字（22461015967875697）。（其相当于自动增长，只是固定的基数值较大而已。）
语句1消耗时间平均为：0秒；
语句2消耗时间平均为：0.51秒；
语句3消耗时间平均为：0秒；（多方测试，条件里只要有主键ID，查询速度毫秒级都显示000。测试的ID值，有前一百条的，也有后90多万条的。查询时间完全一样，毫秒级都为000）
第三种情况：
主键采用mysql自带的自动增长，数据为纯数字（1，2，3，4，5……）。
语句1消耗时间平均为：0秒；
语句2消耗时间平均为：0.48秒；
语句3消耗时间平均为：0秒；（多方测试，条件里只要有主键ID，查询速度毫秒级都显示000。测试的ID值，有前一百条的，也有后90多万条的。查询时间完全一样，毫秒级都为000）
总结：由此可见，mysql MyISAM 主键采用自动增长性能比其他有微弱的优势。测试数据为100w，如果是1000W 1亿，我想这个优势会拉大，如果你还有外键关联查询，这个优势就更明显了。当然，如果你设计的系统，数据量还没有超过100W，你用啥主键类型都无所谓。我测试电脑是笔记本，如果是专业的服务器，估计100W条，mysql MyISAM 的这些测试，根本都测不出来时间差。
