本文首发于 CSDN转载请注明出处。MySQL 的命令不难但数量多、又不常写结果就是每次动手都要翻一遍文档。真正高频的其实只有几十条按「连接 → 库表 → 账号 → 备份 → 排查」这五类记住结构用的时候顺着找就行。这篇把它们整理成一张速查表命令都标注了使用场景。你用的是哪个版本在敲命令之前先确认版本因为 8.0 已经停止支持了版本状态建议5.7已停止支持尽快评估升级安全更新已没有8.02026 年 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;建库字符集一律用 utf8mb4USE 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;确认。常见问题Q8.0 还能继续用吗能跑但已经没有安全更新了。跑在公网或不满足内网隔离要求的实例应尽快规划迁移优先目标就是 8.4 LTS。Q迁移到 8.4 最容易踩什么坑认证插件默认值的变化最常导致老客户端连不上其次是部分废弃语法和默认参数调整。迁移前先用备份恢复到测试实例跑一遍完整业务回归比直接升生产稳妥。Q为什么要用 utf8mb4 而不是 utf8MySQL 的utf8只支持最多三个字节存不下四字节字符。utf8mb4 才是完整的 UTF-8能覆盖 emoji 和生僻字。Qmysqldump 备份几百 G 的库可行吗可以但不理想速度慢且恢复耗时长。超大库更适合物理备份方案或者按库表拆分备份并行执行。Q查询不走索引怎么办先EXPLAIN看执行计划。常见原因是条件字段上加函数、类型隐式转换字符串字段用数字比较、或者联合索引没用上最左列。关于墨衍如果你也在多个平台发技术文章值得看看墨衍。三个最常用的权益——发文额度提升密集更新不再受限、批量 GEO 检测一次扫完全部文章的 AI 引用状态、AI 图文同步一稿多平台分发。点这里了解墨衍会员