MySQL数据库的监控方式是什么
对于当前数据库的监控方式有很多，分为数据库自带、商用、开源三大类，每一种都有各自的特色；而对于mysql数据库由于其有很高的社区活跃度，监控方式更是多种多样，不管哪种监控方式最核心的就是监控数据，获取得到全面的监控数据后就是灵活的展示部分。1、连接数（Connects）1.1、最大使用连接数showstatuslike'Max_used_connections';1.2、当前打开的连接数showstatuslike'Threads_connected';2、缓存（buffe
对于当前数据库的监控方式有很多，分为数据库自带、商用、开源三大类，每一种都有各自的特色；
而对于 mysql 数据库由于其有很高的社区活跃度，监控方式更是多种多样，不管哪种监控方式最核心的就是监控数据，获取得到全面的监控数据后就是灵活的展示部分。
1、连接数（Connects）
1.1、最大使用连接数
show status like 'Max_used_connections';
1.2、当前打开的连接数
show status like 'Threads_connected';
2、缓存（bufferCache）
2.1、未从缓冲池读取的次数
show status like 'Innodb_buffer_pool_reads';
2.2、从缓冲池读取的次数
show status like 'Innodb_buffer_pool_read_requests';
2.3、缓冲池的总页数
show status like 'Innodb_buffer_pool_pages_total';
2.4、缓冲池空闲的页数
show status like 'Innodb_buffer_pool_pages_free';
2.5、缓存命中率计算
（1-Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests）*100%
2.6、缓存池使用率为
((Innodb_buffer_pool_pages_total-Innodb_buffer_pool_pages_free）/Innodb_buffer_pool_pages_total）*100%
3、锁（lock）
备注：锁等待统计得数量为累加数据，每次获取得时候可以跟之前得数据进行相减，得到当前统计得数据
3.1、锁等待个数
show status like 'Innodb_row_lock_waits';
3.2、平均每次锁等待时间
show status like 'Innodb_row_lock_time_avg';
3.3、查看是否存在表锁，有数据代表存在锁表，空为无表锁
show open TABLES where in_use>0
4、慢SQL
备注：当 mysqldumpslow 命令执行失败时，将慢日志同步到本地进行格式化处理。
4.1、查看 mysql 慢 sql 开关是否打开
show variables like 'slow_query_log'; --ON 为开启状态，OFF 为关闭状态 set global slow_query_log=1 -- 可进行开启
4.2、查看 mysql 慢 sql 阈值
show variables like 'long_query_time'; set global long_query_time=0.1 -- 根据页面传递阈值参数，修改阈值
4.3、查看 mysql 慢 sql 目录
show variables like 'slow_query_log_file';
4.4、格式化慢 sql 日志
注：此语句通过 jdbc 执行不了，属于命令行执行。
意思为：显示出耗时最长的 10 个 SQL 语句执行信息，10 可以修改为 TOP 个数。显示的信息为：执行次数、平均执行时间、SQL 语句
mysqldumpslow -s at -t 10 /export/data/mysql/log/slow.log
5、statement
5.1、insert 数量
show status like 'Com_insert';
5.2、delete 数量
show status like 'Com_delete';
5.3、update 数量
show status like 'Com_update';
5.4、select 数量
show status like 'Com_select';
6、吞吐（Database throughputs）
6.1、发送吞吐量
show status like 'Bytes_sent';
6.2、接收吞吐量
show status like 'Bytes_received';
6.3、总吞吐量
Bytes_sent+Bytes_received
7、数据库参数（serverconfig）
7.1、show variables
8、慢 SQL排查步骤
慢 SQL 指的是 MySQL 慢查询，具体指运行时间超过 long_query_time 值的 SQL。
我们常听 MySQL 中有二进制日志 binlog、中继日志 relaylog、重做回滚日志 redolog、undolog 等。针对慢查询，还有一种慢查询日志 slowlog，用来记录在 MySQL 中响应时间超过阀值的语句。慢 SQL 对实际生产业务影响是致命的，所以测试人员在性能测试过程中，对数据库 SQL 语句执行情况实施监控，给开发提供准确的性能优化意见显得尤为重要。那怎么使用 Mysql 数据库提供的慢查询日志来监控 SQL 语句执行情况，找到消耗较高的 SQL 语句，以下详细说明一下慢查询日志的使用步骤：
8.1、确保打开慢 SQL 开关 slow_query_log
8.2、设置慢 SQL 域值 long_query_time
这个 long_query_time 是用来定义慢于多少秒的才算 “慢查询”，注意单位是秒，我通过执行 sql 指令 set long_query_time=1 来设置了 long_query_time 的值为 1, 也就是执行时间超过 1 秒的都算慢查询，如下：
8.3、查看慢 SQL 日志路径
8.4、通过慢 sql 分析工具 mysqldumpslow 格式化分析慢 SQL 日志
mysqldumpslow 慢查询分析工具，是 mysql 安装后自带的，可以通过./mysqldumpslow —help 查看使用参数说明
8.4.1、常见用法 取出使用最多的 10 条慢查询
./mysqldumpslow -s c -t 10 /export/data/mysql/log/slow.log
取出查询时间最慢的 3 条慢查询
./mysqldumpslow -s t -t 3 /export/data/mysql/log/slow.log
注意：使用 mysqldumpslow 的分析结果不会显示具体完整的 sql 语句，只会显示 sql 的组成结构；
假如: SELECT FROM sms_send WHERE service_id=10 GROUP BY content LIMIT 0, 1000;
mysqldumpslow 命令执行后显示：
Count: 2 Time=1.5s (3s) Lock=0.00s (0s) Rows=1000.0 (2000), vgos_dba[vgos_dba]@[10.130.229.196]SELECT FROM sms_send WHERE service_id=N GROUP BY content LIMIT N, N
8.4.2、mysqldumpslow 的分析结果详解
Count：表示该类型的语句执行次数，上图中表示 select 语句执行了 2 次。
Time：表示该类型的语句执行的平均时间（总计时间）
Lock：锁时间 0s。
Rows：单次返回的结果数是 1000 条记录，2 次总共返回 2000 条记录。
通过这个工具就可以查询出来哪些 sql 语句是慢 SQL，从而反馈研发进行优化，比如加索引，该应用的实现方式等。
8.5、常见慢 SQL 排查
8.5.1、不使用子查询
SELECT FROM t1 WHERE id (SELECT id FROM t2 WHERE name='hechunyang');
子查询在 MySQL5.5 版本里，内部执行计划器是这样执行的：先查外表再匹配内表，而不是先查内表 t2，当外表的数据很大时，查询速度会非常慢。
在 MariaDB10/MySQL5.6 版本里，采用 join 关联方式对其进行了优化，这条 SQL 会自动转换为
SELECT t1. FROM t1 JOIN t2 ON t1.id = t2.id;
但请注意的是：优化只针对 SELECT 有效，对 UPDATE/DELETE 子 查询无效， 生产环境尽量应避免使用子查询。
8.5.2、避免函数索引
SELECT FROM t WHERE YEAR(d) >= 2016;
由于 MySQL 不像 Oracle 那样⽀持函数索引，即使 d 字段有索引，也会直接全表扫描。
应改为 :
SELECT FROM t WHERE d >= ‘2016-01-01';
8.5.3、用 IN 来替换 OR 低效查询
慢
SELECT FROM t WHERE LOC_ID = 10 OR LOC_ID = 20 OR LOC_ID = 30;
高效查询
SELECT FROM t WHERE LOC_IN IN (10,20,30);
8.5.4、LIKE 双百分号无法使用到索引
SELECT FROM t WHERE name LIKE '%de%';
应改为 :
SELECT FROM t WHERE name LIKE 'de%';
8.5.5、分组统计可以禁止排序
SELECT goods_id,count() FROM t GROUP BY goods_id;
默认情况下，MySQL 对所有 GROUP BY col1，col2… 的字段进⾏排序。如果查询包括 GROUP BY，想要避免排序结果的消耗，则可以指定 ORDER BY NULL 禁止排序。
应改为 :
SELECT goods_id,count () FROM t GROUP BY goods_id ORDER BY NULL;
8.5.6、禁止不必要的 ORDER BY 排序
SELECT count(1) FROM user u LEFT JOIN user_info i ON u.id = i.user_id WHERE 1 = 1 ORDER BY u.create_time DESC;
应改为 :
SELECT count (1) FROM user u LEFT JOIN user_info i ON u.id = i.user_id;
详解Navicat导入数据库的标准步骤，涵盖SQL脚本执行与CSV数据导入两种核心场景。针对导入过程中常见的字符集乱码、主键冲突及外键约束错误，提供具体的设置方法与修复建议，确保数据迁移准确无误。
深入理解SQL PRIMARY KEY与UNIQUE约束的区别。文章从行标识与重复限制的目标出发，详解主键的非空特性、外键引用角色以及多数据库对NULL值的处理差异。结合users表实战示例，指导开发者如何根据字段稳定性与业务语义合理选择约束类型，避免设计误区。
刚开始设计关系型数据库？了解PRIMARY KEY、FOREIGN KEY、UNIQUE、NOT NULL、CHECK、DEFAULT等约束的作用、语法和排错方法。本文以PostgreSQL语法为主，结合用户订单场景，清晰展示如何防止脏数据并处理常见约束冲突。
深入解析SQL游标导致的死锁与资源未释放问题。通过PostgreSQL与MySQL语法对比，展示如何识别长事务持锁、分析锁等待链，并提供短事务提交、异常清理及批量处理的最佳实践，确保数据库连接与锁资源及时释放。
后端开发者在维护数据库时，常需对现有表添加主键、唯一或外键约束。若直接执行ADD CONSTRAINT，往往因存量数据不合规导致报错。本文详解操作前的数据清洗步骤、标准SQL语法及MySQL等特殊写法，帮助你在生产环境安全完成结构变更。
针对 SQL 初学者的分组统计实战指南。深入解析 GROUP BY 分组机制、WHERE 与 HAVING 的执行时机差异，以及 COUNT 函数对 NULL 值的处理逻辑。通过具体代码示例演示如何正确筛选聚合结果，并排查因 JOIN 连接导致的统计数据异常，提升报表准确性。
本文详细对比SQL Server和MySQL中游标的基本用法。从DECLARE声明到FETCH遍历，再到CLOSE关闭与DEALLOCATE/Handler清理，解析两者在语法结构、变量接收及异常处理上的核心差异。通过标准代码示例展示如何安全使用游标，避免资源泄漏，适用于需要进行数据库存储过程开发或跨平台迁移的开发者。
深入解析SQL中INNER JOIN与LEFT JOIN的核心区别。通过users和orders表实例，展示匹配行保留与NULL补位机制，重点讲解ON与WHERE子句中放置右表过滤条件的不同后果，提供防止LEFT JOIN退化的实战技巧及行数异常排查步骤。
深入理解 SQL CHECK 约束在 PostgreSQL、MySQL 等数据库中的实现差异。文章通过订单业务场景，讲解如何定义单列范围与多列逻辑约束，分析 NULL 值对布尔条件的影响，并提供修改已有表结构时的安全操作建议，帮助开发者构建更健壮的数据完整性防线。
后端开发中，如何正确使用 SQL 外键约束来维护订单与明细表的关系？本文通过 PostgreSQL 示例，深入讲解外键的创建语法、插入顺序要求，以及 ON DELETE CASCADE、RESTRICT、SET NULL 等策略的实际影响与风险控制，助你构建健壮的数据库结构。
火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力，依托字节自研豆包多模态大模型，凭借火山方舟一站式平台，提供模型精调、推理部署、智能应用搭建等全链路服务，结合高性能AI算力，助力各行业快速落地大模型数字化与智能化应用。
