高并发查询优化需从查询、表结构、执行计划和系统配置四层面协同调整，核心是减少锁争用、降低单次开销、避免全表扫描及合理缓存。
高并发查询优化不是堆硬件或加索引就能解决的，核心在于减少锁争用、降低单次查询开销、避免全表扫描和合理利用缓存。关键要从查询本身、表结构、执行计划和系统配置四个层面协同调整。
精准识别慢查询与瓶颈点
不能靠“感觉”判断哪条 SQL 慢。先开启慢查询日志（slow_query_log=ON），设置合理阈值（如 long_query_time=0.1），再结合pt-query-digest 分析日志，找出 QPS 高 + 平均响应时间长的 Top SQL。同时用 SHOW PROCESSLIST 或information_schema.PROCESSLIST观察是否大量线程处于 Sending data、Locked 或Copying to tmp table状态——这些是典型瓶颈信号。
索引不是越多越好，而是要“刚刚好”
高频 WHERE 条件字段必须有索引，但要注意：
- 联合索引遵循最左前缀原则，比如 (user_id, status, create_time) 能加速 WHERE user_id = ? AND status = ?，但对WHERE status = ? 无效
- 避免在索引列上做函数操作，如 WHERE YEAR(create_time) = 2024 会跳过索引；应改写为WHERE create_time BETWEEN ‘2024-01-01’ AND ‘2024-12-31’
- 区分度低的字段（如gender、is_deleted）单独建索引意义不大，可考虑作为联合索引的后缀位
- 定期用 EXPLAIN 验证执行计划，重点看 type 是否为 ref/range、key 是否命中预期索引、rows是否明显偏大
减少锁冲突与事务粒度
高并发下锁等待是性能杀手。尽量做到：
- 读操作优先走 READ COMMITTED 隔离级别，避免间隙锁；写操作避免长事务，UPDATE/DELETE 务必带明确主键或唯一索引条件
- 拆分大事务：比如批量更新 10 万条记录，改成每次 1000 条 + 短事务循环，配合 COMMIT 释放行锁
- 写操作避免 SELECT … FOR UPDATE 无必要加锁；如需校验后写入，可用 INSERT … ON DUPLICATE KEY UPDATE 或REPLACE INTO替代“查 - 判 - 写”三步逻辑
- 热点行更新（如账户余额）考虑用应用层队列削峰，或数据库层用 乐观锁（version 字段）代替悲观锁
查询语句与结果集瘦身
很多性能问题出在 SQL 写法本身：
- 禁止SELECT *，只取业务真正需要的字段，尤其避开 TEXT/BLOB 类大字段
- 分页慎用OFFSET，深度分页（如LIMIT 100000, 20）会导致全表扫描；改用游标分页（如WHERE id > last_seen_id ORDER BY id LIMIT 20）
- 避免子查询嵌套过深，JOIN 表数控制在 3 张以内；关联字段类型、字符集、排序规则必须完全一致，否则无法走索引
- 聚合统计类查询（如实时 UV/PV）考虑预计算 + 定时刷新，或用 Redis HyperLogLog 等近似算法替代精确 COUNT(DISTINCT)
不复杂但容易忽略——调优不是一锤子买卖。上线后持续监控 InnoDB Row Operations、Key Buffer Hit Rate、Threads_connected 等指标，结合业务增长节奏动态调整。
