MySQL 读性能在高并发场景下容易成为瓶颈，核心优化方向是减少单次查询耗时、降低锁竞争、提升缓存命中率，并合理分担数据库压力。关键不在于堆硬件，而在于精准识别瓶颈点并针对性调整。
定位真实瓶颈：先看慢日志和执行计划
很多“高并发读慢”实际是少数慢查询拖垮整体。务必开启慢查询日志（slow_query_log=ON），设置合理阈值（如 long_query_time=0.1），定期分析 top SQL。对高频查询逐条用 EXPLAIN 查看执行计划，重点关注：
是否走了预期索引（key 列非 NULL） 扫描行数（rows）是否远超返回行数 是否有 Using filesort 或 Using temporary索引优化：少而精，覆盖常用查询路径
避免“一个表一堆索引”，重点优化 QPS 高、响应时间长的查询。原则包括：
联合索引遵循最左前缀，把区分度高、常用于 WHERE 的字段放前面 尽量用覆盖索引（SELECT 字段全在索引中），避免回表 删除长期未被使用的索引（可通过 performance_schema.table_io_waits_summary_by_index_usage 查看） 对范围查询（如 BETWEEN、>），索引字段放在联合索引末尾查询与连接层优化：减负 + 复用
应用端直接影响数据库负载：
禁止 SELECT *，只查必需字段 分页慎用 OFFSET，大数据量改用游标分页（如 WHERE id > last_id LIMIT 20） 连接池配置合理（如 HikariCP 的 maximumPoolSize 避免远超 MySQL max_connections） 读写分离：将报表、后台等非强一致性查询路由到从库缓存与架构级分流：别让所有读都压到 MySQL
数据库不是万能缓存：
应用层加本地缓存（如 Caffeine）缓存热点小数据（用户配置、字典项） 引入 Redis 缓存复杂查询结果，注意设置合理过期策略和缓存穿透防护 静态化页面或接口结果（如商品详情页），通过消息队列异步更新 考虑读多写少场景下使用 MySQL Group Replication 或 ProxySQL 实现自动读写分离与负载均衡不复杂但容易忽略——多数高并发读问题，80% 出在慢查询+缺失索引+应用层无节制请求。先抓慢日志，再调索引，最后才考虑加缓存或扩容。
