MySQL性能瓶颈通常出现在四个核心环节：磁盘I/O、CPU、锁竞争和连接/网络。不是所有慢都是SQL写得差，很多问题藏在资源调度和配置底层。
磁盘I/O瓶颈：最常见也最容易被低估
当查询需要频繁读写磁盘（尤其是机械硬盘），响应就会明显变慢。典型表现是InnoDB缓冲池命中率低于95%，iostat显示%util持续接近100%，或slow.log里大量“Using temporary; Using filesort”。常见诱因包括：
innodb_buffer_pool_size设置过小，无法缓存热数据 日志文件（ib_logfile）与数据文件共用同一块物理磁盘 未开启innodb_flush_method=O_DIRECT，导致双重缓存 大字段（如TEXT、BLOB）未分离存储，拖慢整行读取CPU瓶颈：计算密集型操作的信号灯
CPU使用率长期高于80%，且top中mysqld进程占主导，说明数据库正在做大量计算。这往往不是因为数据量大，而是因为：
复杂函数运算：如WHERE YEAR(create_time) = 2024（导致索引失效） 无索引JOIN或ORDER BY + LIMIT组合未命中覆盖索引 全表扫描后还要做GROUP BY或DISTINCT（临时表+排序全在内存/CPU完成） 大量短连接反复解析SQL（可考虑启用query_cache或升级到8.0+的prepared statement缓存）锁竞争瓶颈：高并发下的隐形卡点
用户反馈“有时快有时卡”，且卡顿集中在写操作附近，大概率是锁问题。InnoDB虽默认行锁，但以下情况仍会升级为表级或引发等待：
UPDATE或DELETE语句未走索引，触发全表扫描并加间隙锁 长事务未及时提交，持锁时间过长（SHOW ENGINE INNODB STATUS里可见lock wait） 唯一索引冲突重试（如INSERT IGNORE重复键）引发隐式锁等待 READ-COMMITTED以上隔离级别下，MVCC版本链过长拖慢SELECT连接与网络瓶颈：常被忽略的“最后一公里”
应用端报“Connection refused”或“Too many connections”，不一定是max_connections设小了，更可能是：
wait_timeout或interactive_timeout太短，连接被服务端主动断开，客户端重连逻辑混乱 应用未复用连接（如PHP短生命周期每次new PDO），造成TIME_WAIT堆积 跨机房部署时，单次查询网络RTT达20ms以上，叠加多轮交互（如N+1查询）放大延迟 MySQL未绑定内网IP，请求经NAT或防火墙策略限速定位时别跳步：先开slow_query_log + long_query_time=1，再看show global status里的Threads_connected、Innodb_row_lock_waits、QPS/TPS趋势，最后用EXPLAIN验证关键SQL执行路径。改参数前，务必确认瓶颈真实存在——调大buffer_pool对锁争用毫无帮助，就像给堵车路口加宽车道却不管红绿灯配时。
