时间字段应置于联合索引末尾以避免截断右侧列，但前提是前导列需高频、高选择性；若前导列低区分度（如status），即使时间在后，索引仍可能失效。
时间字段放在联合索引末尾，但不能默认“靠后就安全”
时间范围查询（如 created_at BETWEEN '2026-01-01' AND '2026-10-31' 或 updated_at > NOW() - INTERVAL 7 DAY）本身不排斥索引，但会截断右侧所有列——这是硬限制，不是优化建议。所以把时间字段放最后，只是让截断影响最小化，前提是它前面的列能真正过滤掉大部分数据。
常见错误是建了 idx_status_created(status, created_at)，结果发现 status 只有 3–5 个取值（低基数），created_at 范围一加，MySQL 得扫描几十万行再过滤，索引形同虚设。
- 先确认前导列是否高频且高区分度：比如
user_id、tenant_id、order_no这类字段，基数高、WHERE 中出现率 >80% - 避免用
status、is_deleted、gender等低区分度字段做最左列，除非它们在业务中确实承担了主过滤角色（如多租户系统中tenant_id就是天然高基数） - 如果时间字段必须参与等值查询（如按天分区汇总），可考虑
DATE(created_at)表达式索引（MySQL 8.0+），但注意函数索引无法用于WHERE created_at > ...这类原生范围
当 WHERE 中跳过中间列时，时间字段完全失效
假设你建了 idx_user_status_created(user_id, status, created_at)，但某次查询只写 WHERE user_id = 123 AND created_at > '2026-01-01'，那 created_at 不会走索引——B+ 树里 user_id = 123 的子树中，status 值是乱序的，created_at 更不可能连续。
这不是 MySQL 优化器不够聪明，而是 B+ 树结构决定的物理事实。优化器重排条件顺序也救不了它。
- 需要这类查询，就得单独建
idx_user_created(user_id, created_at) - 不要指望一个索引覆盖所有排列组合；索引是为具体 SQL 服务的，不是为“可能有”的查询预留的
- 用
EXPLAIN看key_len：如果预期用上两列但key_len只显示第一列长度，基本就是中间列被跳过了
LIKE 'prefix%' 和时间范围混用时，时间列仍会失效
LIKE 'abc%' 属于等值延伸，不触发截断，但它只对当前列有效。比如 idx_name_created(name, created_at) 配合 WHERE name LIKE 'zhang%' AND created_at > '2026-01-01'，name 能用，created_at 依然不能用——因为 LIKE 'zhang%' 在 B+ 树里仍是范围扫描（从 'zhang' 开始到 'zhangzzz...' 结束），不是精确点查。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
换句话说：LIKE 'prefix%' 和 >、BETWEEN 一样，都算范围操作，都会导致其右侧列索引失效。
- 若业务真要同时按前缀 + 时间查，且性能敏感，考虑冗余字段：比如从
name提取name_prefix（前 3 字符），建等值索引(name_prefix, created_at) - 或者改用全文索引（
FULLTEXT）处理模糊前缀，但那是另一套机制，不走 B+ 树 - 切记：
LIKE '%xxx'或LIKE '%xxx%'会让整个联合索引失效，连最左列都用不上
ORDER BY 时间字段时，联合索引能否避免 filesort？
能，但有条件。比如查询 SELECT * FROM orders WHERE user_id = 123 ORDER BY created_at DESC，如果索引是 idx_user_created(user_id, created_at)，就能直接利用索引有序性，无需 filesort。
但如果索引是 idx_user_status_created(user_id, status, created_at)，而查询是 WHERE user_id = 123 AND status = 1 ORDER BY created_at DESC，同样可以避免排序——因为 user_id 和 status 是等值，created_at 在索引中天然有序。
- 关键看 ORDER BY 字段是否是索引的“连续后缀”，且前导列都是等值条件
- 如果 ORDER BY 包含多个字段，比如
ORDER BY status, created_at，那索引必须是(user_id, status, created_at)才能覆盖；(user_id, created_at, status)就不行 - DESC/ASC 要和索引定义一致（MySQL 8.0+ 支持混合方向，但老版本建议统一）
时间字段在联合索引里的位置，从来不是由“它是不是时间”决定的，而是由它在真实查询中扮演的角色决定的：是等值过滤？范围过滤？还是排序依据？漏掉这个判断，光记“时间放后面”，反而会埋下更隐蔽的性能坑。
