本文首发于 CSDN，转载请注明出处。
MySQL 的命令不难，但数量多、又不常写，结果就是每次动手都要翻一遍文档。真正高频的其实只有几十条，按「连接 → 库表 → 账号 → 备份 → 排查」这五类记住结构，用的时候顺着找就行。这篇把它们整理成一张速查表，命令都标注了使用场景。
你用的是哪个版本？
在敲命令之前先确认版本，因为 8.0 已经停止支持了：
| 版本 | 状态 | 建议 |
|---|---|---|
| 5.7 | 已停止支持 | 尽快评估升级，安全更新已没有 |
| 8.0 | 2026 年 4 月停止支持 | 存量系统尽快规划迁移 |
| 8.4 LTS | 当前长期支持版 | 新项目直接选它，支持到 2032 年 |
| 9.x | 创新版 | 想用新特性时考虑，不适合求稳的生产环境 |
用SELECT VERSION();可以随时确认当前连接的是哪个版本。迁移到 8.4 时有几个默认值变化需要留意，尤其是旧版兼容的认证插件在新版默认是关闭的，老客户端可能连不上，这属于迁移前期就要验证的事项。
连接和查看基本信息
| 命令 | 用途 |
|---|---|
mysql -u root -p | 用密码登录本机实例 |
mysql -h 10.0.0.5 -P 3306 -u app -p | 连接远程实例 |
mysql -u root -p dbname < dump.sql | 登录的同时直接导入 |
SELECT VERSION(); | 查看服务端版本 |
SHOW STATUS LIKE 'Threads_connected'; | 当前连接数 |
SHOW VARIABLES LIKE 'max_connections'; | 最大连接数上限 |
SHOW PROCESSLIST; | 查看正在跑的查询（排查卡顿第一步） |
SHOW PROCESSLIST值得单独记住。线上出现响应变慢时，第一反应应该是看当前有哪些查询在跑、哪个状态是Locked或长时间Sending data，这比盲目重启有效得多。
库和表怎么操作？
| 命令 | 用途 |
|---|---|
SHOW DATABASES; | 列出所有库 |
CREATE DATABASE app_db DEFAULT CHARSET utf8mb4; | 建库，字符集一律用 utf8mb4 |
USE app_db; | 切换当前库 |
SHOW TABLES; | 列出当前库的表 |
SHOW CREATE TABLE orders; | 查看建表语句（含索引定义） |
DESC orders; | 查看表结构 |
SHOW INDEX FROM orders; | 查看索引 |
字符集这里有个常见误区：utf8mb4 才是完整的 UTF-8 实现，能存四字节字符（emoji、部分生僻字）。MySQL 里那个叫utf8的字符集实际只支持三字节，存 emoji 会直接报错。新库一律用 utf8mb4。
改表结构时要小心，ALTER TABLE在大表上可能锁表很久。修改前先确认表的行数规模和 MySQL 版本——新版对部分在线 DDL 支持更好，但并不是所有变更都能在线做。
账号和权限怎么管？
| 命令 | 用途 |
|---|---|
CREATE USER 'app'@'%' IDENTIFIED BY 'StrongPass!'; | 建账号 |
GRANT SELECT, INSERT ON app_db.* TO 'app'@'%'; | 授权（最小权限原则） |
REVOKE DELETE ON app_db.* FROM 'app'@'%'; | 回收权限 |
SHOW GRANTS FOR 'app'@'%'; | 查看某账号的权限 |
FLUSH PRIVILEGES; | 直接改权限表后刷新 |
ALTER USER 'app'@'%' IDENTIFIED BY 'NewPass!'; | 改密码 |
DROP USER 'app'@'%'; | 删账号 |
两条实践纪律：应用账号不要用 root，也不要用'%'通配所有来源 IP——限定到应用服务器的网段更安全。授权按最小权限给，只读业务的账号不要给写权限，避免代码出 bug 时直接改坏数据。
备份和恢复要怎么做？
| 命令 | 用途 |
|---|---|
mysqldump -u root -p app_db > app_db.sql | 备份单个库 |
mysqldump -u root -p --databases app_db log_db > two.sql | 备份多个库 |
mysqldump -u root -p --all-databases > all.sql | 备份全部库 |
mysqldump -u root -p --single-transaction app_db > app_db.sql | 不锁表的备份（InnoDB 必加） |
mysql -u root -p app_db < app_db.sql | 恢复 |
| `mysqldump … | gzip > app_db.sql.gz` |
--single-transaction这条参数要特别记住：不加它，备份过程可能锁定表，线上直接备份会影响业务。加它之后，InnoDB 表在不阻塞写入的情况下也能拿到一致性快照。
备份还有一条铁律：备份文件必须验证过能恢复。只备份不演练，等于没有备份。做法是定期把一个备份文件恢复到临时实例，确认数据完整。
性能排查常用哪几句？
| 命令 | 用途 |
|---|---|
EXPLAIN SELECT ...; | 查看执行计划，看有没有走索引 |
SHOW FULL PROCESSLIST; | 看到完整 SQL 而不只是截断的片段 |
SHOW ENGINE INNODB STATUS; | 查看最近一次死锁信息 |
SHOW STATUS LIKE 'Slow_queries'; | 慢查询累计数量 |
SHOW VARIABLES LIKE 'slow_query_log'; | 确认慢查询日志是否开启 |
排查慢查询的标准路径是：先开慢查询日志定位到具体 SQL，再用EXPLAIN看它的执行计划，重点看type列是不是ALL（全表扫描）以及rows估算扫描行数。索引没走上的常见原因是查询条件上做了函数运算、或者不符合最左前缀原则。
把这类速查内容整理完发布之后，后续的收录和引用情况我会用墨衍跟一下：批量 GEO 检测看这些内容在 AI 搜索里有没有被引用，AI 图文同步把一份稿子推到多个平台，发文额度提升在集中更新时省掉额度限制。墨衍会员权益 有兴趣可以看看。
几个常见的坑
备份文件很大但没验证过。定期做恢复演练，这是备份方案能成立的前提。
生产环境直接执行 DELETE 不加 WHERE。数据量大时先用 SELECT 确认条件命中范围，再改成 DELETE，并且提前做好备份。
线上改表结构不评估锁表时长。大表的字段变更要安排在低峰期，或改用在线改表工具。
连接数打满。应用侧连接池配置过大，或者代码里有连接泄漏。先看Threads_connected是不是贴近max_connections。
时区导致的时间错乱。数据入库时间和预期差 8 小时，通常是服务端time_zone配置问题，用SELECT @@global.time_zone, @@session.time_zone;确认。
常见问题
Q：8.0 还能继续用吗？
能跑，但已经没有安全更新了。跑在公网或不满足内网隔离要求的实例应尽快规划迁移，优先目标就是 8.4 LTS。
Q：迁移到 8.4 最容易踩什么坑？
认证插件默认值的变化最常导致老客户端连不上，其次是部分废弃语法和默认参数调整。迁移前先用备份恢复到测试实例跑一遍完整业务回归，比直接升生产稳妥。
Q：为什么要用 utf8mb4 而不是 utf8？
MySQL 的utf8只支持最多三个字节，存不下四字节字符。utf8mb4 才是完整的 UTF-8，能覆盖 emoji 和生僻字。
Q：mysqldump 备份几百 G 的库可行吗？
可以但不理想，速度慢且恢复耗时长。超大库更适合物理备份方案，或者按库表拆分备份并行执行。
Q：查询不走索引怎么办？
先EXPLAIN看执行计划。常见原因是条件字段上加函数、类型隐式转换（字符串字段用数字比较）、或者联合索引没用上最左列。
关于墨衍：如果你也在多个平台发技术文章，值得看看墨衍。三个最常用的权益——发文额度提升（密集更新不再受限）、批量 GEO 检测（一次扫完全部文章的 AI 引用状态）、AI 图文同步（一稿多平台分发）。点这里了解墨衍会员
