高并发下索引失效比慢查询更致命，因其导致大量请求并发冲击磁盘i/o，挤爆buffer pool、打满连接数，引发雪崩；常见原因包括隐式类型转换、函数包裹字段、最左前缀未对齐。
为什么高并发下索引失效比慢查询更致命
因为失效的索引会让大量请求同时落到磁盘 I/O，瞬间把 innodb_buffer_pool 挤爆，连接数打满，进而引发雪崩。不是查得慢，是查得“一起卡”。常见诱因包括：隐式类型转换（比如 WHERE user_id = '123' 对 int 字段）、函数包裹字段（WHERE DATE(create_time) = '2024-01-01'）、或最左前缀没对齐（联合索引 (a,b,c) 却只查 WHERE b = 1）。
联合索引字段顺序必须按「过滤强度 + 查询频率」排
不能只看 WHERE 条件出现顺序。比如订单表常查 WHERE status = ? AND shop_id = ? AND created_at > ?，但 status 只有 3–5 个枚举值，而 shop_id 有十万级区分度——这时索引应建为 (shop_id, status, created_at)，而非照搬 SQL 顺序。否则 status 在前会导致索引选择性极低，优化器大概率放弃走索引。
实操建议：
- 用
SELECT COUNT(DISTINCT col)/COUNT(*) FROM table算选择性，>0.1 才算高区分度 - 把等值查询字段放前面，范围查询（
>,BETWEEN）放最后，避免截断后续字段的索引能力 - 如果存在
ORDER BY，尽量让排序字段也落在索引后缀中，避免额外 filesort
覆盖索引能直接消除回表，但别盲目加所有 SELECT 字段
回表是高并发下的性能黑洞——每行都要回到聚簇索引取数据，随机 I/O 爆增。用 EXPLAIN 看 Extra 列是否含 Using index 可确认是否覆盖。
系统功能强大、操作便捷并具有高度延续开发的内容与知识管理系统，并可集合系统强大的新闻、产品、下载、人才、留言、搜索引擎优化、等功能模块，为企业部门提供一个简单、易用、开放、可扩展的企业信息门户平台或电子商务运行平台。开发人员为脆弱页面专门设计了防刷新系统，自动阻止恶意访问和攻击；安全检查应用于每一处代码中，每个提交到系统查询语句中的变量都经过过滤，可自动屏蔽恶意攻击代码，从而全面防止SQL注入攻击
但注意：
- 覆盖索引越宽，B+ 树层级越深、内存占用越大，写入性能下降明显
- 只把高频查询中「固定且稳定」的返回字段加入索引，比如
SELECT order_no, status, updated_at就建(shop_id, status, updated_at, order_no) - 千万别把
TEXT或大VARCHAR字段塞进索引——会触发Row size too large错误
高并发写多读少场景慎用普通二级索引
每个二级索引插入都要更新 B+ 树+维护 change buffer，并发写入时容易在 dict_sys->mutex 上争抢，导致 innodb_row_lock_waits 暴涨。真实案例：某订单流水表加了 4 个二级索引后，QPS 从 8000 掉到 2200。
可考虑：
- 写入路径剥离：用 Kafka 异步落库，主表只保留必要字段和主键，索引精简到 1–2 个
- 读写分离 + 索引差异化：从库建更多索引，主库只保核心查询路径
- 用
innodb_adaptive_hash_index=OFF降低热点页冲突（尤其 SSD 环境下收益明显）
真正难的不是加索引，是判断哪些查询值得索引、哪些该用缓存兜底、哪些干脆改查询逻辑——比如把 SELECT * FROM orders WHERE user_id IN (…) 拆成多次单 ID 查询，反而比一个宽索引更稳。
