pdo更好，因其更契合thinkphp抽象统一、可移植、易测试、错误可控的设计目标；性能差异微乎其微，真正瓶颈在于连接管理、查询设计、索引与缓存策略。
ThinkPHP 默认使用 PDO 驱动，不是因为“性能更好”，而是因为 PDO 更契合框架的设计目标：抽象统一、可移植、易测试、错误可控。在真实业务场景中，MySQLi 和 PDO 的性能差异微乎其微，几乎可以忽略；真正影响性能的是连接管理、查询设计、索引优化和缓存策略，而非驱动选型。
ThinkPHP 下两者实际性能对比的关键事实
基准测试（100次连接 + 500条插入）显示：
- PDO 连接创建略慢于 MySQLi（约慢 8%~12%，因 DSN 解析与属性初始化开销）
- 单次简单查询（如 SELECT * FROM user LIMIT 1）耗时基本一致（误差在 ±3% 内）
- 批量预处理写入（如 500 次 INSERT）在关闭模拟预处理（
PDO::ATTR_EMULATE_PREPARES = false）后，与 MySQLi 的prepare + bind_param性能相当 - 高并发下，若未正确复用连接或未启用持久连接，两者都会因频繁握手拖慢整体响应，此时瓶颈在 MySQL 本身，而非 PHP 驱动
为什么 ThinkPHP 官方推荐并默认用 PDO
这不是性能取舍，而是工程合理性选择：
-
数据库可迁移性：项目后期需切到 PostgreSQL 或 SQLite（如单元测试用内存库），PDO 只需改一句配置（
'dsn' => 'pgsql:host=...'），模型和查询逻辑零修改；MySQLi 则必须重写全部数据访问层 -
错误处理统一：PDO 启用
PDO::ERRMODE_EXCEPTION后，所有数据库异常都抛出PDOException，可被 ThinkPHP 的异常中间件统一捕获、记录、响应；MySQLi 默认静默失败，漏检$mysqli->error就导致白屏无日志 -
预处理更健壮：PDO 命名参数（
:name）语义清晰、顺序无关，避免 MySQLi 中bind_param('ssi', $a, $b, $c)类型字符错一位就静默绑定失败的问题 -
字符集与安全默认更合理：ThinkPHP 的 PDO 驱动自动在 DSN 中追加
;charset=utf8mb4，并强制设置ATTR_EMULATE_PREPARES=false，从源头规避 emoji 存储失败和 LIKE 注入风险；MySQLi 驱动需手动调set_charset('utf8mb4')且不干预 prepare 行为
什么情况下才该考虑 MySQLi 驱动
仅当同时满足以下全部条件时，才有必要评估切换：
- 项目已上线多年，全程只用 MySQL，且明确未来 3 年内绝不会换库或加其他数据源
- 核心链路存在毫秒级敏感操作（如高频金融对账），经 xhprof 或 Blackfire 精确分析确认数据库驱动是瓶颈（而非 SQL 或锁）
- 需要 MySQL 特有功能，例如：
mysqli::poll()实现连接池轮询、mysqli::send_query()异步多语句、或MYSQLI_CLIENT_COMPRESS压缩传输 - 团队熟悉 MySQLi 面向过程风格，且拒绝封装/适配 PDO 抽象层（但 ThinkPHP 本身已屏蔽底层细节，此条实际极少成立）
不换驱动也能提效的实操建议
比起纠结驱动，这些改动收益更大：
- 开启连接池或长连接：在数据库配置中设
'params' => [PDO::ATTR_PERSISTENT => true]（注意配合连接数限制） - 批量操作用事务包裹：避免每条 INSERT 都提交，ThinkPHP 的
Db::transaction()对 PDO/MySQLi 均有效 - 读写分离配置到位：ThinkPHP 支持主从分离，驱动类型不影响该能力，但能显著降低主库压力
- 查询结果缓存：用
cache(true)或 Redis 缓存高频不变数据，驱动层完全无感知
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
