convert_tz作用于索引列会导致索引失效，必须将时区转换移至值侧（如将目标时间转为utc再比较）；字段存utc是最佳实践，否则统一按本地时间查询，避免对字段应用函数。

WHERE子句里用CONVERT_TZ导致索引失效

只要CONVERT_TZ作用在索引列上，比如WHERE CONVERT_TZ(created_at, '+00:00', '+08:00') > '2026-10-01'，B+树就完全无法跳查——MySQL必须对每行执行函数计算，EXPLAIN里key一定为NULL，type退化成ALL或index。

真正能走索引的写法，是把时区转换逻辑从字段侧移到值侧：

• 原表created_at存的是UTC时间（推荐），查询时把目标时间转成UTC再比较：WHERE created_at > CONVERT_TZ('2026-10-01 00:00:00', '+08:00', '+00:00')
• 如果字段存的是本地时间（如+08:00），且不能改存储格式，那就统一按本地时间写条件：WHERE created_at > '2026-10-01 00:00:00'，别碰字段本身
• ORM里尤其注意：MyBatis的#{} 会自动加引号，但若拼接CONVERT_TZ进SQL字符串，等于主动把函数塞到字段上

子查询返回时间字段后JOIN引发隐式转换

嵌套查询中，若子查询结果集的时间字段SELECT created_at FROM logs WHERE ...和外层表的created_at字段时区信息不一致（比如一个是TIMESTAMP带时区语义，一个是DATETIME无时区），MySQL在JOIN或IN时会悄悄做类型对齐，触发隐式转换。

验证方法不是看EXPLAIN，而是查真实类型：

• 查子查询列类型：SHOW COLUMNS FROM (SELECT created_at FROM logs WHERE id ，确认<code>Type是否和主表一致
• 查连接层时区：SELECT @@time_zone, @@system_time_zone，确保应用连接时没被SET time_zone = 'SYSTEM'之类覆盖
• 临时修复可加CAST在字面量侧：ON a.created_at = CAST(b.created_at AS DATETIME)，但仅限紧急绕过，不能替代存储规范化

ALTER TABLE修改时间字段类型的风险点

想把DATETIME改成TIMESTAMP来统一时区行为？小心锁表和隐式语义变更。

• ALTER TABLE t MODIFY created_at TIMESTAMP会强制把现有值按当前@@time_zone解释再存入，历史数据可能偏移——例如原存'2026-01-01 12:00:00'在+08:00下，改完变成UTC时间戳，读出来就成'2026-01-01 04:00:00'
• 更安全的做法是新增created_at_utc字段，用UPDATE t SET created_at_utc = CONVERT_TZ(created_at, @@time_zone, '+00:00')批量补全，再建索引，最后灰度切查询逻辑
• MySQL 8.0.22+支持ADD COLUMN ... STORED生成列：ADD COLUMN created_at_utc TIMESTAMP AS (CONVERT_TZ(created_at, @@time_zone, '+00:00')) STORED，可直接在该列建索引

应用层传参时区不一致的典型表现

前端JS用new Date().toISOString()传'2026-10-14T12:34:56.789Z'，后端Java用LocalDateTime解析却没指定时区，入库变成系统默认时区（如+08:00）的DATETIME，查的时候再用CONVERT_TZ兜底——这整条链路都在制造索引失效机会。

关键控制点在参数绑定阶段：

• JDBC连接串必须显式加serverTimezone=UTC，否则TIMESTAMP字段会按JVM时区二次转换
• Spring Boot配置spring.jackson.time-zone=GMT+0和spring.jackson.date-format=yyyy-MM-dd HH:mm:ss，避免JSON反序列化丢时区
• 永远不要在SQL里写WHERE created_at > NOW()这种依赖连接时区的表达式；改用WHERE created_at > UTC_TIMESTAMP()或预计算好UTC时间传参

时区问题最麻烦的不是修SQL，而是字段存什么、连接用什么、应用读什么，三者稍有错位，索引就形同虚设。别指望一个CONVERT_TZ调用能救全场。