MySQL 5.7中确认SQL真实耗时最可靠方式是查看慢查询日志，因其记录从解析到返回结果的全程微秒级总耗时；实时监控则需启用performance_schema.events_statements_current并查TIMER_WAIT（皮秒单位，需除1000000000000转秒），而SHOW PROFILES的Duration仅含粗略阶段估算，不包含网络、锁等待等关键环节，且8.0已弃用。
MySQL 5.7里看SQL真实耗时，别信SHOW PROFILES的Memory和Duration——它只记录粗略阶段时间，且8.0已弃用；真正能反映“从发起到返回结果”全程耗时的，只有慢查询日志、performance_schema.events_statements_current和EXPLAIN ANALYZE（后者5.7不支持，得排除）。
怎么确认一条SQL到底跑了多久？看慢查询日志最可靠
慢查询日志记录的是完整生命周期：从解析、优化、执行到发送结果的总耗时，单位精确到微秒，且不受会话隔离影响。
-
long_query_time必须设低（比如0.2），否则300ms的语句根本进不去日志 - 日志路径由
slow_query_log_file指定，MySQL进程必须对该路径有写权限，否则静默失败——查不到日志先ls -l看权限 - 日志里
Query_time: 0.123456是真实耗时，小数点后六位是微秒，不是毫秒；Lock_time接近它，说明瓶颈在锁等待，不是SQL本身 - 别用
grep手动翻，用mysqldumpslow -s t -t 10 /var/lib/mysql/xxx-slow.log，它自动归并参数化SQL，排序更准
想实时抓正在跑的SQL耗时？用events_statements_current而不是SHOW PROCESSLIST
SHOW FULL PROCESSLIST只能看到Time字段（状态持续秒数），但这个值可能卡在“Sending data”或“Sorting result”，无法区分是计算慢还是网络慢；而events_statements_current直接暴露SQL级皮秒级耗时。
- 查当前活跃CALL或SELECT：
SELECT SQL_TEXT, TIMER_WAIT/1000000000000 AS sec FROM performance_schema.events_statements_current WHERE SQL_TEXT IS NOT NULL ORDER BY TIMER_WAIT DESC LIMIT 5 -
TIMER_WAIT单位是皮秒，不除1000000000000你会看到一串123456789012，没法读 - 如果返回空，先检查
setup_instruments是否启用：UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' WHERE NAME = 'statement/sql/select'（同理对call、insert等） - 注意：该表只存当前线程最新一条语句，不是历史记录——要查刚跑完的，得切到
events_statements_history_long
为什么SHOW PROFILE的耗时不等于真实耗时？
SHOW PROFILE输出的Duration字段，本质是各执行阶段（如starting、executing）的估算时间，不包含网络传输、客户端接收、锁等待等环节，且不同版本统计粒度差异大。
- 执行
SET profiling = 1后跑SQL，再SHOW PROFILES，看到的Duration常比慢日志少50~200ms——差的就是TCP回包和客户端解析时间 -
SHOW PROFILE CPU FOR QUERY N里的cpu_user和cpu_system只反映CPU时间片，I/O等待、上下文切换全不计入 - 并发场景下，
Duration会被其他线程干扰，尤其当buffer pool刷脏页或purge线程活跃时，数值完全失真
真正要归因单条SQL耗时，必须把慢日志的Query_time、performance_schema的TIMER_WAIT、以及EXPLAIN里的rows和Extra三者对照着看——Query_time告诉你“花了多久”，TIMER_WAIT告诉你“在哪花的”，rows和Extra才告诉你“为什么花”。漏掉任意一环，优化就是蒙眼打靶。
