qps衡量每秒执行的sql语句数（questions/秒），tps衡量每秒完成的事务数（com_commit+com_rollback/秒）；二者需用两次采样差值计算，不可用uptime作分母。
QPS 和 TPS 到底在量什么？别把它们当数字看
QPS 和 TPS 是 MySQL 最常被监控、也最容易被误解的两个基础指标：QPS 衡量的是「每秒执行了多少条 SQL 语句」，TPS 衡量的是「每秒完成了多少个事务」。关键区别在于——QPS 包含所有 SELECT、INSERT、UPDATE、DELETE 等语句，而 TPS 只统计真正提交或回滚的事务（即 Com_commit + Com_rollback）。一个事务里可能包含多条语句，所以 QPS 通常远高于 TPS。
实操时直接用这两个公式：
-
QPS = Questions / seconds，查SHOW GLOBAL STATUS LIKE 'Questions'，不是Queries（后者含内部语句，不准） -
TPS = (Com_commit + Com_rollback) / seconds，查SHOW GLOBAL STATUS LIKE 'Com_commit'和SHOW GLOBAL STATUS LIKE 'Com_rollback'
常见错误是拿 Uptime 当分母——它代表 MySQL 运行总时长，不能用于计算瞬时速率；正确做法是间隔固定秒数（如 10 秒）两次采样，做差值再除以时间差。
Buffer 命中率低 ≠ 一定要调大 buffer_size
InnoDB 缓冲池命中率低于 95%、key_buffer 命中率低于 99%，确实提示缓存不够用，但盲目增大 innodb_buffer_pool_size 或 key_buffer_size 很可能引发 OOM 或 swap 颠簸。MyISAM 表已基本淘汰，key_buffer_size 在纯 InnoDB 场景下几乎无意义；而 innodb_buffer_pool_size 虽然建议设为物理内存的 50%–75%，前提是系统没跑其他吃内存的服务（比如 Java 应用、Redis）。
更务实的做法是先确认是不是“缓存污染”：
- 检查
innodb_buffer_pool_read_requests和innodb_buffer_pool_reads：如果后者突增，说明大量数据页没命中，得看是不是有未加索引的大范围ORDER BY或JOIN - 用
SELECT * FROM sys.schema_unused_indexes（需启用performance_schema）找长期不用的索引，删掉它们能显著减少缓冲池压力 - 避免在 OLTP 场景中执行全表扫描类报表查询，这类请求会把热数据挤出缓冲池
Query Cache 已废弃，别再配 query_cache_size
MySQL 8.0 已彻底移除 Query Cache（QC），5.7 也默认关闭；即使你还在用 5.6，也该停用它。原因很实在：QC 的失效逻辑是「只要表有任意写入，所有涉及该表的缓存全清」，高并发更新场景下，缓存命中率常低于 10%，反而因维护哈希表和锁带来额外开销。
如果你看到监控里 Qcache_hits 数值很高，大概率是业务读多写少且 SQL 模板高度重复——但这恰恰说明应用层更适合做缓存（比如 Redis），而不是依赖 MySQL 自带的 QC。
- 禁用方式：配置文件中设
query_cache_type = 0，并把query_cache_size = 0 - 替代方案：用
SELECT SQL_NO_CACHE ...显式跳过 QC（仅调试用），或改用应用级缓存控制粒度 - 注意：
SQL_CACHE语法在 8.0+ 已报错，不要在代码里硬编码
别只盯着 QPS/TPS，Innodb_row_lock_waits 才是并发卡点真凶
当 QPS 上不去、响应变慢，但 CPU 和 I/O 都不高的时候，大概率是锁争用。这时候看 SHOW GLOBAL STATUS LIKE 'Innodb_row_lock_%' 比看 QPS 有用得多：Innodb_row_lock_waits 表示发生行锁等待的次数，如果每秒超过几次，就得查具体是哪张表、哪个事务在堵着。
- 快速定位：执行
SELECT * FROM information_schema.INNODB_TRX\G查当前长事务；再用SELECT * FROM information_schema.INNODB_LOCK_WAITS\G看谁在等谁 - 典型诱因：未走索引的
UPDATE或DELETE会升级为间隙锁（Gap Lock），导致无关记录也被锁住 - 规避手段：确保 WHERE 条件字段都有高效索引；避免在事务里做 HTTP 调用或 sleep；短事务优先，拆大事务为小批次
调优从来不是调几个参数就完事——QPS 和 TPS 是结果，不是原因；真正要盯的，是那些让语句卡住、让连接堆积、让缓冲池失效的具体行为。
