WHERE条件中对TIMESTAMP字段使用DATE()或HOUR()会导致索引失效，因优化器无法匹配函数输出；应改用范围查询，如created_at >= '2026-04-18 00:00:00' AND created_at

WHERE条件里别对TIMESTAMP字段套DATE()或HOUR()

索引失效最常见原因就是写成 WHERE DATE(created_at) = '2026-04-18' 或 WHERE HOUR(created_at) = 14。MySQL优化器无法用索引去匹配函数输出结果，因为索引建在原始 UTC 存储值上，而 DATE() 返回的是当前会话时区下的日期字符串。

正确做法是改用范围比较：

• WHERE created_at >= '2026-04-18 00:00:00' AND created_at
• 字符串字面量会被 MySQL 按当前 time_zone 解释，再自动转成 UTC 去查索引
• 如果应用连接的 time_zone 是 '+08:00'，那上面语句实际等价于查 UTC 时间 2026-04-17 16:00:00 到 2026-04-18 16:00:00

建索引前先确认会话时区是否稳定

如果应用没显式设置 time_zone，MySQL 会用全局默认值（可能是 SYSTEM），一旦服务器时区变更，同样一条查询可能查出不同结果，甚至让索引选择路径变复杂。

检查和控制方式：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 查当前会话时区：SELECT @@time_zone;
• 临时切时区测试：SET time_zone = '+08:00';
• 上线前统一在连接池初始化 SQL 里加：SET time_zone = '+08:00';
• 避免依赖 SYSTEM，它受操作系统影响，不可控

别用UNIX_TIMESTAMP()包裹字段来建函数索引

有人想“把 TIMESTAMP 转成整数加快查”，于是写 CREATE INDEX idx_ts_int ON t (UNIX_TIMESTAMP(created_at))。这看似合理，但实际几乎没用：

• UNIX_TIMESTAMP(created_at) 是运行时计算，MySQL 5.7+ 才支持函数索引，且必须用 GENERATED COLUMN + INDEX 组合，不能直接对函数建索引
• 即使建成了，每次查询还得写成 WHERE UNIX_TIMESTAMP(created_at) BETWEEN 1744838400 AND 1744924800，应用层必须自己做时区转换，极易出错
• 原生 created_at 字段已有 B+ 树索引，范围查询性能已足够好，没必要绕路

TIMESTAMP索引本身有效，但要注意NULL值和精度

TIMESTAMP 加索引是有效的，但有两个细节常被忽略：

• 如果字段允许 NULL，索引中该值不参与排序，IS NULL 查询走不了索引范围扫描，只能全表扫
• 带微秒精度（如 TIMESTAMP(3)）时，索引键长变大，B+ 树层级略深，但对百万级以下表影响可忽略
• 建索引建议显式声明：CREATE INDEX idx_created_at ON t (created_at) USING BTREE;，不依赖隐式行为

真正容易翻车的地方不在语法，而在时区漂移——同一行数据，在不同时区连接下执行相同范围查询，可能命中或错过同一条记录，而你从 EXPLAIN 看不出异常。