MySQL 中 UUID() 不能用作列默认值，8.0.13+ 仍明确禁止；推荐用 BEFORE INSERT 触发器配合 IF 判断空值自动生成，兼顾兼容性与透明性。
MySQL 中 UUID() 不能直接用作列的默认值
如果你尝试在MySQL中为列设置默认值为UUID()，会发现这条路行不通。即便到了MySQL 8.0.13版本之后，虽然引入了对部分函数（比如NOW()）作为默认值的支持，但UUID()函数依然被明确排除在许可名单之外。直接执行CREATE TABLE t (id CHAR(36) DEFAULT UUID() PRIMARY KEY);这样的语句，会立刻收到一个invalid default value for 'id'的错误。这并非语法问题，而是MySQL设计上的限制。
在使用数据库管理工具（如DBea ver、Na vicat）时，这个限制表现得更为隐蔽：你可能在图形界面中为“默认值”一栏填入UUID()，但保存时，这个值要么被静默清空，要么直接报错，让人颇感困惑。
- 核心要点：不要在DDL语句中硬写
DEFAULT UUID()，它不会生效。 - ORM注意：如果使用Django、SQLAlchemy等ORM框架，务必确保主键的生成逻辑放在应用层代码或数据库触发器中，而不是依赖数据库的列默认值功能。
- 版本确认：这个限制至少持续到MySQL 8.0.31版本，官方文档将其归类为“不允许的非确定性函数”。
用触发器实现插入时自动生成 UUID 主键最稳妥
既然默认值走不通，那么触发器就成了一个优雅且强大的替代方案。它巧妙地绕过了限制，并且对所有客户端——无论是命令行、可视化工具还是ORM——都完全透明。一旦表上定义了相应的触发器，任何INSERT操作只要没有提供id值，就会自动填充一个UUID。
这个方法特别适用于需要兼容旧版MySQL、希望各类工具都能无缝插入数据，或者不想让业务代码感知主键生成细节的场景。
具体操作可以分为两步：
- 第一步：建表。将主键字段设置为
NOT NULL，但不设置默认值。CREATE TABLE users ( id CHAR(36) NOT NULL PRIMARY KEY, name VARCHAR(50) );
- 第二步：创建触发器。关键点在于使用
BEFORE INSERT触发器配合IFNULL函数。CREATE TRIGGER users_set_uuid BEFORE INSERT ON users FOR EACH ROW SET NEW.id = IFNULL(NEW.id, UUID());
这里的IFNULL是点睛之笔：它首先检查插入语句是否显式提供了id值（例如在数据迁移时），只有当id为NULL时，才触发UUID()函数生成新值。这种设计兼顾了灵活性与自动化。至于性能，完全不必多虑，UUID生成是纯内存操作，对数据库性能的影响微乎其微。
PostgreSQL 可直接用 gen_random_uuid() 或 uuid_generate_v4()
相比之下，PostgreSQL对UUID的支持就显得“开箱即用”得多。不过，这里也有细节需要注意，主要是函数来源和权限。
PostgreSQL提供了两种主流方式：一种是内置在pgcrypto扩展中的gen_random_uuid()；另一种是更常见的、来自uuid-ossp扩展的uuid_generate_v4()。一个常见的错误是，直接建表CREATE TABLE t (id UUID DEFAULT uuid_generate_v4())却报错“function uuid_generate_v4() does not exist”，这通常是因为对应的扩展没有启用。
- 启用扩展：首先需要以超级用户权限执行
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";。 - 建表定义：之后就可以在建表时直接使用了：
id UUID PRIMARY KEY DEFAULT uuid_generate_v4()。 - 工具兼容：像pgAdmin这类可视化工具通常能识别这种默认值，在新增记录时会自动处理。
- 避免野路子：不建议使用
md5(random()::text)这类手动拼接的方式来生成UUID，既不标准也不可靠。
前端/可视化界面提交时漏传 id 字段反而成了“优点”
一个有趣的现象是，在许多低代码平台或内部工具（如Retool）中，表单提交的INSERT操作默认只包含用户填写的非主键字段。这在UUID主键的场景下，反而成了一个优势——只要数据库层（通过触发器）或后端服务层做好了兜底生成，前端就完全无需为此编写任何特殊逻辑。
当然，实践中还是有些坑需要留意：
- ORM配置：如果后端使用类似Lara vel Eloquent这样的ORM，将主键类型设置为字符串（
$keyType = 'string'）后，切记同时关闭自增属性（$incrementing = false）。否则，ORM可能仍会尝试插入0或空字符串，导致唯一键冲突。 - 空值判断：前面提到的MySQL触发器使用了
IFNULL，但它只判断NULL。如果前端传入了空字符串""或全零UUID，它不会触发生成新ID。更严谨的写法是：IF(NEW.id = '' OR NEW.id IS NULL, UUID(), NEW.id)。 - 性能认知：UUID作为主键时，由于其无序性，在B+树索引中的写入局部性较差，理论上高并发插入可能比自增ID略慢。但话说回来，对于绝大多数中小型系统，这个差异几乎无法感知，不必过早优化。
说到底，实现UUID自动生成的关键，在于确保触发器和扩展被正确启用，并且空值判断逻辑要覆盖所有可能的“伪空”情况。其他地方出点小问题或许还能运行，这里要是漏了，新数据可就真的插不进去了。
