不能真正“实时”，它只记录当前会话中已执行完（或中断）的语句，且默认关闭、有容量限制（最多保存15条），不适合长期监控。
show profiles 能不能实时看 SQL 耗时？
不能真正“实时”，它只记录当前会话中已执行完（或中断）的语句，且默认关闭、有容量限制（最多保存 15 条），不适合长期监控。你执行 SHOW PROFILE 时看到的是上一条语句的各阶段耗时，比如 executing、Sorting result、Sending data 等，但前提是这条语句已经结束。
常见误用场景：
- 在长事务或大导入过程中反复执行
SHOW PROFILE，结果始终显示旧语句——因为新语句还没结束，profile 不会更新 - 开启后没注意
show profiles列出的 Query_ID，直接show profile查了错的 ID - 忘记
SET profiling = 'ON'是会话级的，新连接需重设
临时调试单条慢查询可以，但别指望靠它盯住一个正在跑的 LOAD DATA 或 UPDATE 进度。
performance_schema 是不是更靠谱的实时方案？
是，但得配对启用，否则查 performance_schema.events_statements_current 会全是空。MySQL 5.6+ 默认部分启用，但 stage 和 statement 的采集常被关着。
必须执行的初始化步骤：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE 'statement/%';UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE 'stage/%';UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_statements_current', 'events_stages_current');
之后才能查到当前活跃语句：
SELECT THREAD_ID, SQL_TEXT, TIMER_WAIT/1000000000 AS time_sec FROM performance_schema.events_statements_current WHERE SQL_TEXT IS NOT NULL AND CURRENT_SCHEMA = 'your_db';
注意：TIMER_WAIT 是纳秒单位，要除以 1000000000 才是秒；如果值为 NULL，说明该语句还没开始执行或已被清理。
为什么查不到刚执行的 INSERT/UPDATE 的实时耗时？
因为 performance_schema.events_statements_current 只存“当前正在执行”的语句快照，而很多 DML 在 InnoDB 内部会拆成多个 stage（如 updating table、end），且 stage 级别数据默认不持久化——一旦语句结束，stage 记录就从 events_stages_current 消失，只留在 events_stages_history_long（需提前开对应 consumer）。
所以实际看到的“耗时”往往是零或极小值，除非你手动加 SLEEP(1) 并在 sleep 阶段去查，否则很难捕获中间态。更现实的做法是结合：
-
SHOW FULL PROCESSLIST看Time列（单位秒，是线程处于当前状态的持续时间，非 SQL 总耗时） -
SELECT * FROM sys.session WHERE COMMAND = 'Query'（sys schema 封装了 performance_schema，可读性更好） - 对大操作加
/*+ MAX_EXECUTION_TIME(30000) */主动限流，避免失控
production 环境该选哪个？
别用 show profiles：它已被标记为 deprecated，MySQL 8.0 文档明确说“will be removed in a future MySQL release”。
优先走 performance_schema + sys 视图，但必须确认三点：
- 配置项
performance_schema = ON已在 my.cnf 中启用（重启生效） -
events_statements_history_longconsumer 开启，否则历史语句查不到 - 避免高频轮询
events_statements_current，它会带来可观的性能开销，尤其在高并发下
真正需要“实时进度”的场景（比如导入百万行），performance_schema 也给不出精确百分比——它不跟踪已处理行数，只能靠外部工具解析 binlog position 或估算文件偏移量。这点最容易被忽略。
