MySQL 本身不支持面向对象设计
直接说结论：
MySQL是关系型数据库，没有类、继承、封装、多态等面向对象概念。所谓“面向对象设计”在 MySQL 中并不存在——你不能定义
class User，也不能让
Admin继承
User。所有“OO 设计映射到 MySQL”的尝试，实际都是应用层（比如 Python/Java）的 ORM（如
SQLAlchemy、
Hibernate）在做转换，而底层仍是标准的表、字段、索引、JOIN。
ORM 的对象建模方式会显著影响查询性能
常见问题不是 MySQL “慢”，而是 ORM 自动生成的 SQL 不合理。比如：
SELECT *拉取整张表，哪怕只用其中 1 个字段 嵌套
JOIN过深，ORM 自动拼出 5 张表关联，但业务其实只需要用户昵称和最近一条订单 一对多关系默认开启
eager loading，查 1 个用户触发 100 次
SELECT（N+1 查询） 用
JSON字段存对象结构，后续想按内部字段筛选时只能全表扫描（
JSON_CONTAINS无法走索引）
这些都不是 MySQL 的锅，但最终表现为“数据库变慢”。优化方向很明确：关掉自动 JOIN，显式写
SELECT列表，用
EXPLAIN看执行计划，必要时绕过 ORM 直写原生 SQL。
反范式与冗余字段是常见的性能权衡点
纯“面向对象思维”倾向把数据拆得极细（比如
user、
user_profile、
user_settings各一张表），这利于维护但增加 JOIN 成本。真实高性能场景往往反其道而行： 在
orders表里冗余
user_nickname，避免查订单时连
users表 把高频统计值（如
article_comment_count）存在主表，而不是每次
COUNT()子查询 用
ENUM或
TINYINT替代外键关联的状态表（如订单状态），减少 JOIN，也降低存储开销
这类设计违反“教科书范式”，但对读多写少、QPS 高的业务更友好。关键看
WHERE条件是否能命中索引，以及
EXPLAIN是否显示
type=ref或更好。
真正该关注的是查询路径，不是对象模型
MySQL 性能瓶颈几乎都落在三件事上：索引没建对、查询没走索引、磁盘 I/O 过高（大结果集、临时表落盘）。与其纠结“这个实体要不要拆成两张表”，不如问：
这条查询最常 WHERE 的字段有没有联合索引？顺序对不对？ 返回的rows数量是不是远大于实际需要？
SHOW PROFILE显示耗时最多的是
Copying to tmp table还是
Sorting result？
很多团队花两周重构 ORM 关系映射，上线后发现慢查询日志里排第一的还是那条没加索引的
LIKE '%keyword%'—— 优先级错位了。
EXPLAIN SELECT u.name, o.total FROM users u JOIN orders o ON u.id = o.user_id WHERE o.status = 1 AND o.created_at > '2024-01-01';
查完这个，再决定要不要把
status和
created_at加进联合索引，比争论“User 和 Order 该不该一对一绑定”实在得多。
