企业官网建设流程全解析

直接进入正题。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 localhost，Mysql会把它当作socket连接处理，除非你明确写了TCP端口；如果你用-h 127.0.0.1，那才是真正的TCP连接。这两者在权限验证上走的路径不同，有些用户只授权了'username'@'localhost'，你用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) ALGORITHM=INPLACE, LOCK=NONE;

这里有个非常关键的点：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一看，type=ALL，全表扫描，类型一换，瞬间变成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-purged=OFF 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-purged=OFF。如果你在开启了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-output=DECODE-ROWS -v /var/lib/mysql/binlog.000012 | grep 'DELETE FROM users'

mysqlbinlog有一个坑：默认情况下，基于行复制的binlog内容是base64编码的，直接看是一堆乱码，必须加上--base64-output=DECODE-ROWS -v才能看到真实的SQL语句。恢复误删数据时，我的操作思路是先用mysqlbinlog定位误删操作的时间点，然后把该时间点前后的binlog导出成SQL文件，剔除掉错误的DELETE语句后重新导入。记住，恢复数据时千万不要在原库上直接操作，一定是在一个新库或临时实例上回放，确认无误后再切换到生产。

6. 权限管理与日常运维命令：一切为了安全可控

6.1 用户权限的最小化落地

权限命令不需要背太多，但必须理解授权模型的逻辑。Mysql的权限验证分两阶段：第一阶段是连接验证，看用户名和来源主机是否匹配；第二阶段是操作验证，看用户对目标库表有哪些权限。

-- 创建用户，注意主机来源限制，别用%，除非你真的需要任意主机访问 CREATE USER 'app_user'@'192.168.1.%' IDENTIFIED BY 'StrongPassword_2024'; -- 最小化授权：只授予应用必要的权限 GRANT SELECT, INSERT, UPDATE, DELETE ON mydb.* TO 'app_user'@'192.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_user'@'192.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

第二步，审查建表语句，确认字符集和引擎。我习惯把ENGINE=InnoDB和DEFAULT CHARSET=utf8mb4显式写出来，不给数据库默认值留任何歧义。

第三步，在线库确认迁移前状态，记录执行前的时间点和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显示type=ALL，rows接近全表。原因很可能是created_at字段上没有索引。第五步，确认加索引策略，选择在线加索引的方式执行。

ALTER TABLE large_table ADD INDEX idx_created_at (created_at) ALGORITHM=INPLACE, LOCK=NONE;

第六步，加完索引后，重新查执行计划，确认执行效率提升，随后关闭慢查询日志，避免日志文件膨胀。

SET GLOBAL slow_query_log = OFF;

整个排查过程中，唯一需要记住的原则是：先采集现场，再分析定位，最后动手变更。漫无目的地杀线程、改参数，只会让问题更复杂。我见过不少同行，一接到慢查询报警就急着KILL连接，结果杀完一批又冒出一批，因为根本原因没有解决。

9. 常见命令踩坑清单：这些问题我全遇到过

这么多年下来，我把最常见、破坏力最大的命令使用错误整理成一张速查表。每一条都是真实掉过坑的血泪教训。

这张表的每一行，我都在真实环境里见过对应的生产事故。有些事故可以靠备份救回来，有些则造成了不可逆的数据丢失。做数据库工作，最重要的不是会多少高深的调优技能，而是先把这些基础命令用对，把事故发生率降到最低。

10. 一个被很多人忽视的命令：EXPLAIN ANALYZE

Mysql 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显示type=ref，看起来挺正常，但实际执行却动不动好几秒。用EXPLAIN ANALYZE一看，发现它在某个JOIN步骤的actual rows是预估的上千倍——就是说Mysql的优化器对结果行数估算完全不准，导致选择了错误的时间代价高的执行路径。这个信息，传统EXPLAIN是看不到的。

注意，EXPLAIN ANALYZE是真的会执行SQL的。所以生产环境的大表慎用，上来先看执行计划整体结构合理，再考虑用这个方法定位具体瓶颈。

最后分享一点个人习惯

关于命令使用，我觉得最有价值的习惯不是背命令，而是给命令归类场景，建立自己的速查表。我自己的本地笔记里，每个分类下除了命令本身，还有我在生产环境踩过的坑和对应的私房参数。比如备份场景，我固定用--single-transaction --set-gtid-purged=OFF --quick三个参数组合；比如锁表排查场景，我会直接打开一张常用SQL剪贴板，里面是查锁、查事务、查状态的五条固定SQL，到现场直接粘贴执行。

以及很重要的一点，Mysql版本迭代很快，5.7和8.0的很多行为都不太一样。授权写的ALTER USER 'root'@'%' IDENTIFIED BY ... PASSWORD EXPIRE NEVER在旧版本里很可能直接报语法错误。所以建议装一个Mysql 8.0的本地测试环境，每条命令都实际敲几遍，再上生产就不慌了。

下一块内容，我准备把information_schema里的常用视图整理一下，讲一讲如何用纯SQL完成日常巡检工作。那套东西比命令行工具更灵活，也是从初级到高级运维必须要跨的那道坎。