为何@PrimaryGeneratedColumn("uuid")在MySQL中生成VARCHAR(36)而非CHAR(36)？

结合你使用的技术栈（TypeORM 0.3.17、MySQL 8.1.0等），主要原因有以下几点：

• 跨数据库兼容性：TypeORM作为通用ORM框架，需要适配多种数据库系统。不同数据库对CHAR类型和UUID的处理逻辑存在差异，比如部分数据库原生不支持用CHAR存储UUID，或在字符编码、存储优化上有特殊要求。使用VARCHAR(36)可以在不同数据库环境中保持一致的行为，无需针对特定数据库做定制化适配。

• 设计的延续性与兼容性：TypeORM早期版本为了覆盖更多使用场景，选择了VARCHAR作为UUID的存储类型。后续版本延续这一设计，避免因类型变更导致现有项目出现数据兼容问题，比如旧数据迁移时的格式转换风险。

• MySQL存储特性与实际差异：虽然UUID固定为36位，但在MySQL中，CHAR(36)和VARCHAR(36)的存储开销差异极小——CHAR(36)直接占用36字节，VARCHAR(36)会额外多1字节存储长度信息（因36≤255）。这种差异在实际业务中几乎可以忽略，TypeORM更倾向于用统一的VARCHAR逻辑处理字符串类型，减少特殊类型的判断分支。

• 潜在的扩展性：虽然标准UUID是36位，但实际场景中可能出现变体（比如去掉连字符的32位UUID）。VARCHAR(36)可以兼容这类长度更短的格式，而CHAR(36)会自动补空格，反而可能引发数据格式校验或查询匹配的问题。

内容的提问来源于stack exchange，提问作者Hyungjin Kim