mysqli_query()和pdo::query()慢的主因是未索引+无预处理导致全表扫描与硬解析，应建b-tree索引、用预处理、避免select*、禁用模拟预处理、流式取数，并通过explain定位性能瓶颈。
PHP 中 mysqli_query() 和 PDO::query() 为什么慢得明显
不是函数本身慢，而是默认用法触发了全表扫描或重复解析。比如在循环里反复调用 mysqli_query($conn, "SELECT * FROM users WHERE id = $id")，既没预处理，又没索引支撑，每次都是硬解析+全表扫。
实操建议：
- 把
WHERE条件字段（如user_id、status）加上 B-tree 索引，用EXPLAIN验证是否命中 - 改用预处理语句：
$stmt = $pdo->prepare("SELECT name FROM users WHERE id = ?"); $stmt->execute([$id]); - 避免
SELECT *，只查真实需要的字段，减少网络传输和内存占用 - 确认连接未启用
mysqlnd的缓存（如mysqli.cache_size），它对动态 SQL 无效，反而误导判断
AI 辅助写 SQL 时最常生成的三类危险查询
GitHub Copilot、CodeWhisperer 等工具在补全 SQL 时，倾向“语法正确但性能灾难”的写法，尤其在关联复杂业务逻辑时。
典型问题：
-
JOIN多层嵌套却没加ON条件索引，导致笛卡尔积 —— 查 100 行用户 × 1000 行订单 = 10 万行中间结果 - 在
WHERE中对字段用函数：WHERE DATE(created_at) = '2024-01-01'，直接让created_at索引失效 - 用
IN (SELECT ...)替代JOIN，MySQL 5.7 及更早版本会强制走依赖子查询，无法用上索引
应对方法：把 AI 生成的 SQL 粘贴进 phpMyAdmin 或命令行执行 EXPLAIN FORMAT=TREE，重点看 rows 和 type 列 —— 出现 ALL 或 index 就得重写。
PHP 层面绕不开的三个配置陷阱
很多性能问题不来自 SQL 本身，而来自 PHP 连接和结果集处理方式。
-
mysqli_options($conn, MYSQLI_OPT_CONNECT_TIMEOUT, 2)不设超时，数据库卡住时 PHP 进程会挂满，看起来像“查询慢”，其实是连接等死 - 用
mysqli_fetch_all($result, MYSQLI_ASSOC)一次性取全部数据，大结果集（>1 万行）直接吃光内存；应改用while ($row = mysqli_fetch_assoc($result))流式读取 -
PDO默认开启PDO::ATTR_EMULATE_PREPARES = true，在 MySQL 5.6 以下版本会导致预处理被模拟成字符串拼接，失去参数绑定和计划缓存优势；显式关掉：$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false)
什么时候该放弃优化 SQL，转去改架构
单表查询加了索引、用了预处理、EXPLAIN 显示 type=ref、rows 控制在千级以内，但接口响应仍 >500ms，大概率是架构级瓶颈。
可立刻检查：
- 是否在事务里干了非 DB 操作（如调第三方 API、写文件）——
mysqli_begin_transaction()后拖太久，锁住行/表 - 是否高频更新同一张表的统计字段（如
view_count），引发写竞争；考虑用 Redis 计数器异步落库 - 是否用 MySQL 承担了不该它干的活（如模糊搜索、地理围栏、全文检索）—— 这些交给
Elasticsearch或Sphinx更合适
真要动 SQL，先看慢日志里 Query_time 和 Lock_time 哪个更大；前者调查询，后者调并发设计。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
