MySQL 本身不支持 OOP，但应用层用 OOP 封装 MySQL 操作能显著降低维护成本
MySQL 是关系型数据库，没有类、继承、封装等 OOP 特性。所谓“MySQL 使用 OOP 思想”，实际是指在应用代码（如 Python/PHP/Java）中，用面向对象方式设计数据库访问层。这样做不是为了炫技，而是解决真实项目里反复出现的痛点：SQL 散落各处、参数拼接易出错、事务逻辑重复、表结构变更后牵一发而动全身。
用 DBConnection
+ Model
类封装增删改查，避免裸写 query()
直接调用底层驱动（如 Python 的
pymysql.execute()或 PHP 的
mysqli_query()）写 SQL，会导致业务逻辑和数据访问混杂。OOP 的解法是分层：一个连接管理类负责生命周期，一个基类
Model提供通用方法，具体表对应子类。
常见错误现象：手动拼接 SQL 字符串导致 SQL 注入；每次查询都重连数据库拖慢响应；更新多个字段时漏写
WHERE条件清空整张表。
Model子类应声明
_table属性，而非在每个方法里硬编码表名 所有写操作（
INSERT/
UPDATE/
DELETE）必须默认开启事务上下文，或显式要求传入
conn对象 查询方法返回统一结构（如字典列表），不暴露原始游标或结果集对象
class User(Model):
_table = 'users'
<pre class='brush:php;toolbar:false;'>def get_by_email(self, email):
return self.select_one("SELECT * FROM %s WHERE email = %s", self._table, email)调用时不用关心 SQL 细节，也不用自己处理参数转义
用继承+多态处理不同 MySQL 版本或存储引擎的兼容性差异
生产环境常遇到低版本 MySQL（如 5.6）不支持
JSON函数，或某张表用了
MyISAM引擎不支持事务。若所有逻辑堆在 if-else 里，代码很快变泥潭。OOP 可以把差异点抽象为方法，在子类中重写。
使用场景：迁移老系统时需兼容 MySQL 5.6 和 8.0；部分报表表用
ARCHIVE引擎只读，但主业务表需完整 CRUD。 基类
Model定义
get_insert_sql()、
get_update_sql()等钩子方法
MySQL56Model重写
json_contains()为字符串
LIKE模拟 只读模型继承自
ReadOnlyModel，禁止调用
save()和
delete()，运行时报错而非静默失败
ORM 不是银弹，手写关键 SQL + OOP 封装才是高并发项目的常见做法
很多团队踩过坑：全盘依赖 Django ORM 或 Laravel Eloquent，结果一条
select_related()生成 20 表 JOIN，慢查询频发；或复杂聚合统计被强行套进 ORM 链式调用，可读性归零。真正稳定的实践是——核心交易链路用预编译 SQL +
Model方法封装，非关键路径再用 ORM 快速开发。
性能影响明显的地方：分页（
LIMIT OFFSET在千万级表上失效）、全文检索（绕过
MATCH AGAINST直接走
LIKE '%x%'会锁表）、批量插入（ORM 逐条
INSERT比
INSERT INTO ... VALUES (),(),()慢 10 倍以上）。 在
Model中提供
bulk_insert_many()方法，内部拼接单条多值 SQL 复杂查询不封装进模型方法，而是单独建
report/目录，用
NamedTuple或
dataclass做结果映射 所有手写 SQL 必须走
self._execute(sql, params)统一入口，便于后续加日志、熔断、慢查采样
最容易被忽略的是连接泄漏：OOP 封装后，开发者容易忘记
conn.close()，尤其在异常分支里。正确做法是在
DBConnection类中用
__enter__/
__exit__支持
with语句，或让
Model方法内部自动管理短生命周期连接。
