直接进入正题。Mysql命令这类东西网上搜出来一大把但绝大多数都是把官方文档的目录抄了一遍看着啥都有真正上手干活的时候翻半天找不到能救命的那条命令。我自己维护线上库这几年把真正高频、真正踩过坑的命令和用法重新整理了一遍不追求大而全只追求关键时候能用上。这篇不是给你背的是给你放在手边查的。1. Mysql命令学习的正确姿势先搭建目录思维很多人学Mysql命令是从SELECT开始的这没错但效率低。我自己的经验是把命令分类成几个大块脑子里先有目录再往里填细节遇到问题直接按图索骥比死记硬背管用得多。我把日常运维和开发涉及的命令分成五个块连接与配置、库表操作与CRUD增删改查、查询进阶与索引优化、备份恢复与日志、权限与运维管理。这个分类不是按官方文档分的是按我在真实环境中的使用频率和紧急程度分的。比如mysqldump和binlog相关命令你平时可能一个月都用不上一次但真出事儿了那是救命用的必须刻在脑子里。还有一个基础认知要摆正命令行操作和可视化工具比如各种图形化客户端完全是两码事。图形化工具点几下就能看到结果但命令行让你明白每一步操作背后数据库到底干了什么、锁了哪些资源、走了哪种算法。用命令行你是在和数据库引擎直接对话用图形化工具你是在跟工具对话。所以日常开发可以用工具但排查问题、写脚本、做自动化运维命令行是绕不开的。2. 连接与库表操作所有命令的地基2.1 连接数据库前必看的5个参数连接命令是所有操作的入口但很多人只会用最基础的mysql -u root -p。实际生产环境里这一条根本不够用。# 基础连接生产环境强烈建议不要用root直连 mysql -u username -p # 指定主机和端口局域网内远程连接必备 mysql -h 192.168.x.x -P 3306 -u username -p # 指定socket文件连接本机连接首选跳过TCP握手开销 mysql -S /tmp/mysql.sock -u username -p # 连接后立即执行SQL并退出写脚本批量处理的利器 mysql -u username -p -e SELECT NOW(); # 指定默认数据库省去每条SQL都写库名前缀 mysql -u username -p database_name这里重点说两个我踩过坑的参数。第一个是-h如果你用-h localhostMysql会把它当作socket连接处理除非你明确写了TCP端口如果你用-h 127.0.0.1那才是真正的TCP连接。这两者在权限验证上走的路径不同有些用户只授权了usernamelocalhost你用TCP连接就会被拒绝。第二个参数是-e这个是写自动化脚本的神器配合shell的循环和条件判断可以批量执行数据库操作后面实操部分我会给例子。2.2 数据库和表结构管理别只会CREATE和DROP库表管理这块CREATE DATABASE和DROP TABLE没什么好讲的我重点说几个容易忽略的高频命令。-- 判断是否存在再创建幂等操作脚本里必须这么写 CREATE DATABASE IF NOT EXISTS mydb DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_bin; -- 修改表名注意生产环境可能引发元数据锁 ALTER TABLE old_table RENAME TO new_table; -- 查看表结构这个命令比DESC信息更完整 SHOW CREATE TABLE users\G; -- 快速复制表结构而不复制数据做抽数前先建空表很常见 CREATE TABLE backup_table LIKE original_table; -- 添加索引时指定算法在线DDL避免阻塞业务写入 ALTER TABLE users ADD INDEX idx_username (username) ALGORITHMINPLACE, LOCKNONE;这里有个非常关键的点ALTER TABLE在生产环境执行时不是所有版本都支持在线变更。在5.6之前大部分ALTER操作是会锁表的这意味着在执行期间业务的写入会被卡住。我记得有个真实案例某公司的DBA在白天对一张千万级用户表执行了一个加字段操作结果线上业务直接阻塞了几分钟运维报警电话被打爆。后来亲历了这事我才养成了一个铁律线上环境的大表结构变更一律在低峰期执行并且先检查版本是否支持在线DDL。SHOW CREATE TABLE也是容易被忽略但极其重要的命令。它能完整显示建表语句、字符集、存储引擎、分区信息排查字符集乱码问题或者确认表的分区规则时比DESC好用太多。3. 数据操作命令增删改查的进阶玩法3.1 INSERT的三种变体别再一条一条插了批量插入是我看很多人写SQL时最心疼的地方。我曾经见过一段代码在循环里一条一条执行插入插入10万条数据用了接近半小时。后面我给优化方案时重点教了三种变体。-- 基础插入单条语句 INSERT INTO users (name, age) VALUES (Alice, 25); -- 批量插入一次插入多行效率提升几十倍 INSERT INTO users (name, age) VALUES (Alice, 25), (Bob, 30), (Carol, 28); -- 插入或更新适用于主键或唯一索引冲突时自动更新 INSERT INTO users (name, age) VALUES (Alice, 26) ON DUPLICATE KEY UPDATE age VALUES(age); -- 插入或忽略冲突时直接跳过不报错 INSERT IGNORE INTO users (name, age) VALUES (Bob, 31);批量插入的原理很简单一条SQL语句只做一次网络往返而循环插入每次都要独立的网络交互和事务处理。在数据初始化、临时表填充、ETL数据抽取转换加载过程中批量插入是绝对的主流方式。IO密集型场景下这个优化带来的速度提升是数量级的。需要特别注意的是ON DUPLICATE KEY UPDATE。它依赖唯一索引或主键来触发判断如果你表上没有唯一键这条命令的行为就跟普通INSERT一样不会触发更新。另外在高并发写入场景下INSERT ... ON DUPLICATE KEY UPDATE会产生锁竞争如果业务允许优先考虑INSERT IGNORE或先查询再更新的策略。3.2 UPDATE和DELETE不加WHERE就是在玩火这两条命令是事故多发区。听说过一个国内某大厂的事故公司DBA在跑一个UPDATE任务时少写了一个WHERE条件直接把全表某个字段值都改掉了最后只能从备份恢复业务中断了几个小时。这种事故的根源不是命令本身而是操作习惯。-- 更新单表时务必先SELECT确认影响行数 SELECT COUNT(*) FROM users WHERE age 18; UPDATE users SET status minor WHERE age 18; -- 跨表更新注意JOIN语法版本差异 UPDATE users u JOIN orders o ON u.id o.user_id SET u.level VIP WHERE o.amount 10000; -- 安全删除的通用套路先查出来看一眼 SELECT * FROM users WHERE last_login DATE_SUB(NOW(), INTERVAL 1 YEAR); -- 确认无误后加LIMIT分批删除避免长时间锁表 DELETE FROM users WHERE last_login DATE_SUB(NOW(), INTERVAL 1 YEAR) LIMIT 5000;两次强调这个习惯的原因在于Mysql的UPDATE和DELETE不像某些数据库有单次操作行数上限保护。如果没有WHERE条件它会傻乎乎地扫全表直到所有行都改完或删完。生产环境一次全表更新往往意味着锁表——如果是InnoDB引擎默认行锁但全表扫描时会对大量行加锁性能急剧下降极端情况下会堵死整个库。所有我在团队内部定的规矩是任何更新或删除任务必须先在测试环境用EXPLAIN看过执行计划确认走索引再正式执行。3.3 SELECT基础自查清单写完SQL先看一眼这4条开发了这么多年我总结了一个SELECT语句的快速自查清单。每次写完SQL我都会花十秒钟过一遍排查80%以上的隐藏问题。第一是否有多余的DISTINCT。如果你发现一条SQL里DISTINCT是为了去重而加的但分组字段本身是唯一的那说明你的JOIN查询有数据膨胀问题需要检查关联字段是否有重复值。第二LIMIT很大时是否真的需要。分页查询里LIMIT 1000000, 20这种写法Mysql会先查出一百万行再丢弃这等于白干。解决方案是用上一页的最大主键或时间戳做条件也就是业界说的键集分页。第三SELECT *是否真的需要。不要图省事明确列出字段名减少网络传输也为后续加字段减少波及面。第四和不必要的ORDER BY说再见。排序是有代价的如果结果集不需要有序别写如果一定要排序尽量让排序字段命中索引。4. 查询进阶与索引优化性能的本质4.1 WHERE条件里的隐式转换坑这条命令本身不复杂但导致的性能问题极其隐蔽。-- 假设表里有一列 phone VARCHAR(11) SELECT * FROM users WHERE phone 13800138000;当phone是字符串类型而条件右边是数字时Mysql会尝试把字符串字段隐式转换为数字进行比较。这个转换会让字段上的索引失效查询变成了全表扫描。数据量小的时候没感觉数据量到了千万级这条SQL能把数据库CPU直接打满。解决办法很简单保证条件右边的类型和字段定义的类型完全一致。在写参数化查询时特别注意传入参数的类型标签。如果你用的是ORM框架一定要确认字段映射类型是否匹配。这个坑我见过太多次了几个人排查了一整天都找不到原因最后用EXPLAIN一看typeALL全表扫描类型一换瞬间变成ref。4.2 JOIN查询小表驱动大表的底层逻辑JOIN的优化是面试高频题也是线上性能排查的重灾区。很多人知道LEFT JOIN和INNER JOIN的语法区别但没搞明白Mysql底层是怎么执行JOIN的。Mysql最常用的JOIN执行方式是嵌套循环连接就是拿外层表的每一行去内层表找匹配的行。所以外层表越小内层表被扫描的次数越少整体越快。这个原理演化出来的优化原则就叫小表驱动大表。-- 推荐小表orders驱动大表users SELECT u.name, o.amount FROM orders o LEFT JOIN users u ON o.user_id u.id; -- 反例大表驱动小表Mysql优化器可能会自动调整但别依赖 SELECT u.name, o.amount FROM users u LEFT JOIN orders o ON u.id o.user_id;另外有一个点是即使Mysql优化器有自动重排JOIN顺序的能力它也有判断失误的时候特别是涉及复杂的子查询或ORDER BY时。所以写JOIN时的习惯也很重要尽量让驱动表的过滤条件提前生效也就是说在ON里尽量少放过滤条件过滤条件放到WHERE里让优化器先缩小驱动表的结果集。4.3 EXPLAIN命令的三个关键关注点EXPLAIN是Mysql性能诊断的照妖镜。但在合作过的团队里我发现很多人只会看type是不是ALL其他一概不管。我自己的习惯是重点盯三列。第一是type。从好到差依次是system const eq_ref ref range index ALL。线上查询至少要达到range理想状态是ref以上。如果发现index或ALL就必须排查索引问题。第二是key。这一列显示实际用到的索引如果你发现key是NULL说明这条SQL根本没使用索引。第三是rows。这是Mysql估算的要扫描的行数这个值越接近实际返回行数越好如果差距悬殊说明统计信息不准确或者索引选择性太差。EXPLAIN SELECT u.name, o.amount FROM users u JOIN orders o ON u.id o.user_id WHERE u.age 30\G;运行上面这条命令重点看输出结果里的type、key、rows三列。如果users表上的type是ALL且rows巨大而WHERE条件里有age字段大概率是缺一个idx_age索引。注意加了索引后要记得用ANALYZE TABLE users;更新统计信息不然优化器可能还按旧的统计信息做执行计划。4.4 覆盖索引与回表理解索引下推的前提覆盖索引这个概念是和EXPLAIN里的Extra列直接相关的。如果Extra里面有Using index那就说明这条SQL走了覆盖索引查询所需的字段全部包含在索引树中不需要回表查聚簇索引。这是最高效的查询方式。举个例子-- 假设表有联合索引 idx_city_age (city, age) SELECT city, age FROM users WHERE city Shanghai AND age 30;这条SQL只需要从idx_city_age索引树中就能拿到city和age两个字段根本不用回表。但如果查询变成SELECT name, city, age ...name字段不在索引里就必须回表查主键对应的数据行。所以在设计联合索引时一个实用经验是把查询频率最高的字段放在联合索引的最左列尽量让索引覆盖常用的查询字段这是从SELECT层面就能做的最大性能优化。5. 备份恢复与日志命令救命能力储备5.1 逻辑备份mysqldump的标准操作做维护这一行的备份命令要形成肌肉记忆。常规备份我用mysqldump但参数踩坑无数这里直接说结论。# 单库备份包含表结构和数据加锁方式适合停机备份 mysqldump -u username -p --single-transaction --set-gtid-purgedOFF mydb mydb_backup.sql # 备份结构中特定表注意mysqldump的表名参数 mysqldump -u username -p mydb users orders selected_tables.sql # 只备份表结构不加-d注意参数是--no-data mysqldump -u username -p --no-data mydb schema_only.sql # 压缩备份线上大库默认操作方式 mysqldump -u username -p --single-transaction mydb | gzip mydb_backup.sql.gz--single-transaction这个参数极其重要它利用InnoDB的MVCC多版本并发控制机制在一个快照中读取数据备份过程中不会锁业务表的写入。如果不加这个参数备份期间涉及的表只能读不能写业务会直接中断。还有一个容易踩坑的是--set-gtid-purgedOFF。如果你在开启了GTID全局事务标识的Mysql实例上做备份默认的mysqldump会写入GTID信息恢复时如果目标实例的GTID配置不一致会直接报错。备份从库时我通常显式加上这个参数避免恢复流程被GTID卡住。5.2 恢复命令如何快速导入大备份文件备份恢复我只推荐两个方案别再想用图形化工具的导入功能恢复几十GB的库那会等到怀疑人生。# 标准恢复方式 mysql -u username -p mydb mydb_backup.sql # 多个分片备份文件并行恢复用管道的方式分散IO压力 # 先拆分文件再并行导入 zcat mydb_backup.sql.gz | mysql -u username -p mydb恢复的时候第一件事不是执行命令而是检查磁盘空间。df -h是恢复前的必备动作。曾经有个案例某公司在恢复一个100GB的库时忘记检查磁盘空间结果数据库写到一半磁盘满了恢复进程崩溃整个库处于一个半初始化状态最后只能从头再来白白浪费了几个小时。还有就是我建议恢复时先关闭目标库的外键检查恢复完再开启否则导入顺序错误会导致外键约束报错中断。命令是SET FOREIGN_KEY_CHECKS 0;注意这个命令需要在会话中用SQL执行不是命令行参数。5.3 binlog查看与回放误删数据的最后一道防线binlog二进制日志是Mysql数据恢复真正意义上的杀手锏。很多公司的全量备份是每天一次但增量数据都在binlog里。如果某天上午误删了一张表你要做的不是崩溃而是用binlog找回数据。# 查看binlog文件列表 SHOW BINARY LOGS; # 看当前正在写入的binlog SHOW MASTER STATUS; # 查看指定binlog中的SQL内容Mysql 8.0和5.7有参数差异 mysqlbinlog --no-defaults --base64-outputDECODE-ROWS -v /var/lib/mysql/binlog.000012 | grep DELETE FROM usersmysqlbinlog有一个坑默认情况下基于行复制的binlog内容是base64编码的直接看是一堆乱码必须加上--base64-outputDECODE-ROWS -v才能看到真实的SQL语句。恢复误删数据时我的操作思路是先用mysqlbinlog定位误删操作的时间点然后把该时间点前后的binlog导出成SQL文件剔除掉错误的DELETE语句后重新导入。记住恢复数据时千万不要在原库上直接操作一定是在一个新库或临时实例上回放确认无误后再切换到生产。6. 权限管理与日常运维命令一切为了安全可控6.1 用户权限的最小化落地权限命令不需要背太多但必须理解授权模型的逻辑。Mysql的权限验证分两阶段第一阶段是连接验证看用户名和来源主机是否匹配第二阶段是操作验证看用户对目标库表有哪些权限。-- 创建用户注意主机来源限制别用%除非你真的需要任意主机访问 CREATE USER app_user192.168.1.% IDENTIFIED BY StrongPassword_2024; -- 最小化授权只授予应用必要的权限 GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.* TO app_user192.168.1.%; -- 只读用户报看板或报表功能用 CREATE USER readonly_user% IDENTIFIED BY Readonly_2024; GRANT SELECT ON mydb.* TO readonly_user%; -- 授权后刷新权限8.0之后其实不需要但养成习惯 FLUSH PRIVILEGES; -- 查看用户的权限 SHOW GRANTS FOR app_user192.168.1.%;这里有一项明确的安全建议生产环境不要给应用账号授予DROP和ALTER权限。应用代码发版时如果误操作或者被SQL注入攻击一条DROP TABLE就真的什么都没了。有些公司甚至把DELETE权限也收掉删除操作全部走软删除标记这是防误删的终极方案。FLUSH PRIVILEGES这条命令在Mysql 8.0里已经不需要手动执行了因为权限修改立即生效。但如果你们还在用5.5或5.6的老版本这句还是得有。6.2 连接数与进程管理数据库卡死的急救指南数据库卡死了别慌先看进程列表再决定怎么处理。-- 查看所有活跃连接重点关注Info列是否为NULL SHOW FULL PROCESSLIST; -- 杀掉指定的僵死连接常见于锁等待导致的堆积 KILL 12345;Show FULL PROCESSLIST输出里有几个状态值得关注。Sleep状态表示连接空闲但还保持着如果大量Sleep连接存在说明应用连接池配置有问题连接没有及时回收。Locked状态表示这条SQL在等待表锁或行锁。Sending data阶段比较害人它其实包含从存储引擎读取数据到发送结果的全过程如果长时间停留在这个状态大概率是SQL性能问题而非网络问题。我在接手一个线上卡死问题时第一步永远是看SHOW FULL PROCESSLIST里有没有大量Waiting for table metadata lock。这个状态通常和一个未提交的长事务以及一个针对该表的ALTER TABLE语句叠加有关。解决办法是找到持有元数据锁的长事务要么COMMIT要么KILL。这些排查经验在命令手册里是找不到的。6.3 性能相关SQL速查状态变量和慢查询日志SHOW STATUS和慢查询日志是日常巡检的左右手。SHOW STATUS能直接反映数据库的健康度指标。-- 查看当前连接数上限和实际连接数 SHOW VARIABLES LIKE %max_connections%; SHOW STATUS LIKE Threads_connected; -- 查看InnoDB缓冲池命中率 SHOW STATUS LIKE Innodb_buffer_pool_read%; -- 动态设置慢查询日志开关排查结束后记得关闭 SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 1; -- 超过1秒的SQL记录日志慢查询日志特别有用的一点是它不只是记录SQL文本还记录执行时间和扫描行数。通过这个日志定位到的SQL配合EXPLAIN分析执行计划基本可以解决90%的业务性能问题。我曾经通过慢查询日志发现了一个定时任务它每小时跑一次UPDATE但每次都会更新全表造成大量行锁。找到了问题SQL后在任务脚本里加了精确的WHERE条件数据库压力立刻降了一半。7. 实战场景一用命令行完成一个完整的上线发布操作前面拆了很多命令这里我串一个典型的场景帮你建立完整的操作概念。假设我们要上线一个新功能包含一张新表、一个索引调整、以及一批初始数据的初始化。第一步在测试环境确认表结构导出建表语句。mysqldump -u dev_user -p --no-data mydb new_feature_table new_feature_table_schema.sql第二步审查建表语句确认字符集和引擎。我习惯把ENGINEInnoDB和DEFAULT CHARSETutf8mb4显式写出来不给数据库默认值留任何歧义。第三步在线库确认迁移前状态记录执行前的时间点和binlog位置。SHOW MASTER STATUS;第四步在执行窗口内导入表结构。mysql -u deploy_user -p mydb new_feature_table_schema.sql第五步验证表结构用SHOW CREATE TABLE new_feature_table\G;确认所有字段定义无误。第六步初始化数据。如果是从文件导入用批量插入的方式如果是业务脚本生成确认脚本使用预处理语句预编译SQL避免注入问题。这个流程里有一个我每次都会强调的细节导入表结构后第一件事不是写数据而是立即用SHOW CREATE TABLE检查一遍。因为我自己就遇到过导入生产库的时候由于目标库的sql_mode和测试库不同某些字段的默认值被静默修改而且是进了数据之后才发现最后不得不回滚。先验证再使用这个习惯帮我躲过很多次事故。8. 实战场景二性能问题排查的完整手顺排查性能问题是DBA和架构师最核心的能力。我按一次真实的排查过程梳理一下手顺包含用到的每一条命令。通常第一天夜里线上开始偶发慢查询业务方反馈接口变慢。第一步我先看数据库当前的负载。SHOW GLOBAL STATUS LIKE Threads_running; SHOW GLOBAL STATUS LIKE Threads_connected;第二步开启慢查询收集现场。SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 0.5;第三步如果问题还在持续直接抓当前运行中的SQL。这里有两条核心命令-- 看当前正在执行的SQL这是第一现场 SELECT * FROM information_schema.processlist WHERE state ! Sleep ORDER BY time DESC; -- 查InnoDB当前的锁等待和事务信息 SELECT * FROM information_schema.innodb_trx WHERE trx_state RUNNING;第四步经过几分钟采集慢查询日志里出现了一条高频SQL。我用EXPLAIN对它进行精准分析。EXPLAIN SELECT * FROM large_table WHERE created_at 2024-01-01 ORDER BY user_id LIMIT 10;EXPLAIN显示typeALLrows接近全表。原因很可能是created_at字段上没有索引。第五步确认加索引策略选择在线加索引的方式执行。ALTER TABLE large_table ADD INDEX idx_created_at (created_at) ALGORITHMINPLACE, LOCKNONE;第六步加完索引后重新查执行计划确认执行效率提升随后关闭慢查询日志避免日志文件膨胀。SET GLOBAL slow_query_log OFF;整个排查过程中唯一需要记住的原则是先采集现场再分析定位最后动手变更。漫无目的地杀线程、改参数只会让问题更复杂。我见过不少同行一接到慢查询报警就急着KILL连接结果杀完一批又冒出一批因为根本原因没有解决。9. 常见命令踩坑清单这些问题我全遇到过这么多年下来我把最常见、破坏力最大的命令使用错误整理成一张速查表。每一条都是真实掉过坑的血泪教训。场景错误做法正确做法原因简析批量删除大表数据DELETE FROM t WHERE ...全量一次执行加LIMIT分批执行或保留最近数据其余归档一次性删除会持有大量行锁阻塞业务备份大库不加--single-transaction加--single-transaction使用InnoDB一致性快照不加会导致备份期间表不可写改表结构ALTER TABLE直接执行不确认锁策略加ALGORITHMINPLACE, LOCKNONE低峰期执行默认策略在大表上可能锁表统计更新更新全表时忘记WHERE先SELECT COUNT(*)确认影响行数无WHERE就是全表更新事故级别错误字符串字段查询左边是VARCHAR右边是数字保证类型一致用引号包裹变量隐式转换导致索引失效分页深度翻页LIMIT 1000000, 20用主键或唯一键做条件定位数据量大时深分页性能剧降binlog分析直接mysqlbinlog看内容加--base64-outputDECODE-ROWS -v默认输出是编码后的伪SQL乱加索引每个字段都建索引按最左前缀原则建联合索引索引过多导致写入速度下降GTID备份恢复时报GTID错误备份加--set-gtid-purgedOFF不同实例GTID配置不一致导致冲突授权过宽CREATE USER x%然后全库ALL最小化授权限制主机来源安全域越大出事波及面越大这张表的每一行我都在真实环境里见过对应的生产事故。有些事故可以靠备份救回来有些则造成了不可逆的数据丢失。做数据库工作最重要的不是会多少高深的调优技能而是先把这些基础命令用对把事故发生率降到最低。10. 一个被很多人忽视的命令EXPLAIN ANALYZEMysql 8.0.18 以后推出了EXPLAIN ANALYZE这是性能排查工具的又一次进化。和普通EXPLAIN不同它不只是输出预估的执行计划而是真正执行SQL并输出每一步实际消耗的时间和行数。EXPLAIN ANALYZE SELECT u.name, o.amount FROM users u JOIN orders o ON u.id o.user_id WHERE u.age 30;输出的关键字段包括actual time和actual rows这两项能直接暴露SQL慢在哪里。我举个例子之前排查一条SQL普通EXPLAIN显示typeref看起来挺正常但实际执行却动不动好几秒。用EXPLAIN ANALYZE一看发现它在某个JOIN步骤的actual rows是预估的上千倍——就是说Mysql的优化器对结果行数估算完全不准导致选择了错误的时间代价高的执行路径。这个信息传统EXPLAIN是看不到的。注意EXPLAIN ANALYZE是真的会执行SQL的。所以生产环境的大表慎用上来先看执行计划整体结构合理再考虑用这个方法定位具体瓶颈。最后分享一点个人习惯关于命令使用我觉得最有价值的习惯不是背命令而是给命令归类场景建立自己的速查表。我自己的本地笔记里每个分类下除了命令本身还有我在生产环境踩过的坑和对应的私房参数。比如备份场景我固定用--single-transaction --set-gtid-purgedOFF --quick三个参数组合比如锁表排查场景我会直接打开一张常用SQL剪贴板里面是查锁、查事务、查状态的五条固定SQL到现场直接粘贴执行。以及很重要的一点Mysql版本迭代很快5.7和8.0的很多行为都不太一样。授权写的ALTER USER root% IDENTIFIED BY ... PASSWORD EXPIRE NEVER在旧版本里很可能直接报语法错误。所以建议装一个Mysql 8.0的本地测试环境每条命令都实际敲几遍再上生产就不慌了。下一块内容我准备把information_schema里的常用视图整理一下讲一讲如何用纯SQL完成日常巡检工作。那套东西比命令行工具更灵活也是从初级到高级运维必须要跨的那道坎。