复合索引应按高选择性列优先原则设计，如idx_user_status_time(user_id,order_status,created_at)可覆盖多类查询，但WHERE仅含低区分度字段时无效；唯一索引uk_order_no必须用于order_no防重复；JOIN外键order_id须建索引；索引过多会拖慢写入性能。
WHERE条件里总查user_id和order_status？先建复合索引
高频查询如果固定组合多个字段，比如“查某个用户的待支付订单”，WHERE user_id = ? AND order_status = 1，单列索引效果有限。这时必须用复合索引，且顺序不能错：高选择性列放前面。
常见错误是把低区分度字段（如order_status只有0/1/2）放在前面，导致索引利用率低。正确做法是把user_id放第一，再跟order_status和created_at：
ALTER TABLE orders ADD INDEX idx_user_status_time (user_id, order_status, created_at);- 这个索引能覆盖
WHERE user_id = ?、WHERE user_id = ? AND order_status = ?、WHERE user_id = ? AND order_status = ? ORDER BY created_at DESC三种场景 - 但
WHERE order_status = ?或WHERE created_at > ?完全用不上它
ORDER BY created_at慢？别单独建索引
单纯为排序字段加索引（比如只对created_at建索引）在高并发订单表里基本无效——MySQL无法用它加速带WHERE的查询，除非WHERE条件也命中该索引。
真正要解决“按时间查最新订单”这类需求，得把排序字段塞进复合索引末尾，并确保前缀能被WHERE用上：
- 如果查询是
WHERE user_id = ? ORDER BY created_at DESC LIMIT 10，idx_user_created (user_id, created_at)就能避免filesort - 如果查询还带
order_status过滤，就扩展为(user_id, order_status, created_at)，注意created_at必须在最后 - 不要建
(created_at, user_id)——最左前缀失效，WHERE user_id = ?根本用不到
唯一订单号查询总走全表扫描？立刻加唯一索引
order_no是外部系统调用的核心字段，但很多人只设了普通INDEX甚至没建索引，导致每次查订单详情都全表扫。
必须用UNIQUE KEY，不是普通INDEX：
ALTER TABLE orders ADD UNIQUE KEY uk_order_no (order_no);- 唯一约束自带索引，且能防止重复写入，一箭双雕
- 如果已有重复数据，先清理再执行，否则会报
Duplicate entry错误 - 别用
INDEX代替——虽然也能提速，但不保证业务唯一性，后续可能引发资损
JOIN order_items时卡顿？外键字段必须有索引
查订单+明细时，orders JOIN order_items ON orders.id = order_items.order_id，如果order_items.order_id没索引，就会触发嵌套循环+全表扫描，数据量一过百万，响应直接秒变十几秒。
这不是可选项，是硬性要求：
ALTER TABLE order_items ADD INDEX idx_order_id (order_id);- 如果还常按
product_id查明细，再加(order_id, product_id)复合索引 - 检查
EXPLAIN输出里type是否为ref或eq_ref，不是就说明索引没生效 - 别指望主键自动优化JOIN——
order_items的主键可能是id，但JOIN用的是order_id，必须显式建索引
INSERT和UPDATE。上线前务必用真实流量压测写入性能，尤其注意分库分表后跨分片查询无法走索引这个死结。 
