MySQL是关系型数据库，不支持类、继承等面向对象概念；所有OO映射均由应用层ORM实现，性能问题多源于ORM生成的低效SQL而非MySQL本身。
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 或更好。
享有盛誉的PHP高级教程，Zend Framework核心开发人员力作，深入设计模式、PHP标准库和JSON 。 今天，PHP已经是无可争议的Web开发主流语言。PHP 5以后，它的面向对象特性也足以与Java和C#相抗衡。然而，讲述PHP高级特性的资料一直缺乏，大大影响了PHP语言的深入应用。 本书填补了这一空白。它专门针对有一定经验的PHP程序员，详细讲解了对他们最为重要的主题
真正该关注的是查询路径，不是对象模型
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 该不该一对一绑定”实在得多。
