高并发查询优化需从查询、表结构、执行计划和系统配置四层面协同调整，核心是减少锁争用、降低单次开销、避免全表扫描及合理缓存。
高并发查询优化不是堆硬件或加索引就能解决的，核心在于减少锁争用、降低单次查询开销、避免全表扫描和合理利用缓存。关键要从查询本身、表结构、执行计划和系统配置四个层面协同调整。
精准识别慢查询与瓶颈点
不能靠“感觉”判断哪条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等指标，结合业务增长节奏动态调整。