MySQL 触发器不是面向对象的机制
触发器（
TRIGGER）是 MySQL 中基于表级数据变更（
INSERT/
UPDATE/
DELETE）自动执行的一段 SQL 逻辑，它没有类、实例、继承、封装或方法调用等面向对象（OOP）的核心特征。它的行为由数据库引擎在满足条件时“推”着执行，但本身不构成对象，也不支持
this、
new、访问修饰符或接口实现。
事件驱动 ≠ 面向对象
MySQL 的事件驱动特性（如触发器、事件调度器
EVENT）只表示“有事发生就响应”，和 OOP 没有必然联系。比如：
TRIGGER响应的是 DML 语句，不是对象方法调用；
EVENT是按时间调度的 SQL 批处理，不绑定任何数据结构或状态； 没有对象生命周期管理（构造/析构）、多态分发或消息传递机制。
真正的事件驱动 + OOP 组合常见于应用层（如 Python 的
asyncio+ 类方法，或 Java 的
EventListener接口），而非 MySQL 内部。
为什么容易混淆？
部分开发者看到“触发”“监听”“响应”等词，联想到前端 DOM 事件或 Spring 的
@EventListener，误以为底层模型类似。但要注意： MySQL 触发器中不能定义类、不能
new实例、不能调用自定义函数以外的“方法”；
NEW和
OLD是伪记录（pseudo-rows），不是对象实例——它们不可扩展、无方法、只读（对
BEFORE UPDATE的
NEW可赋值，但仍是字段集合）； 所有逻辑必须写成 SQL 语句或调用存储函数/过程，无法使用 OOP 语法表达行为抽象。
例如下面这个触发器只是修改字段值，并非“调用对象方法”：
CREATE TRIGGER update_updated_at BEFORE UPDATE ON users FOR EACH ROW SET NEW.updated_at = NOW();
如果真想在 MySQL 环境里靠近 OOP 思维
只能靠外围设计弥补，比如：
用存储过程模拟“方法”，以表名 + 动作命名：如sp_users_create()、
sp_orders_cancel()； 用 JSON 字段存结构化行为配置（但解析和执行仍在 SQL 层，不改变范式）； 把业务规则下沉到应用层 ORM（如 Django Model 的
save()、SQLAlchemy 的
@event.listens_for），让数据库只做持久化。
真正需要 OOP 封装和事件解耦时，MySQL 不是承载点——它负责可靠存取，而不是建模逻辑。
