正确方式是用 microtime(true) 包裹 query() 或 execute() 调用并立即读取结果，虽非服务端绝对精确但最轻量实用；真要权威耗时须依赖 MySQL 慢查询日志的 query_time 字段或 pt-query-digest 分析。
MySQLi 和 PDO 中获取查询耗时的正确方式
直接看执行时间，不能靠 microtime(true) 包裹 query() 调用——因为网络往返、服务端排队、锁等待等真实延迟都被你“过滤”掉了。真想统计数据库层实际耗时，得依赖驱动本身暴露的指标或服务端日志。
MySQLi（面向对象）不提供单条语句执行时间接口；PDO 更不提供。所以必须换思路：要么启用 MySQL 的慢查询日志并解析，要么在查询前后打点并接受客户端侧近似值（这是最常用、也最实用的做法）。
- 使用
microtime(true)记录query()前后时间差，是绝大多数生产环境的实际选择 - 注意关闭 MySQL 的
query_cache_type（已弃用但旧版本可能开启），否则缓存命中会严重干扰测量 - PDO 需确保未启用
PDO::ATTR_EMULATE_PREPARES，否则预处理语句会被客户端模拟，时间不含服务端解析开销
用 microtime(true) 统计单条查询耗时（推荐实操）
这是最轻量、最可控、且能覆盖 95% 调优场景的方式。关键不是“绝对精确”，而是“相对可比”——比如对比加索引前后的变化，或 A SQL 和 B SQL 的耗时差异。
$start = microtime(true);
$stmt = $pdo->query("SELECT * FROM users WHERE status = 'active'");
$result = $stmt->fetchAll();
$elapsed = microtime(true) - $start;
echo sprintf('Query took %.4f seconds', $elapsed); // 输出如：Query took 0.0234 seconds
- 务必在
query()或execute()后立刻读取结果（如fetch()、fetchAll()），否则耗时不含结果集传输和客户端遍历时间 - 如果用
fetch()循环读大数据集，microtime()应包住整个循环，否则只测了第一条 - 避免在测试时同时运行
var_dump()或print_r()，它们的输出开销可能远超查询本身
MySQL 慢查询日志 + pt-query-digest 分析全量耗时
当你要定位“哪类查询拖垮了整体响应”，而不是单次调试，就必须上服务端日志。PHP 层无法感知其他连接的查询行为，只有 MySQL 自己知道谁慢、为什么慢。
立即学习“PHP免费学习笔记（深入）”；
先确认 MySQL 已开启慢查询：
SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 0.1; -- 记录 >100ms 的所有查询（含未走索引的） SET GLOBAL log_output = 'TABLE'; -- 写入 mysql.slow_log 表，方便 PHP 查询分析
- 日志中
query_time字段才是服务端真实执行耗时（单位秒，精度微秒），比 PHP 打点更权威 - 配合 Percona Toolkit 的
pt-query-digest可聚合分析、排序、生成报告，比如“TOP 10 最慢查询” - 注意：
log_output = 'FILE'时，PHP 无法直接读取日志文件（权限/路径限制），需走中间服务或定时导入
为什么不要用 gettimeofday() 或 hrtime() 替代 microtime()
hrtime(true)（PHP 7.3+）精度更高，但对数据库查询耗时无实际意义——MySQL 协议本身、TCP 栈、甚至网卡中断延迟都在毫秒级，纳秒级打点只会给你虚假的确定性。
-
microtime(true)精度是微秒，足够区分 1ms 和 100ms 级别差异，也与 MySQLquery_time字段对齐 -
gettimeofday()在 Windows 上可能回退（系统时间校准），导致负耗时；microtime()底层用的是 monotonic clock（PHP 7.3+ 默认） - 真正影响耗时判断的，从来不是时钟精度，而是你有没有把网络 I/O、结果集解包、类型转换这些环节包含进去
最常被忽略的一点：很多人只测 query()，却忘了 prepare() 本身也有开销（尤其是高并发下服务端预处理缓存未命中）。如果用 PDO，建议把 prepare() 和 execute() 分开打点，才能看清瓶颈在编译还是执行。
