企业官网建设流程全解析

1. 连接与基础环境命令：先把门敲开再谈别的

很多人学MySQL命令，第一步就走偏了——上来就背SELECT怎么写，结果连自己登的是哪台机器、用的哪个账号、字符集对不对都没搞清楚，后面查出来的数据全是乱码，还以为是数据本身的问题。我在带新人时经常说一句话：命令是手，环境是眼，眼睛没睁开，手再快也白搭。这一章就把连接层和基础环境相关的命令一次性捋清楚，这些命令你每天开工前基本都要敲一遍。

1.1 登录连接的几种姿势与参数拆解

最基础的登录命令长这样：

mysql -h 主机地址 -P 端口 -u 用户名 -p

这里有个细节值得展开。-h后面跟的是数据库服务器地址，本地就是127.0.0.1或者localhost；-P是大写，指端口，默认3306，如果你改过端口就必须显式指定，小写-p是密码，这两者别搞混，我见过不止一个人把-p和-P用错导致连不上还排查半天。-u是用户名，-p单独写表示回车后再输入密码，这种写法比直接把密码写在命令里安全，因为密码写在命令行里会留在终端历史记录中，属于典型的安全隐患。

如果你只想快速执行一条命令就退出，不用进入交互界面，可以用-e参数：

mysql -u root -p -e "SHOW DATABASES;"

这个在写脚本、做定时任务的时候特别顺手。还有一个容易被忽视的参数是--default-character-set，当你发现查出来的中文是问号或者乱码时，八成是客户端字符集和服务器不一致，可以这样指定：

mysql -u root -p --default-character-set=utf8mb4

字符集这个问题我想多说两句。现在新项目一律建议用utf8mb4，不要用老的utf8。因为MySQL里那个叫utf8的字符集其实每个字符最多只存3个字节，存不了emoji和一些生僻字，而utf8mb4才是真正完整的UTF-8实现，每个字符最多4个字节。这个坑非常经典，很多老系统升级时都会遇到。

登录进去之后，有几个环境查看命令建议你养成习惯敲一敲：

1.2 数据库层面的基础操作命令

库的操作命令不算多，但每条都有讲究。创建数据库时，明确指定字符集和排序规则是好习惯：

CREATE DATABASE mydb DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

utf8mb4_general_ci里的ci是 case insensitive，表示比较时不区分大小写。如果你对排序精度有要求，比如要按德语、法语的特殊规则排序，可以用utf8mb4_unicode_ci，它遵循Unicode标准排序，但性能会略慢一点。日常业务用general_ci基本够了。

查看、切换、删除数据库的命令分别是：

SHOW DATABASES; USE mydb; DROP DATABASE mydb;

DROP DATABASE这条命令我每次都要提醒：它会连同库里的所有表和数据一起删掉，且默认无法恢复。生产环境执行前，务必确认你连的不是主库，最好先在测试库演练一遍。

另外还有一个查看建库语句的命令，迁移或者复盘时很有用：

SHOW CREATE DATABASE mydb;

它会把你当时建库的完整SQL语句还原出来，包括字符集设置，这样你就能确认线上库到底用的什么字符集，而不是凭记忆猜。

1.3 帮助命令：被严重低估的自救工具

MySQL自带一个帮助系统，很多人从来没用过。当你忘了某个命令的参数怎么拼，不用去翻网页，直接在客户端里敲：

HELP SELECT; HELP CREATE TABLE; HELP SHOW;

它会返回这个命令的语法说明和常用选项。虽然格式不算漂亮，但对命令行环境下快速自查特别有用。我个人的习惯是，凡是那种半年才用一次、每次都要查文档的命令，比如GRANT、ALTER TABLE的复杂子句，我都会先用HELP看一眼语法骨架，避免凭记忆写错关键字。

提示：帮助内容依赖本地安装的帮助表，部分精简版或云数据库实例可能没有加载帮助数据，如果HELP返回空，不用怀疑命令写错了，是帮助库没装。

2. 表结构操作命令：DDL才是日常踩坑重灾区

数据查询写得再溜，表结构不合理照样白搭。DDL（数据定义语言）这一块，看起来就是建表改表删表，但真正在项目里出问题的往往就是这里。字段类型选错、索引忘了建、改表把线上锁住，这些事故的根源都在DDL命令上。这一章把建表、改表相关的命令和背后的注意事项讲透。

2.1 建表命令与字段类型选择逻辑

一个规范的建表语句大概是这样：

CREATE TABLE user ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, username VARCHAR(64) NOT NULL, age TINYINT UNSIGNED DEFAULT 0, balance DECIMAL(12,2) DEFAULT 0.00, status TINYINT DEFAULT 0, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username), KEY idx_status (status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这段语句里每个选择都有理由。主键用BIGINT UNSIGNED而不是INT，是因为INT最大约21亿，订单号、用户量大的系统很容易撑爆；DECIMAL(12,2)用来存金额，绝对不能拿FLOAT或DOUBLE存钱，浮点数会有精度丢失，0.1+0.2不等于0.3这种事在财务数据里是致命的；TINYINT存状态码，既省空间又清晰。

UNIQUE KEY和普通KEY的区别也很关键。UNIQUE约束了唯一性，除了加速查询还能防止重复数据；普通索引只加速查询不做限制。像用户名这种不能重复的字段，用唯一索引比在代码里先查再插要可靠得多，因为并发情况下代码判断存在竞态，唯一索引由数据库层保证，是最后一