mysql 5.7无法通过单一开关实现全链路sql追踪，必须组合general_log（记录原始语句）、slow_query_log（捕获慢/低效查询）和performance_schema（深度执行细节）三者协同，并手动对齐时间戳与线程id。
不能靠单一开关实现“全链路”——MySQL 5.7 没有类似 PostgreSQL 的 log_min_duration_statement + log_statement = 'all' 组合式全量记录能力。你必须按需组合多个日志机制，且每种日志覆盖不同层级、不同生命周期阶段。
哪些日志能覆盖SQL执行的哪个环节？
别指望一个配置打遍天下。MySQL 5.7 的日志是分层的，各司其职：
-
general_log：只记录“客户端发了什么”，不包含解析、优化、执行细节；开启后会记录所有语句（含SET、USE），但无法告诉你为什么慢、锁在哪、走了哪个索引 -
slow_query_log：只捕获超时（long_query_time）或未用索引（log_queries_not_using_indexes）的查询，漏掉大量“快但错”的语句（如误写WHERE 1=1导致全表扫描却耗时 0.2s） -
profiling：仅限当前会话，且已废弃（MySQL 8.0 移除），只能看到 CPU / IO 时间分布，看不到锁等待、InnoDB 行锁信息 -
error_log+innodb_print_all_deadlocks：只在死锁发生时输出事务快照，不记录普通执行流 -
performance_schema：唯一能接近“全链路”的方案，但默认关闭多数消费者（consumers）和仪器（instruments），需手动启用
真正可行的组合：general_log + performance_schema + slow_query_log
这是目前 MySQL 5.7 下最贴近“全链路”的实操路径，但必须明确各自边界：
- 开
general_log记原始语句：设log_output = 'TABLE'，避免文件 I/O 瓶颈；查SELECT * FROM mysql.general_log ORDER BY event_time DESC LIMIT 100快速回溯调用来源 - 开
slow_query_log捕异常耗时：设long_query_time = 0.5（OLTP 场景建议值），配合log_queries_not_using_indexes = ON，定位低效 SQL - 启用
performance_schema深度追踪：运行以下命令（需 SUPER 权限）：UPDATE performance_schema.setup_consumers SET enabled = 'YES' WHERE name LIKE 'events_statements%';<br>UPDATE performance_schema.setup_instruments SET enabled = 'YES', timed = 'YES' WHERE name LIKE 'statement/sql/%' OR name LIKE 'wait/lock/%' OR name LIKE 'wait/io/file/myisam/%';
之后查SELECT * FROM performance_schema.events_statements_history_long WHERE sql_text LIKE '%your_table%' ORDER BY end_time DESC LIMIT 20 - 注意：
performance_schema内存消耗随并发上升，events_statements_history_long默认仅保留 10000 行，高并发下可能被覆盖——不是丢日志，是被新事件顶掉
容易被忽略的三个硬限制
这些不是配置问题，而是 MySQL 5.7 架构本身决定的盲区：
- 存储过程内部逻辑不可见：即使开了
general_log，也只记 CALL 语句，不记过程体内的INSERT、UPDATE；必须像知识库说的那样，用INSERT INTO sp_debug_log手动埋点 - 查询重写（如隐式类型转换、函数索引失效）不会在日志中体现：你看到的是最终执行的
sql_text，但优化器实际改写的版本（比如把WHERE id = '123'转成WHERE id = 123）无从得知；得靠EXPLAIN FORMAT=JSON对比 - 事务内多语句的因果关系靠人工串连：
general_log里只有时间戳，没有 trace_id；performance_schema中的THREAD_ID可关联同一线程的语句，但跨连接（如应用层连接池复用）就断了——你得靠应用层传/*+ TRACE_ID=xxx */注释并解析日志
真正的难点不在开启日志，而在于把 mysql.general_log 的语句、performance_schema.events_statements_history_long 的执行耗时、information_schema.INNODB_TRX 的事务状态、以及你自己写的 sp_debug_log 表，按时间戳和线程 ID 对齐——这一步没有自动化工具，只能靠人盯。
