设置TIME_ZONE后MySQL大数据量查询性能异常问题问询

1. 索引失效导致全表扫描
   当执行SET TIME_ZONE = 'Asia/Dubai';后，CURDATE()和UNIX_TIMESTAMP()的计算会绑定当前会话时区。此时WHERE子句中的UNIX_TIMESTAMP(CURDATE() - INTERVAL 1 DAY)与UNIX_TIMESTAMP(CURDATE())属于行级动态计算——MySQL需要为devicesData表的每一行数据重新计算这两个函数的值，再与dd.createdAt做比较。这种情况下，dd.createdAt上的索引完全无法被利用，只能执行全表扫描，面对9万行数据必然出现卡顿。

而改用变量预计算的方式，start和end在查询执行前就已确定为固定UNIX时间戳，WHERE子句变成对固定值的范围匹配，MySQL可以直接使用dd.createdAt上的索引完成高效查询，性能自然大幅提升。

2. tzset()的底层开销
   SET TIME_ZONE会触发底层的tzset()调用，该函数需要加载并解析时区数据，在会话级别重置时区相关全局状态。如果存储过程频繁执行此操作，或服务器时区数据加载效率低下，会额外增加会话初始化开销。更关键的是，时区变更后，MySQL对时间函数的处理逻辑切换到新时区，原本可预计算的表达式变为动态计算，进一步放大了性能损耗。

3. LEFT JOIN的放大效应
   原查询使用LEFT JOIN，当时区导致全表扫描时，rooms与devicesData的关联操作会退化为嵌套循环的全表匹配，数据处理量呈几何级增长，最终出现卡顿甚至看似“无限循环”的情况——本质是查询执行时间过长，超出等待预期。

内容的提问来源于stack exchange，提问作者tugglan