MySQL本身不支持面向对象编程，它作为关系型数据库缺乏类、继承、封装、多态等OOP特性；所谓“面向对象”实为应用层通过ORM（如SQLAlchemy、Django ORM）将表映射为类、行映射为实例、字段映射为属性，并在代码中实现验证、关联、钩子等行为，MySQL仅负责扁平化数据的存取。
MySQL 本身不支持面向对象编程
MySQL 是关系型数据库，不是编程语言，它没有类、继承、封装、多态这些 OOP 特性。所谓“MySQL 面向对象编程”，通常是开发者在应用层（比如 Python、Java、PHP）用 ORM 框架模拟 OOP 行为，或在 SQL 层尝试用视图、存储过程、JSON 字段等“类比”对象结构——但这只是设计思路的迁移，不是真正的 OOP。
ORM 是最常用的“类对象映射”方式
真正让 MySQL “看起来像 OOP” 的，是 ORM（Object-Relational Mapping）工具。它把数据库表映射成程序中的类，行映射成实例，字段映射成属性。
-
SQLAlchemy（Python）中，User类对应users表，user = User(name='Alice')创建一个实例，session.add(user)触发 INSERT -
Django ORM中，models.Model是基类，子类自动获得save()、delete()、objects.filter()等方法 -
ActiveRecord（Ruby on Rails）甚至让User.find(1)直接返回带业务逻辑的对象，而非原始数据行
关键点：所有对象行为（如验证、关联加载、钩子回调）都在应用代码里定义，MySQL 只负责存取扁平化的字段值。
MySQL 内部无法定义“方法”或“访问控制”
有人试图用存储函数或触发器模拟“对象方法”，比如写一个 get_full_name() 存储函数来拼接 first_name 和 last_name。但要注意：
- 存储函数不能修改数据（除非用
MODIFIES SQL DATA显式声明），也不具备状态或实例上下文 - 无法实现封装：所有字段仍是直接可查的，
SELECT *会暴露全部列，没有private或protected - 继承无法表达：MySQL 没有“父表/子表自动继承字段”的语法；常见做法是用
JOIN或UNION手动组合，或用单表继承（type字段区分） - JSON 字段（如
meta JSON）能存嵌套结构，但 MySQL 不提供原生的“调用对象方法”能力，JSON_EXTRACT(meta, '$.settings.theme')只是取值，不是执行方法
容易混淆的典型错误场景
新手常误以为以下操作是“OOP”：
- 给表起名
user_profile、user_preference就算“建了多个类” → 实际只是命名习惯，无语义约束 - 在触发器里写
SET NEW.updated_at = NOW()就算“实现了 setter” → 这只是自动赋值，不涉及对象生命周期或校验逻辑 - 用视图封装复杂查询，命名为
v_active_users就当成“类接口” → 视图是只读虚拟表，不能有状态、不能传参（除非用 MySQL 8.0+ 的CTE或参数化视图替代方案）
真正需要 OOP 语义时，逻辑必须落在应用层。MySQL 的角色始终是可靠、高效、一致的数据持久化引擎——它不负责建模，只负责存得准、查得快、改得稳。
