[特殊字符] MySQL性能参数查询总结

核心语句​

使用 SHOW STATUS语法查询服务器性能指标:

sql 复制代码
SHOW [GLOBAL|SESSION] STATUS LIKE '参数';

​常用性能参数列表​

参数名 含义说明
Connections 连接MySQL服务器的总次数
Uptime MySQL服务器已运行的时间(单位:秒)
Slow_queries 慢查询的次数(需关注优化)
Innodb_rows_read SELECT查询返回的行数
Innodb_rows_inserted INSERT操作插入的行数(批量插入仅计数一次)
Innodb_rows_updated UPDATE操作更新的行数
Innodb_rows_deleted DELETE操作删除的行数
Com_select 查询操作执行的次数
Com_insert 插入操作执行的次数(批量插入仅计数一次)
Com_update 更新操作执行的次数
Com_delete 删除操作执行的次数
  1. ​关键用途​

    1. 监控数据库负载(如连接数、运行时间)。

    2. 分析SQL执行频率(增删改查次数)。

    3. 定位性能问题(如慢查询数量、InnoDB引擎的行操作统计)。

MySQL 查询成本(Query Cost)核心笔记

一、last_query_cost 是什么

  • 定义:系统状态变量,记录上一查询的预估 I/O 成本,由查询优化器计算
  • 作用:优化器选执行计划(如索引、全表扫)的依据,对比不同计划 "成本"
  • 单位:随机数据页读取次数,代表 "完成查询预计读多少磁盘块"

二、"高成本" 查询未必慢的原因

优化器按随机 I/O 模型估算,实际执行受物理机制影响:

  1. I/O 类型差异
    • 随机 I/O:磁头频繁移动,读取零散数据页,效率低
    • 顺序 I/O:连续读取相邻数据页,效率高
    • 全表扫虽 last_query_cost 高,但触发顺序 I/O,实际执行可能很快
  2. 缓冲池(Buffer Pool)
    • 内存缓存磁盘数据页,查询优先读内存(缓存命中),无需磁盘 I/O
    • 预读机制:智能批量加载连续数据页到内存,降低实际耗时

三、实践应用要点

  1. 对比使用,而非绝对值
    加索引后,若 last_query_cost 显著下降,说明优化器认为新计划更优(通常利好性能,但不绝对)
  2. 综合判断真实性能
    结合 SHOW PROFILES(执行时间)、Innodb_buffer_pool_reads(实际磁盘读)等指标,避免仅依赖 last_query_cost

四、核心结论

优化器的 "成本模型"(理论估算)≠ 引擎的 "物理执行"(真实性能),需结合场景综合分析,last_query_cost 更适合做执行计划对比工具,而非绝对性能指标 。

相关推荐
爱学习的阿磊18 分钟前
使用Fabric自动化你的部署流程
jvm·数据库·python
枷锁—sha24 分钟前
【SRC】SQL注入快速判定与应对策略(一)
网络·数据库·sql·安全·网络安全·系统安全
惜分飞37 分钟前
ORA-600 kcratr_nab_less_than_odr和ORA-600 4193故障处理--惜分飞
数据库·oracle
chian-ocean37 分钟前
CANN 生态进阶:利用 `profiling-tools` 优化模型性能
数据库·mysql
m0_5500246341 分钟前
持续集成/持续部署(CI/CD) for Python
jvm·数据库·python
AC赳赳老秦41 分钟前
代码生成超越 GPT-4:DeepSeek-V4 编程任务实战与 2026 开发者效率提升指南
数据库·数据仓库·人工智能·科技·rabbitmq·memcache·deepseek
啦啦啦_99991 小时前
Redis-2-queryFormat()方法
数据库·redis·缓存
玄同7652 小时前
SQLite + LLM:大模型应用落地的轻量级数据存储方案
jvm·数据库·人工智能·python·语言模型·sqlite·知识图谱
吾日三省吾码2 小时前
别只会“加索引”了!这 3 个 PostgreSQL 反常识优化,能把性能和成本一起打下来
数据库·postgresql
chian-ocean2 小时前
百万级图文检索实战:`ops-transformer` + 向量数据库构建语义搜索引擎
数据库·搜索引擎·transformer