干了十来年MySQL相关的活儿从早期的5.5一路用到现在的8.0、8.4 LTS我发现自己日常工作中真正高频敲的命令还真就是那一百来条。这些年不管是给公司内部做培训还是带新人写SQL我一直跟他们强调一句话图形化工具能让你把活干完但命令行能让你把活干明白。这份MySQL常用命令手册就是我把这些年在生产环境、面试沟通、线上故障排查里反复用到的命令整理出来的一个合集不是什么大而全的官方文档更侧重于“当时我遇到这个问题是怎么解决的”。所以这份手册的定位很简单解决日常工作里最扎手的几个问题——装完库连不上、连接报SSL错误、写SQL排序查询慢、线上事务卡死、要建索引不知道该建哪个、备份恢复手忙脚乱、权限给了半天还是报错。同时它也顺手覆盖了面试里最高频的那些考点因为你会发现面试官问的“索引为什么快”“锁是怎么回事”本质上就是你平时敲的那几条命令背后的原理。如果你正在学MySQL、刚接触Linux运维或者已经写了两三年SQL但对数据库运维还是有点发怵这份手册应该能帮你把零散的知识串起来。我尽量用“先给命令、再讲为什么、最后说坑在哪”的方式来写按我自己的实操顺序往下走。1. 这份MySQL常用命令手册解决的是什么问题1.1 为什么常用命令值得单独整理一份MySQL的官方文档动辄几千页但你让一个每天在用的后端工程师或者运维说几个最常用的SQL大概率就是增删改查加建索引。真正拉开差距的不是“会不会写select”而是遇到问题时能不能用对命令、看对输出。比如同样的排序慢有人只会加索引碰运气有人会用EXPLAIN看执行计划再用慢查询日志定位这就是命令熟练度的差别。我见过太多人装好MySQL之后第一步就是打开Navicat点点点。这没什么不好但生产环境里你总会遇到必须上命令行的场景服务器上只有命令行、容器里没法装图形工具、Windows服务起不来要去看错误日志、线上死锁要在performance_schema里翻数据。这些场景下脑子里有没有那几条命令直接影响故障恢复的时间。所以这份手册不是让你背命令而是让你知道“这条命令的输出意味着什么、下一步该干什么”。另外MySQL社区版本身也在快速变化。5.7系列早在2023年就已经停止更新5.7.44是它的最后一个维护版本网上偶尔会看到“5.7.44之后怎么又出了个5.7.43”这种疑惑其实那是下载站的排序或者版本号回滚造成的错觉5.7真正的终点就是5.7.44。之后官方主推8.0系列和8.4 LTS长期支持版。命令手册自然也要跟着调整比如8.0里锁信息从information_schema挪到了performance_schema老命令在新版本里大概率查不到东西。1.2 这份手册适合谁、怎么用最有效首推给三类人刚入行的运维和DBA需要用命令行排查问题写了好几年业务代码但没系统了解过数据库底层逻辑的后端工程师准备跳槽面试、想在MySQL相关问题上讲出原理的人。手册里的每条命令我都尽量配上实际输出和解释你不需要死记只要照着敲一遍观察结果变化基本就能记住。我建议你看这份手册的时候别光看手里开一个MySQL实例最好是Linux环境Windows也行。每看一小节就实际操作一遍把报错故意制造出来再解决印象会深得多。比如你在第2部分会看到SSL连接错误这玩意儿在MySQL 8.0里几乎必然遇到我就碰见过不下十次。你能亲手复现一次以后再遇到就不会慌了。2. 装库与连库起步阶段的常见绊脚石2.1 版本选择、下载解压与初始化先聊版本。如果你的项目还在用MySQL 5.7建议尽快规划升级因为官方已经不再提供安全补丁出问题只能自己扛。8.0是目前应用最广的稳定版本像8.0.44就是我在生产环境里用了很久的版本。8.4 LTS则是官方新推出的长期支持分支适合新项目直接选用命令和8.0基本一致只是有些8.0里的旧特性被移除了。下载时认准官方源比如在Linux上用apt或yum装是最省事的# Ubuntu/Debian apt update apt install mysql-server # CentOS/RHEL 7/8 yum install mysql-server如果是二进制包解压之后最关键的就是初始化。很多人第一次装MySQL失败都栽在初始化这一步上。5.7和8.0之后的初始化方式几乎一样直接执行mysqld --initialize-insecure --basedir/usr/local/mysql --datadir/var/lib/mysql用--initialize-insecure会生成一个无密码的root账号方便首次登录之后再立刻改密码。如果直接用--initialize系统会随机生成一个临时密码一般在error log里登录时要用--skip-password或者读日志里的密码。Windows上还会遇到“net start mysql 服务无法启动”核心原因十有八九是没初始化data目录、my.ini路径不对或者3306端口被占用。初始化之后先把服务装上再启动mysqld --install mysql net start mysql启动以后第一件事是跑安全初始化脚本把匿名用户、测试库这些默认风险点清掉mysql_secure_installation连接命令就没什么好说的了注意端口、字符集、编码不要踩坑mysql -h 127.0.0.1 -P 3306 -u root -p --default-character-setutf8mb4我见过不少人因为-P写成了小写-p导致连不上记一下大P是端口小p是密码提示。2.2 SSL连接报错的排查姿势MySQL 8.0默认开启了SSL连接而很多老客户端、旧驱动只支持TLSv1.0或者压根没编译SSL支持这时候就会报ERROR 2026 (HY000): SSL connection error: protocol version mismatch之类的错。光看报错很容易懵其实就两条路让客户端支持更高TLS版本或者在确认网络环境安全的情况下临时关掉SSL。如果你只是命令行手动连可以这样绕过mysql -h 127.0.0.1 -P 3306 -u root -p --ssl-modeDISABLED在连接串层面Java驱动的url里加?useSSLfalseallowPublicKeyRetrievaltruePython的pymysql在connect参数里写ssl_disabledTrue。但注意这不是让你在公网环境裸奔生产环境如果必须走公网访问数据库更应该做的是配好TLS证书而不是图省事关SSL。排查SSL问题还有一个姿势先看服务器端到底支持哪些TLS版本SHOW VARIABLES LIKE tls_version; SHOW VARIABLES LIKE have_ssl;如果tls_version里没有TLSv1.2以上的版本而客户端强制用旧版本那就必然握手失败。这时候还可以在MySQL配置文件里开启tls-versionTLSv1.2,TLSv1.3来排除老协议。实际上我踩得最多的情况是用Navicat连得好好的换了一个老版本JDBC驱动就连不上基本都是TLS版本不匹配加上allowPublicKeyRetrievaltrue就能解决。2.3 服务启动失败的通用排查顺序不管是在Windows上net start mysql报错还是在Linux上systemctl start mysqld失败排查思路其实都一样按顺序来可以节省大量时间。第一步看错误日志。MySQL的错误日志一般在数据目录下文件名类似主机名.err如果不知道数据目录在哪可以执行mysqld --verbose --help | grep datadir或者看配置文件里的log_error配置项。日志末尾几行通常会直接告诉你原因比如Cant start server: Bind on TCP/IP port: Address already in use这说明3306被占了。第二步查端口和进程。Linux上用ss -lntp | grep 3306或者netstat -ano | findstr 3306Windows看是谁占用了端口。最常见的是之前残留的mysqld进程没杀干净也可能是别的服务占用了3306这时候要么改配置文件里的端口要么杀掉占用进程。第三步确认目录权限。Linux下mysqld进程通常以mysql用户运行数据目录的所有者不对就会启动失败chown -R mysql:mysql /var/lib/mysqlWindows上则要注意data目录的读写权限有时候把MySQL装在Program Files下就会出现权限不够的问题解决方法要么以管理员身份运行要么把数据目录挪到D盘。第四步检查my.ini或my.cnf配置。这是最隐蔽的坑比如basedir和datadir写错了、配置文件里有多个重复项后续项覆盖前面的或者配置中的路径包含了中文或空格。我自己就遇到过因为my.ini里误加了一个validate_password_policyLOW但版本不支持这个系统变量直接启动失败。3. 库表结构与查询操作的高频套路3.1 建库建表与结构修改数据库和表的结构设计其实是另一个大话题但从命令层面说常用的就那几条。建库尽量显式指定字符集和排序规则统一用utf8mb4是最稳的CREATE DATABASE IF NOT EXISTS shop DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_unicode_ci; USE shop; CREATE TABLE user ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, name VARCHAR(64) NOT NULL COMMENT 姓名, age INT NOT NULL DEFAULT 0, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;日常开发里“MySQL数据库修改结构”的命令其实翻来覆去就是ADD、MODIFY、DROP、RENAME这几类。很多人老记不住ALTER TABLE的语法顺序我帮你理一下-- 加字段可以指定位置 ALTER TABLE user ADD COLUMN email VARCHAR(128) NULL AFTER name; -- 修改字段类型和默认值 ALTER TABLE user MODIFY COLUMN age INT NOT NULL DEFAULT 0; -- 单独修改默认值为0 ALTER TABLE user ALTER COLUMN age SET DEFAULT 0;这里单独说一下设置默认值为0的场景。很多时候你新增字段时希望默认值就是0但如果不显式指定MySQL会按列类型给一个隐式默认值比如INT列默认是0、VARCHAR默认是空字符串建表时写DEFAULT 0和事后ALTER TABLE ... ALTER COLUMN ... SET DEFAULT 0效果一样。但要注意在MySQL 8.0.19之后ALTER TABLE ... ALTER COLUMN ... SET DEFAULT还会把列里的历史数据一起“重新解释”这在某些版本里行为略有差异所以线上改动前最好先查一下当前数据。3.2 排序、分组、去重的执行逻辑查询最热门的命令就是SELECT加排序分组。很多新手只知道ORDER BY能排序却不明白为什么数据多了就慢。比如这句SELECT age, COUNT(*) FROM user GROUP BY age ORDER BY age DESC;如果没有索引支持MySQL只能把整张表扫一遍然后做临时表和排序内存不够还要落到磁盘这就是“文件排序”的由来。判断有没有用上索引给查询前面加一个EXPLAIN就能看到EXPLAIN SELECT age, COUNT(*) FROM user GROUP BY age ORDER BY age DESC\G如果输出里Extra列出现Using filesort基本就是没走索引或者排序方式和索引顺序不匹配。去重也一样SELECT DISTINCT和GROUP BY都能去重实际效果类似但DISTINCT的实现往往就是在排序或分组过程中去重所以能不能走索引直接影响性能。我个人的习惯是明确的聚合统计用GROUP BY只是想去一列重复值用DISTINCT两者在写法上差别不大别纠结。再回答一个日常高频问题很多人用惯了SQL Server在MySQL里也写DATEPART(year, created_at)然后报错。MySQL没有DATEPART它对应的是EXTRACT和DATE_FORMATSELECT EXTRACT(YEAR FROM created_at) AS yr, DATE_FORMAT(created_at, %Y-%m) AS ym, COUNT(*) FROM user GROUP BY DATE_FORMAT(created_at, %Y-%m);要注意GROUP BY里用什么表达式SELECT里最好保持一致否则某些模式下会报错。3.3 UPDATE恢复与误操作防范热词里有“mysql update 还原”我第一反应就是大概有人把UPDATE写错了没带WHERE条件然后全表数据被改了。这类问题的处理思路其实不是“怎么还原”而是“能不能还”。如果这条UPDATE是在事务里执行的且还没COMMIT那直接ROLLBACK就行START TRANSACTION; UPDATE user SET age age 1 WHERE id 1; -- 发现不对 ROLLBACK;但大多数人报错是因为已经COMMIT了那就得靠备份和binlog了。如果你开启了binlog可以用mysqlbinlog把某个时间点之前的SQL重新执行一遍或者反向解析出误操作的语句来修补。说实话这个恢复过程很痛苦更靠谱的办法是平时养成两个习惯第一UPDATE和DELETE前一定先SELECT看一眼影响范围第二重要数据表至少要有最近的逻辑备份。我自己写生产环境的UPDATE脚本时第一行永远是先跑SELECT COUNT(*)。还有个小命令能让你在看数据变化时省不少事。MySQL客户端里用\G结尾代替分号会把查询结果竖着显示尤其适合一行数据特别宽、横向显示会换行的情况SELECT * FROM user WHERE id 1\G4. 索引管理与慢SQL定位4.1 索引创建与删除的实用命令索引是MySQL性能的核心手段但乱建索引比不建更糟。日常命令就这几条-- 建普通索引 CREATE INDEX idx_name_age ON user(name, age); -- 建唯一索引 ALTER TABLE user ADD UNIQUE INDEX uk_email(email); -- 删索引 DROP INDEX idx_name_age ON user; -- 查看表上的索引 SHOW INDEX FROM user;复合索引的字段顺序是有讲究的这就是面试里必问的“最左前缀原则”。比如我建了idx_name_age(name, age)那么WHERE name张三和WHERE name张三 AND age18都能走索引但单独WHERE age18走不了因为索引是先按name排序再按age排序的。理解了这个逻辑你就知道为什么不要把区分度低的字段放在索引前面了。索引类型方面日常不用背太多只要分清主键索引、唯一索引、普通索引和组合索引就够了。全文索引用得少一般交给Elasticsearch了。空间索引更是冷门提一嘴就行。4.2 EXPLAIN和慢查询日志定位光会建索引不行你得知道SQL到底有没有走索引这就是EXPLAIN的主场。看执行计划时我通常只盯几个列type从好到坏大约是system、const、eq_ref、ref、range、index、ALL看到ALL基本就是全表扫描。key实际使用的索引名为NULL说明没走索引。rows预估扫描行数行数越大性能越差。Extra如果出现Using filesort或Using temporary说明排序和分组用了临时方式。慢查询日志是定位线上问题的利器。平时可以开着阈值别设太高我一般设2秒SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 2; SET GLOBAL slow_query_log_file /var/log/mysql/slow.log;设置完以后可以用mysqldumpslow这个工具对慢日志做统计排序直接看哪些SQL最耗时mysqldumpslow -s t -t 10 /var/log/mysql/slow.log这个工具输出了TOP 10的慢SQL按时间排序基本能快速锁定核心问题。之后再用EXPLAIN一个一个分析该加索引的加索引该改写SQL的改写SQL。4.3 索引失效的典型场景这里必须手动列一下我踩过的坑都是血泪对索引字段做了函数运算比如WHERE DATE(created_at)2025-01-01索引直接失效正确写法是created_at 2025-01-01 AND created_at 2025-01-02。隐式类型转换比如varchar字段和数字比较WHERE phone 13800000000phone是varchar这个比较会触发转换索引失效。前导模糊匹配LIKE %abc永远走不了索引LIKE abc%可以。OR条件里有非索引列整个查询可能放弃索引。出现这些情况EXPLAIN里都能看出来所以别靠猜直接跑一次EXPLAIN。经验丰富的人甚至会盯着type从ALL改成ref的那一下感觉比什么都爽。5. 事务、锁与存储过程把并发和逻辑做扎实5.1 事务的开启、提交、回滚与隔离级别事务这块面试里经常被问“ACID是什么”但实操里最重要的其实是事务边界控制。MySQL默认是自动提交的所以你单独执行一条UPDATE它自己就COMMIT了。手动控制事务常用这样一组命令START TRANSACTION; -- 或者用 BEGIN; UPDATE user SET age age 1 WHERE id 1; -- 检查结果没问题就提交 COMMIT; -- 有任何异常就回滚 ROLLBACK;隔离级别决定了事务与事务之间的可见性MySQL InnoDB默认是REPEATABLE READ也就是可重复读。查看和修改隔离级别的命令SHOW VARIABLES LIKE transaction_isolation; -- 8.0之前叫 tx_isolation SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;实际业务里大多数系统用READ COMMITTED就够了能减少很多间隙锁带来的死锁问题。但如果你要保证同一个事务里多次读到的数据一致还是得用默认的REPEATABLE READ。这个选择要结合具体业务来别一味追求高隔离级别。说到事务还有个常见误区把事务开得特别大比如在一个事务里更新几万条数据后果就是持有锁时间长、undo log膨胀、主从延迟加剧。我建议事务里只做必须做的事情能拆小就拆小。5.2 锁的分类与死锁排查“mysql锁的分类”是搜索热词也是面试高频题。从粒度上分有表锁、页锁、行锁从模式上分有共享锁读锁和排他锁写锁InnoDB在REPEATABLE READ隔离级别下还引入了间隙锁和临键锁Next-Key Lock它们是为了解决幻读用的。对应到命令上最常用的是查看当前锁和事务-- 8.0里查data_locks SELECT * FROM performance_schema.data_locks\G -- 查正在运行的事务 SELECT * FROM information_schema.innodb_trx\G -- 看锁等待和死锁信息 SHOW ENGINE INNODB STATUS\GSHOW ENGINE INNODB STATUS的输出里有一段对死锁的分析会告诉你最近一次死锁是怎么产生的、哪些事务参与了、持有哪些锁。排查死锁时我一般的做法是先看innodb_trx里哪些事务长时间不提交再用data_locks看锁的等待关系最后把阻塞源头的事务杀掉-- 找到要杀的事务ID后 KILL [trx_mysql_thread_id];预防死锁的关键是让所有事务按相同的顺序访问资源。比如事务A先更新id1再更新id2事务B也保持这个顺序就不容易死锁。如果两个事务顺序相反那死锁几乎必然发生。5.3 存储过程的创建与调用存储过程在MySQL里用得不如SQL Server和Oracle那么频繁但某些场景批量数据处理、定时任务、报表生成还是挺香的。创建存储过程的语法有几个注意点默认分隔符是分号而存储过程内部大量使用分号所以要先改DELIMITER。DELIMITER // CREATE PROCEDURE sp_get_user_count(IN p_age INT, OUT p_count INT) BEGIN SELECT COUNT(*) INTO p_count FROM user WHERE age p_age; END // DELIMITER ; -- 调用 CALL sp_get_user_count(20, cnt); SELECT cnt; -- 删除 DROP PROCEDURE IF EXISTS sp_get_user_count;存储过程里还能定义变量、写游标、做循环功能是完整的。但我个人的建议是存储过程不是不能用而是要克制。它最大的问题是调试困难、版本管理麻烦、不太好做单元测试一旦业务逻辑复杂起来维护成本比应用代码高得多。如果你只是想批量做点数据清洗用存储过程没毛病如果核心业务逻辑都塞进存储过程后患无穷。6. 运维必备备份、容器化部署与权限6.1 mysqldump备份与恢复备份是DBA最不能偷懒的活儿。mysqldump是MySQL自带的逻辑备份工具简单场景一条命令就够mysqldump -u root -p --single-transaction --master-data2 shop /backup/shop_$(date %F).sql--single-transaction这个参数很重要它利用InnoDB的一致性快照让备份过程中不锁表适合在线备份。如果库里还有MyISAM表那就免不了要加--lock-all-tables会短暂锁库。--master-data2会在备份文件里记录当时binlog的文件名和位置做恢复和主从复制时非常有用。数据量不大的时候逻辑备份够用单表几个GB起步就得考虑物理备份方案比如Percona XtraBackup那个就更复杂了。恢复的命令很简单把备份文件导回去就行mysql -u root -p shop /backup/shop_2025-01-01.sql如果是全库备份恢复时就不用指定库名mysql -u root -p /backup/all_db_2025-01-01.sql还有一点要提醒备份脚本必须定期做恢复演练。我见过太多人以为备份文件在那放着就万事大吉真出事恢复时才发现备份文件是坏的、或者权限不足那才叫欲哭无泪。6.2 Docker部署MySQL及典型失败原因用Docker装MySQL是这几年最常见的部署方式一条docker run就能拉起来一个实例docker run -d --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDYourPassword \ -e TZAsia/Shanghai \ -v /opt/mysql/data:/var/lib/mysql \ mysql:8.0几个关键点数据卷一定要挂出来不然容器一删数据就没了时区环境变量记得设置不然数据库时间和你本地对不上root密码通过环境变量传首次启动初始化时会生效。docker安装mysql失败的情况我也踩过不少最常见的有这几种端口被宿主机占用-p 3306:3306起不来换一个宿主端口比如-p 3307:3306。数据目录已经有旧数据容器第一次启动时如果挂载的目录不为空且已有初始化过的数据那么MYSQL_ROOT_PASSWORD就不会自动生效你需要用之前那个老密码登录或者清空目录重新初始化。认证插件问题MySQL 8.0默认用户认证插件是caching_sha2_password老版本的客户端工具连不上报错“Authentication plugin caching_sha2_password cannot be loaded”。解决方法是连接时指定--default-authmysql_native_password或者进容器里把用户认证方式改为mysql_native_password。6.3 用户与权限管理命令权限管理是命令手册里绝对不能少的。很多人一开始为了方便直接用root账号连应用这是很大一个坑。正规做法是按应用需要创建专用账号只给最小权限-- 创建用户 CREATE USER app% IDENTIFIED BY App2025; -- 只给业务库的部分权限 GRANT SELECT, INSERT, UPDATE, DELETE ON shop.* TO app%; -- 如果需要管理权限 GRANT ALL PRIVILEGES ON shop.* TO adminlocalhost; -- 收回权限 REVOKE DELETE ON shop.* FROM app%; -- 查看权限 SHOW GRANTS FOR app%; -- 刷新权限 FLUSH PRIVILEGES;注意app%里的%表示允许任意主机连接如果你只想让应用服务器连把%换成具体的IP更安全。另外如果你要做MySQL到ClickHouse的数据同步用Flink CDC或者Canal这类工具还需要额外给账号一些复制权限GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO sync%;没有这些权限CDC工具抓取binlog时会报权限不足的错误。7. 面试题里的高频考点其实都在命令背后7.1 索引为什么能加速查询面试问“索引为什么快”本质上问的是B树这个数据结构。InnoDB的索引是一棵B树这棵树矮胖一个三层高的树就能存上千万条记录。查询时从根节点往下走每层做一次二分查找走三四个节点就能定位到目标而全表扫描是一次性读几万甚至几十万个数据页。这一对比性能差距就出来了。对应到命令层面就是我前面说的EXPLAIN。你能用EXPLAIN把一条SQL从全表扫描ALL优化到走索引ref就说明你理解了这个原理面试官自然认可。再引申一下覆盖索引为什么更优因为索引里已经包含了查询需要的所有列就不需要回表查数据行了Extra里会出现Using index这是很理想的查询状态。7.2 为什么总是让你别用SELECT *很多公司规约里都有一条“禁止SELECT *”表面上是规范本质是IO和网络传输的问题。SELECT *把所有列都捞出来如果表有几十个字段其中好几个还是大字段那一次查询就把大量无用的数据从存储引擎传到Server层再通过网络传到应用纯属浪费。更关键的是如果查询条件匹配的列正好有索引但你要的是所有列索引里没有就必须回表这又增加了一次随机IO。我们看优化手段其实也是从命令切入的用EXPLAIN确认查询是否走了索引用SHOW PROFILE或者performance_schema看时间花在哪然后改写SQL。面试题看着很高大上拆开全是命令和日志的组合。8. 最后分享几个命令行小习惯这几条不算什么复杂的知识但确实是我用了十几年MySQL之后最想留下的几条第一能用\G就用\G。命令行输出一条十几个字段的记录分号结尾会横向铺开换行换得眼睛疼\G一竖排所有字段一目了然。这个习惯从5.5时代一直延续到现在谁用谁知道。第二批量执行SQL文件时别裸着跑加个--force和--show-warningsmysql -u root -p --force --show-warnings big_upgrade.sql就算中途某条语句报错也可以继续往下执行最后还能把所有警告汇总出来排查问题方便很多。第三客户端里也能开日志。在MySQL客户端中执行tee /tmp/mysql_output.log;后面所有命令和输出都会记录到这个文件里做完一轮操作回头翻日志比截屏靠谱。第四登录时把默认字符集写清楚。只要你的表是utf8mb4连接时最好就带上--default-character-setutf8mb4不然中文条件查询偶尔会出乱码或者查不到。第五别怕敲命令。很多新手一看到密密麻麻的参数就发怵其实核心参数就几个多敲几遍肌肉记忆就出来了。真要记不全随时mysql --help、mysqldump --help这些内置帮助比搜索引擎来得准。MySQL常用命令这条路说白了就是熟能生巧。从装库到连库、从查询到索引、从事务到锁、从备份到恢复每一步都有对应的命令和逻辑。把这些串起来你手里的MySQL就不再是一个黑盒而是一个你能跟它对话的系统。
