核心语句
使用 SHOW STATUS
语法查询服务器性能指标:
SHOW [GLOBAL|SESSION] STATUS LIKE '参数';
常用性能参数列表
参数名 |
含义说明 |
---|---|
|
连接MySQL服务器的总次数 |
|
MySQL服务器已运行的时间(单位:秒) |
|
慢查询的次数(需关注优化) |
|
|
|
|
|
|
|
|
|
查询操作执行的次数 |
|
插入操作执行的次数(批量插入仅计数一次) |
|
更新操作执行的次数 |
|
删除操作执行的次数 |
关键用途
监控数据库负载(如连接数、运行时间)。
分析SQL执行频率(增删改查次数)。
定位性能问题(如慢查询数量、InnoDB引擎的行操作统计)。
MySQL 查询成本(Query Cost)核心笔记
一、last_query_cost 是什么
- 定义:系统状态变量,记录上一查询的预估 I/O 成本,由查询优化器计算
- 作用:优化器选执行计划(如索引、全表扫)的依据,对比不同计划 “成本”
- 单位:随机数据页读取次数,代表 “完成查询预计读多少磁盘块”
二、“高成本” 查询未必慢的原因
优化器按随机 I/O 模型估算,实际执行受物理机制影响:
- I/O 类型差异
- 随机 I/O:磁头频繁移动,读取零散数据页,效率低
- 顺序 I/O:连续读取相邻数据页,效率高
-
- 全表扫虽
last_query_cost
高,但触发顺序 I/O,实际执行可能很快
- 全表扫虽
- 缓冲池(Buffer Pool)
- 内存缓存磁盘数据页,查询优先读内存(缓存命中),无需磁盘 I/O
- 预读机制:智能批量加载连续数据页到内存,降低实际耗时
三、实践应用要点
- 对比使用,而非绝对值
加索引后,若last_query_cost
显著下降,说明优化器认为新计划更优(通常利好性能,但不绝对) - 综合判断真实性能
结合SHOW PROFILES
(执行时间)、Innodb_buffer_pool_reads
(实际磁盘读)等指标,避免仅依赖last_query_cost
四、核心结论
优化器的 “成本模型”(理论估算)≠ 引擎的 “物理执行”(真实性能),需结合场景综合分析,last_query_cost
更适合做执行计划对比工具,而非绝对性能指标 。