TIMESTAMP字段加索引有效，但需避免时区转换干扰和函数包裹（如DATE()），否则因隐式类型转换或无法匹配UTC存储值导致索引失效；正确做法是用范围查询替代函数操作。
Timestamp 字段加索引有用，但必须避开时区转换和函数包裹这两个坑，否则索引根本不会被用上。
为什么 TIMESTAMP 字段索引容易失效
MySQL 的 TIMESTAMP 类型在写入时会自动转成 UTC 存储，读取时再按当前会话时区转回。这个隐式转换本身不破坏索引，但一旦你在 WHERE 条件里对字段套函数（比如 DATE(created_at) 或 FROM_UNIXTIME(created_at)），优化器就无法走索引了——因为索引是按原始存储值（UTC）建的，而函数输出的是会话时区下的结果。
- 常见错误写法：
WHERE DATE(created_at) = '2026-04-18'→ 全表扫描 - 正确写法应是范围比较：
WHERE created_at >= '2026-04-18 00:00:00' AND created_at - 注意：这里的字符串字面量会被 MySQL 按当前会话时区解释，再转成 UTC 去匹配索引值
CREATE INDEX 语句要带 NOT NULL 和显式类型
虽然 TIMESTAMP 默认允许 NULL，但索引中 NULL 值不参与 B+ 树排序，且可能影响 MRR（Multi-Range Read）优化效果。建议建索引前确认字段是否可为空：
- 如果业务上绝不为空，建索引时加上
NOT NULL约束更稳妥 - 建索引语句示例：
CREATE INDEX idx_created_at ON orders(created_at) - 避免用
ALTER TABLE ... ADD INDEX而不指定名称，会导致后续维护困难（如删索引时得查SHOW INDEX FROM orders） - 复合索引慎用：除非查询总是同时过滤时间 + 其他字段（如
status），否则单列索引更轻量、更易命中
EXPLAIN 必须看 type 和 key 列
加完索引不能只靠“快了”来判断是否生效，得用 EXPLAIN 看执行计划：
- 关键指标：
type应为range或ref，key显示你刚建的索引名（如idx_created_at） - 如果
type = ALL，说明没走索引；如果key = NULL，说明优化器主动弃用了索引 - 特别注意
Extra列：出现Using filesort或Using temporary说明排序/分组逻辑没被索引覆盖，可能需要调整查询或加覆盖索引 - 测试时用真实时间范围，别用
CURDATE()这类函数——它本身不导致索引失效，但会让EXPLAIN显示预估行数不准
MRR 优化在时间范围查询中默认开启但有前提
MySQL 5.6+ 默认启用 MRR（Multi-Range Read），对 BETWEEN 或 >= AND 这类范围查询有明显加速，但它依赖两个条件：
- 必须使用二级索引（比如你给
created_at建的索引），且查询需回表（即 SELECT 的字段不在索引里） -
read_rnd_buffer_size参数不能太小（默认 256KB），否则缓冲区满得早，排序+顺序读的优势打折扣 - 可通过
SELECT @@optimizer_switch确认mrr=on和mrr_cost_based=on是否启用 - 如果发现范围查询仍慢，先检查
read_rnd_buffer_size是否被其他大查询挤占，而不是急着换分区表
真正卡住性能的，往往不是没建索引，而是查询写法绕过了索引，或者索引建在了错误的时区上下文里。每次改完记得用 EXPLAIN 对比，别信感觉。
