mysql高并发场景下性能瓶颈如何分析_mysql性能排查方法-mysql教程-PHP中文网

慢查询日志中的“慢”SQL未必真慢，可能是锁等待或资源争用所致；需检查long_query_time设置、线程状态、真实耗时语句、未提交事务、缓冲池命中率、连接数与线程池配置、索引失效及执行计划突变。

mysql高并发场景下性能瓶颈如何分析_mysql性能排查方法

看慢查询日志是不是真慢，还是被锁拖垮

高并发下 slow_query_log 里出现大量“慢”SQL，不一定是执行本身慢，更可能是等锁、等资源。先确认 long_query_time 设得太低（比如设成 0.1 秒），把本不该算“慢”的语句也记进去了；再查 SHOW PROCESSLIST 或 information_schema.PROCESSLIST，重点看 State 列：如果大量线程卡在 Waiting for table metadata lock 或 Locked，说明 DDL（如 ALTER TABLE）或长事务阻塞了其他查询。

用 SELECT * FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_TIMER_WAIT DESC LIMIT 10 找真实耗时高的语句（按归一化 digest 统计，比慢日志更准）
检查是否有未提交的事务：SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED LIMIT 5
禁用自动提交后忘记 COMMIT 是高频原因，尤其 ORM 框架中显式开启事务但异常路径未回滚

检查 InnoDB 缓冲池是否真的够用

innodb_buffer_pool_size 配得太小，会导致频繁磁盘读，高并发下 I/O 成瓶颈。别只看内存总量——它应占物理内存的 50%–75%，且必须大于活跃数据集（working set）。验证方法不是看配置值，而是看运行时指标：

查命中率：SHOW ENGINE INNODB STATUS\G 里找 Buffer pool hit rate，持续低于 99% 就危险
看页读写压力：SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%'，若 Innodb_buffer_pool_reads（物理读）远高于 Innodb_buffer_pool_read_requests（逻辑读请求），说明缓存失效严重
注意：MySQL 8.0+ 可用 performance_schema.memory_summary_global_by_event_name 查 buffer pool 内存实际使用分布

连接数和线程池是不是成了隐形瓶颈

并发连接数飙高时，max_connections 被打满只是表象，背后常是连接复用不足或连接泄漏。更隐蔽的问题是线程创建开销：默认每连接一个线程（thread-per-connection），当并发超几百，上下文切换和内存占用就压垮 CPU。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

先确认真实连接数：SHOW GLOBAL STATUS LIKE 'Threads_connected'，对比 max_connections；若长期接近上限，优先查应用层是否没关连接（如 Java 的 Connection.close() 被跳过）
MySQL 5.7+ 企业版支持线程池插件（thread_pool），社区版可用 thread_handling = pool-of-threads（8.0.14+），但需配合 thread_pool_size 调优（通常设为 CPU 核数）
避免短连接风暴：应用层务必启用连接池（如 HikariCP），并设好 maxLifetime 和 idleTimeout，防止连接僵死

索引失效和执行计划突变怎么快速定位

高并发场景下，一条 SQL 突然变慢，大概率是执行计划变了——可能因为统计信息过期、隐式类型转换、或 OR / NOT IN 导致索引失效。不能只看 EXPLAIN 输出，要抓真实执行时的计划。

强制查看实际执行计划：EXPLAIN FORMAT=JSON SELECT ...，重点关注 used_columns、key_length 和 filtered 字段，filtered 接近 100 表示索引过滤效果好
检查是否走了全表扫描：EXPLAIN 中 type 为 ALL 或 index，且 rows 远大于预期结果数
更新统计信息：ANALYZE TABLE table_name，但别在高峰期跑；生产环境建议用 innodb_stats_auto_recalc = ON + innodb_stats_persistent = ON

真正卡住高并发的，往往不是单条 SQL 多慢，而是某类操作（比如没加 WHERE 条件的 UPDATE、没走索引的 ORDER BY、或长事务持有间隙锁）在并发放大下形成雪崩。排查时少盯 QPS，多盯 Threads_running 和 Innodb_row_lock_waits 这类直接反映争用的指标。