SET timestamp=... 是 MySQL 慢查询日志自动添加的时间戳元信息，非执行SQL，不耗时；真正影响性能的是其后的业务语句，需重点关注 Query_time、Rows_examined 等指标。
SET timestamp=... 是 MySQL 自动注入的会话时间戳
这不是你写的 SQL，而是 MySQL 服务端在记录慢查询日志时自动补上的元信息。它表示该语句执行时的 UNIX_TIMESTAMP() 值，用于还原语句执行时的会话时区和时间上下文。只要开启了慢查询日志，几乎所有被记录的语句前都会带这一行 —— 包括 SELECT、INSERT、UPDATE，甚至空操作（比如只执行 SET 变量）。
为什么它总出现在慢日志里，却不是“慢”的原因
SET timestamp=... 本身不耗时，也不会触发索引扫描或锁等待。它只是日志格式的一部分，和真正的业务 SQL 是分离的。真正拖慢查询的是它后面那条语句（比如 SELECT ... FROM h_room_item LEFT JOIN ...）。如果你看到大量 SET timestamp 行，说明：
- 慢查询日志确实在工作，且记录了真实执行的语句
- 你可能误把这行当成“慢 SQL”本身去优化，其实该忽略它
- 如果日志里只有
SET timestamp而没有后续 SQL，大概率是客户端连接后没执行任何有效查询就断开了（比如连接池心跳探测）
log_queries_not_using_indexes 会导致 SET timestamp 单独出现
当启用 log_queries_not_using_indexes=1，MySQL 会把所有未走索引的查询都记进慢日志 —— 即使执行时间远低于 long_query_time。而这类查询往往附带一个 SET timestamp 行，但后面可能只跟一条简单语句（如 SELECT * FROM countries），甚至只是隐式事务开启语句。此时你会看到：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
# Query_time: 0.000215 Lock_time: 0.000003 Rows_sent: 25 Rows_examined: 25 SET timestamp=1712299482; select * from countries;
这种组合不是 bug，是配置行为。关键要看 Rows_examined 是否异常高，以及对应表是否有合适索引。
真正要盯住的是 Query_time 和 Rows_examined
日志中每条记录的性能线索藏在开头几行字段里，而不是 SET timestamp：
-
Query_time：纯执行耗时（不含锁等待），决定是否超long_query_time -
Lock_time：锁等待时间，高说明存在并发争抢 -
Rows_examined：扫描行数，远大于Rows_sent通常意味着缺少索引或索引失效 -
Rows_sent：实际返回行数，对比它和Rows_examined能快速判断效率
如果你发现某条 SELECT 的 Rows_examined 是几万甚至几十万，而 Rows_sent 只有几十，那问题一定出在 JOIN 条件、WHERE 过滤或索引设计上 —— SET timestamp 只是日志的“身份证”，别在它身上浪费排查时间。
