MySQL之创建表的基本操作说起来有点不好意思我干了这么多年后端开发面试过不少人发现一个挺普遍的现象很多候选人能把复杂的查询、存储过程讲得头头是道但让他手写一张业务表的建表语句反而漏洞百出。不是忘了主键就是字符集没指定更有甚者连字段类型都选得稀里糊涂。我印象很深的一次有位候选人建一张用户表手机号字段用了text类型理由是想存得下“以后的国际区号”听得我一愣一愣的。其实创建表这事儿恰恰是MySQL里最基础也最见功力的一步。它决定了一张表后续的查询性能、扩展空间、数据完整性甚至决定了整个项目后期要不要花大把时间做重构。这篇文章我就结合自己这些年实际写过的建表语句把MySQL创建表的基本操作从头到尾捋一遍包括语法细节、字段类型选择的门道、约束与索引的设计思路以及建完之后怎么验证、怎么修改。不管你是刚入行的新手还是写了好几年SQL但没仔细抠过细节的同行这篇都值得花几分钟过一遍。1. 建表之前先想清楚这张表要装什么很多人打开客户端就开始敲CREATE TABLE敲到哪儿算哪儿字段想到一个加一个类型随手选一个顺眼的。这样建出来的表跑通Demo没问题一旦数据量上来或者业务逻辑变复杂各种问题接踵而至。所以我特别想强调建表操作本身只需几秒钟但前面的设计思考才决定了这张表的命运。1.1 需求分析至少回答三个问题在写第一条SQL之前我会先问自己三个问题第一个问题这张表承载的是什么业务对象我在某公司做电商项目时订单模块涉及到的表就有订单主表、订单明细表、订单状态流转表、支付记录表、退款记录表等七八张。如果连业务对象没梳理清楚就把字段全部塞进一张表后期拆分会非常痛苦。做任何一张表之前先把业务对象罗列清楚搞清楚它跟其他对象的关系是一对一、一对多还是多对多。第二个问题这张表的数据量预估有多大会持续增长到什么量级这个直接决定字段类型的选择。比如一张存储用户登录日志的表一天可能就产生几十万行跟一张存储系统配置项的表可能就几十行完全是两个设计思路。前者要精打细算字段长度、考虑分区和归档后者可以稍微宽松一些。第三个问题这张表会被怎样访问是频繁写入还是只读是按某个字段频繁查询还是全表扫描需不需要支持事务这些问题直接影响引擎类型的选择、索引的设计。大二那年我第一次用MySQL给一张临时分析用的表设置了InnoDB后来才发现用MyISAM做只读报表在特定场景下资源占用会更低——当然这是古早年代的做法现在的主流选择基本都是InnoDB但“先想清楚访问模式”这个习惯我一直保留着。1.2 字段命名与类型规划宁可多花十分钟做需求分析的时候我会顺手把字段清单列出来。我曾经接手过一个老项目里面的字段名五花八门有的用中文拼音缩写有的用驼峰有的带前缀f_看得人脑壳疼。后来我养成了习惯所有字段名使用小写下划线风格比如user_name、order_amount不使用MySQL关键字作为字段名。字段类型也要在规划阶段就定下来不要到写SQL的时候再纠结。这里有一个比较实际的建议不确定的时候先去查一下MySQL官方文档对每个类型的定义和取值范围不要凭感觉选。我记得自己在练习阶段给一张学生表的“年龄”字段用过int后来才意识到用tinyint就够了——年龄不可能超过255用int纯属浪费存储空间。字段类型规划这事细节处见水平。2. 动手前的基础连接数据库与语法骨架规划做完才轮到真正执行CREATE TABLE。不过在那之前得先能连上MySQL服务器。2.1 怎么连上数据库从命令行到客户端工具最基础的方式是在命令行里使用MySQL自带的客户端程序。假设MySQL服务跑在本地端口是默认的3306可以用下面这条命令登录mysql -u root -p回车之后输入密码就进入了MySQL的命令行交互环境。如果MySQL不在本机需要指定主机地址和端口mysql -h 你的服务器地址 -P 3306 -u root -p命令行方式的好处是轻量、快捷任何一台装了MySQL的机器都能用不需要额外安装软件。我平时排查线上问题时基本都用它。但日常开发中大多数人更习惯用图形化工具。我自己常用的几款工具特点适用场景MySQL WorkbenchMySQL官方出品功能全面自带ER图、性能监控日常开发、设计表结构Navicat界面美观功能强大支持多数据库需要管理多种数据库的场景DBeaver开源免费跨平台插件丰富预算有限或偏爱开源工具终端直接操作最轻量无图形界面依赖服务器排查、快速验证不管用哪种方式连上之后先别急着建表。第一时间执行下面两条命令确认当前环境SELECT VERSION(); SHOW DATABASES;SELECT VERSION()能告诉你当前MySQL的版本这很重要因为不同版本在字符集默认值、索引实现细节上都有差异。SHOW DATABASES展示当前实例下有哪些数据库你需要确保自己是在正确的库里建表。2.2 CREATE TABLE的基本语法结构创建一张表最核心的语法是这样CREATE TABLE [IF NOT EXISTS] 表名 ( 字段名1 数据类型 [列级约束] [默认值] [注释], 字段名2 数据类型 [列级约束] [默认值] [注释], ... [表级约束] ) ENGINE存储引擎 DEFAULT CHARSET字符集 COLLATE排序规则;这里面有一个关键点容易被忽略中括号里的东西都是可选项但实际建表时这些可选项才是真正体现水平的地方。很多新手写的建表语句只有字段名和类型引擎不写、字符集不写、注释不写建出来的表问题不少。举个实际例子。我最早练习建表时写过这样一条语句CREATE TABLE student ( id INT PRIMARY KEY, name VARCHAR(50) );就这么三行当时的我觉得“简洁美观”。后来有一天我需要给表加注释才发现之前的表连字符集都没指定完全依赖MySQL的全局默认配置。如果服务器默认字符集是latin1那么存中文极大概率会变成乱码。从那以后我建表必定把下面这些信息全部写全CREATE TABLE IF NOT EXISTS student ( id INT NOT NULL AUTO_INCREMENT COMMENT 学生ID主键, name VARCHAR(50) NOT NULL DEFAULT COMMENT 学生姓名, age TINYINT UNSIGNED NOT NULL DEFAULT 0 COMMENT 年龄, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_general_ci COMMENT学生信息表;IF NOT EXISTS的作用是如果表已经存在MySQL不会报错而是给出一个Warning这在执行脚本文件时特别有用可以避免重复执行整个脚本时中断。2.3 临时表、普通表与永久表的区别顺带提一个容易被新手混淆的概念CREATE TABLE创建的普通表是永久存储的数据写入后只要不手动删除就会一直存在。而CREATE TEMPORARY TABLE创建的是临时表只在当前连接会话内有效会话关闭后自动销毁。我在做复杂的多表查询或者数据处理时偶尔会用临时表保存中间结果。它的好处是不用担心污染正式数据也用不着手动清理。但有两点需要留意一是临时表的名字可以和普通表重名此时在会话内访问到的是临时表二是如果连接采用的是连接池方式连接被回收复用之后临时表并不会销毁这也是一些莫名其妙的“幽灵数据”的来源。所以我用临时表有个习惯用完就DROP TEMPORARY TABLE或者干脆在业务代码里开独立会话来处理。3. 字段类型选错才叫真返工类型选择的门道创建表最核心的工作之一就是给每个字段挑选合适的数据类型。这一步看起来不起眼却直接影响存储空间和查询效率。我见过太多返工的案例都是因为一开始类型选错了导致后期数据迁移、SQL改造连轴转。下面把这些年最容易踩坑的几类字段类型逐个说一下。3.1 整数类型别再被int(11)误导MySQL提供了tinyint、smallint、mediumint、int、bigint这几种整数类型存储空间从1字节到8字节不等。选型的唯一依据是取值范围而不是“看着大”或“全都用int省心”。我汇总了它们的存储空间和有符号范围方便对照类型存储字节有符号范围无符号范围TINYINT1-128 ~ 1270 ~ 255SMALLINT2-32768 ~ 327670 ~ 65535MEDIUMINT3-8388608 ~ 83886070 ~ 16777215INT4-2147483648 ~ 21474836470 ~ 4294967295BIGINT8-9.22e18 ~ 9.22e180 ~ 1.84e19关于整数类型有一个流传很广的误解int(11)里面的11代表“最大能存11位数字”。实际上这个数字只是显示宽度并且从MySQL 8.0开始显示宽度已经被废弃。也就是说int(1)和int(11)在存储能力上没有任何区别都是4字节的整数能存储的数值范围完全相同。我之前面试过不少人在这个问题上栽跟头的比例相当高。实际选型建议用户状态、布尔标识这类字段用tinyint年龄、订单数量这类用smallint或mediumint足够主键如果不是特别极端的场景用bigint更稳妥因为int的上限在数据量大时真的会碰到。我曾经在一家做IoT平台的公司遇到一个真实事故设备上报记录表的自增主键用int数据量上来后到了21亿的上限插入直接报错整个写入链路雪崩。那次事故之后我对自增主键一律推荐bigint哪怕当时看起来用不了那么大。如果字段明确不可能为负记得加上UNSIGNED修饰等于把正数上限翻倍。但也注意两个UNSIGNED字段做减法时如果结果为负会报错或得到一个大得离谱的数值这种边界问题要心里有数。3.2 字符串类型char、varchar与text的取舍字符串类型里最常用的就是char和varchar。char(n)是定长字符串无论实际存储内容多短都占用n个字符的存储空间。例如char(10)就算只存了“abc”也会占用10个字符的空间。它的优势在于存储和检索效率略高适合存储长度基本固定的字段比如MD5哈希值固定32位、身份证号18位、手机号11位。varchar(n)是变长字符串实际占用空间是数据长度加一定的额外字节用来记录实际长度。varchar(10)存“abc”只占3个字符空间。它适合存储长度差异大的字段比如用户名、地址、商品标题。这里需要提醒一个非常常见的坑varchar(255)和varchar(256)在索引上有本质区别。MySQL的InnoDB索引对varchar字段一个前缀索引或者普通索引能使用的最大长度受到页大小限制。在utf8mb4字符集下varchar(255)可以完整创建索引而varchar(256)在旧版本中可能因为索引长度超过767字节而创建失败。所以在不确定情况下varchar(255)是最安全的长度选择。至于text类型它适合存长文本比如文章正文、日志详情。但text字段有几个毛病不能有默认值在MySQL 8.0之前不能直接全文索引需要特殊处理在查询时如果不是必要应避免直接SELECT出来否则很容易让临时表跑在磁盘上性能骤降。所以我的原则是能用varchar解决就不上text长文本单独拆表存主表只存一个外键关联。3.3 时间类型datetime与timestamp的取舍MySQL常用的时间类型有date、time、datetime、timestamp、year。业务开发中datetime和timestamp是主要候选人。datetime的存储空间是8字节表示的范围是1000年到9999年完全不受时区影响。它适合存业务发生时间尤其是历史数据、合同时间这种不应该随系统时区变化的时间点。timestamp的存储空间是4字节范围是1970年到2038年这个上限问题被戏称为“2038年问题”它跟时区绑定存储时把当前时刻从会话时区转成UTC保存读取时再转回会话时区。如果你需要表示一个“时刻”而不仅仅是“日历时间”timestamp是合适的。举例来说在一个跨国项目中“用户点赞时刻”这种字段用timestamp更合适因为无论用户在哪个时区看到的时间都是他的本地时间。我个人的实践是业务表中记录创建时间和更新时间统一用datetime配默认值CURRENT_TIMESTAMP这样能避开时区切换带来的坑调试也更直观。“创建时间”字段设默认值DEFAULT CURRENT_TIMESTAMP“最后修改时间”字段加ON UPDATE CURRENT_TIMESTAMP这样只要一行被更新这个字段会自动刷新省去了在业务代码里手动赋值的麻烦。3.4 DECIMAL处理金额的精度问题这也是一个高频踩坑点。我在某电商项目里见过有人用float存商品价格结果一算账就差了0.01客户对账对不上最终只好写脚本批量修正。float和double是浮点数以二进制方式存储近似值精度会丢失绝对不能用于金额。金额必须用定点数decimalprice DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 商品单价单位元decimal(10,2)表示总位数10位小数2位也就是最大能存99999999.99。定点的本质是字符串存储能精确表达小数不会出现浮点误差。做金额字段时我统一用decimal至于小数点后要保留几位视业务币种而定人民币一般2位积分、汇率等可能需要4位甚至6位。4. 约束与索引建表时一次做对建表语句里除了字段定义还有一件事至关重要约束与索引。约束保证数据的正确性和完整性索引决定查询的效率和性能。很多人习惯表建完之后再单独加索引我的建议是能在建表时就设计好的约束必须一次性加进去。4.1 主键、唯一键、外键各自管什么主键PRIMARY KEY唯一标识一行数据不能为NULL表里通常只有一个。主键的选择有两个流派自然主键和代理主键。自然主键用业务字段本身比如身份证号、学号代理主键用一个跟业务无关的自增ID或UUID。我在业务表里绝大多数情况下用自增bigint作为代理主键简单、高效、天然有序回表查询也快。但要说明的是如果一张表有分布式数据合并的需求自增ID会产生冲突这时需要考虑UUID、雪花ID等方案。唯一键UNIQUE KEY保证某个字段或某几个字段的组合在整张表中不重复。它跟主键的区别是唯一键可以为NULL且一张表可以有多个唯一键。举个例子用户表的主键是user_id但同时又要求邮箱不能重复就可以给email加唯一键。MySQL中唯一键的NULL值是可以重复的在默认规则下这个特性和大多数人直觉相悖容易出现“明明加了唯一索引NULL还能插入多条”的情况你需要明确知道这是数据库的设计行为。外键FOREIGN KEY约束当前表的某个字段必须在关联表的主键中存在。它保证了引用完整性比如订单表中的user_id外键指向用户表的id那么订单表就无法插入一个不存在的用户。但在互联网高并发业务里外键并不是一个受欢迎的东西它会让数据写入多一步校验影响插入性能还容易在分库分表场景下失效。我在做业务开发时会用外键约束吗说实话很少用。我更倾向于在应用层保证引用关系保留外键约束给那些强一致、低并发、不允许脏数据的核心场景——比如权限系统、财务流水。4.2 给字段加默认值和注释这是很多人都忽略或者嫌麻烦不写的两点但我强烈建议连默认值和注释一起在建表时写好。默认值的作用是插入数据时不显式给这个字段赋值系统自动填入默认值。比如订单表的status字段默认填0代表待支付这样业务代码少传一个参数也不会因为漏传而拿到NULL。注释的作用是给字段加中文说明。写过老项目的人都有体会一张表上一堆英文字段名时间一长谁也记不住哪个字段是干嘛的。加了注释之后后来接手的人乃至三个月后的自己都能靠注释快速看懂表结构。这是一个“前期多花十秒后期省十小时”的操作。4.3 索引不是越多越好很多有几年开发经验的开发者会陷入另一个极端只要发现查询慢就疯狂加索引结果一张表建了十几个索引。索引能加速查询但代价是每次INSERT、UPDATE、DELETE都要同步维护索引树写多读少的表索引多了反而拖垮性能同时索引也占磁盘空间。我的建表习惯是先把主键和唯一键建好再根据实际的WHERE条件、ORDER BY字段设计查询索引。一条普遍的参考原则是索引少而精尽量用联合索引覆盖常见查询。比如表里有user_id和status两个字段经常一起作为查询条件那么建一个(user_id, status)联合索引比单独建两个索引效果更好因为MySQL可以利用最左前缀原则同时命中两个字段。还有一个细节值得注意建立联合索引时字段顺序有讲究。把区分度高的字段放前面把查询频率更高、更常作为独立条件的字段放前面。这个有经验的DBA会跟你讲半天我这里只做一个提醒——建索引之前先把查询模式想清楚。5. 从零建一张订单表完整实操演示理论讲了不少下面我做一次完整的实操。以电商系统里最常见的订单表为例从需求分析到建表完成把整个流程走一遍。这个过程基本把我前面提到的知识点全部串起来了。5.1 订单表的需求与字段设计假设业务场景是一个简单的电商平台用户下单购买商品需要存储每一笔订单的核心信息。根据需求我梳理出这些核心字段订单ID唯一标识自增主键订单号对外展示的唯一业务编号比如拼接了日期和随机数的字符串用户ID所属用户关联用户表订单金额商品总金额用decimal存储支付状态用tinyint0待支付、1已支付、2已退款收货地址名称、收货人手机号、收货人姓名快照式数据下单时间记录创建时间支付时间实际支付时间默认NULL订单备注用户填写的留言注意一个设计细节收货人信息我选择直接存字段而不是关联一张地址表。因为从业务角度看订单的收货地址必须是一个“快照”——即使后来用户修改了默认地址、删除了地址记录历史订单里的收货信息也不能变。这跟有些方案里存address_id外键的做法不同属于业务上的合理取舍。5.2 完整建表SQL与执行结果设计完毕我写在SQL脚本里的建表语句是下面这样CREATE TABLE IF NOT EXISTS order ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 订单内部自增主键, order_no VARCHAR(32) NOT NULL DEFAULT COMMENT 对外业务订单号, user_id BIGINT UNSIGNED NOT NULL COMMENT 下单用户ID, total_amount DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT 订单总金额单位元, pay_status TINYINT UNSIGNED NOT NULL DEFAULT 0 COMMENT 支付状态0待支付1已支付2已退款, receiver_name VARCHAR(50) NOT NULL DEFAULT COMMENT 收货人姓名, receiver_phone VARCHAR(20) NOT NULL DEFAULT COMMENT 收货人手机号, receiver_address VARCHAR(255) NOT NULL DEFAULT COMMENT 收货地址, remark VARCHAR(500) NOT NULL DEFAULT COMMENT 用户备注, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 下单时间, payed_at DATETIME DEFAULT NULL COMMENT 支付时间, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id), KEY idx_created_at (created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_general_ci COMMENT订单主表;一点说明表名用了order但ORDER是MySQL的保留字用于ORDER BY所以这里用反引号进行转义。我实际工作中会尽量避免这种命名但为了展示这个常见坑特意保留了这个例子——如果你建表时碰到莫名其妙的语法报错先检查一下表名或字段名是不是命中了保留字。执行这条语句后MySQL会返回Query OK, 0 rows affected。如果加了IF NOT EXISTS且表已存在则会返回一个Warning可以用SHOW WARNINGS;查看具体提示。5.3 我用SHOW CREATE TABLE做过什么建表完成后我几乎一定会执行这条命令SHOW CREATE TABLE order\G\G是命令行客户端里的“竖排显示”开关把每一行的输出单独列一行字段多了也不会歪七扭八地挤在一起。这条命令能直接反推出MySQL实际执行的完整建表语句它比你自己脑子里记的那份更权威因为MySQL会把默认值、注释、字符集这些你漏写的信息自动补齐并显示出来。我之前遇到过几次环境不一致的问题在测试库建的表和正式库的表结构有细微差异排查了半天最后就是靠SHOW CREATE TABLE把两张表的定义拉出来diff问题才一目了然。所以每建完一张表我建议都执行一下这条命令确认最终效果别嫌麻烦。6. 创建完表之后每个新手都差这一步表创建成功不代表整个流程走完了。接下来还有几个动作直接把操作新手和老手的区别拉开。6.1 如何验证表结构除了SHOW CREATE TABLE还需要用DESC看一下表结构概览DESC order;它会以表格形式列出字段名、类型、是否允许NULL、键类型、默认值、备注信息。我一般用它快速核对字段是不是都建上了类型有没有写错。更进一步的可以用SHOW INDEX FROM order;查看索引信息确认主键、唯一键和辅助索引都正确创建。还有一个容易忽略的操作确认当前库中所有表的状态。用SHOW TABLE STATUS LIKE order\G查看建表时间、行数估算、存储引擎、字符集等信息。在做表结构变更前我都会先看一眼这个确认表当前的状态符合预期。6.2 插入几条测试数据看效果建表SQL写得再漂亮也要用真实数据验证一遍。我会立刻插入几条测试数据覆盖正常值和边界值INSERT INTO order ( order_no, user_id, total_amount, receiver_name, receiver_phone, receiver_address, remark ) VALUES ( ORD20240101001, 1001, 199.50, 张三, 13800138000, 某市某区某街道1号, 请尽快发货 );这里故意不给id、pay_status、created_at赋值目的就是验证自增主键是否生效、默认值是否正确填充。然后执行SELECT * FROM order WHERE order_no ORD20240101001;如果查出来的记录里id自动生成了pay_status是0created_at是当前时间说明表结构里的设计都生效了。我还会顺手插入一条缺少必填字段的数据比如不写user_id看MySQL是否按预期报错。这个过程能帮你在第一时间发现约束条件是不是漏了。6.3 表建错了怎么办ALTER TABLE的常用操作现实中很少有表能一次设计得百分百到位业务一变就得加字段、改类型、加索引。建表之后最常用的维护操作集中在ALTER TABLE上。给表增加一个新字段ALTER TABLE order ADD COLUMN coupon_amount DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 优惠券抵扣金额 AFTER total_amount;修改一个字段的类型或约束ALTER TABLE order MODIFY COLUMN remark VARCHAR(1000) NOT NULL DEFAULT COMMENT 用户备注;修改字段名同时可以改类型ALTER TABLE order CHANGE COLUMN receiver_phone receiver_mobile VARCHAR(20) NOT NULL DEFAULT COMMENT 收货人手机号;给表增加索引ALTER TABLE order ADD INDEX idx_user_id_status (user_id, pay_status);删除某个字段或索引ALTER TABLE order DROP COLUMN remark; ALTER TABLE order DROP INDEX idx_user_id_status;这里需要特别提醒在数据量很大的表上执行ALTER TABLE尤其是MODIFY COLUMN、CHANGE COLUMN这类操作可能会锁表并导致长时间阻塞。大表变更要选在业务低峰期或者借助在线DDL工具进行平滑操作。年轻的时候我直接在生产订单表上加字段导致写入排队整整几分钟运营那边马上就炸了。自那以后凡是线上表的DDL操作我都要先确认数据量、预估执行时间和影响面再动手。7. 实际操作中的几个坏习惯与纠正方法写到这里建表的基本操作差不多都覆盖了。最后想聊几个我在实际工作中反复见到、自己也踩过的坏习惯。这些不是语法层面的问题而是“经验层面”的坑。如果能把它们提前纠正过来你写的建表语句会迅速老练很多。7.1 滥用自增主键自增主键简单好用但不是万能的。当一张表的自增主键值被业务逻辑引用比如通过URL直接暴露/order/12345对方可以轻松估算你的订单量进而拖数据。这种场景下建议改用不连续的业务主键。另外如果以后要做分库分表单一自增主键跨库会冲突需要在应用层生成全局唯一ID。主键选型这事建议在建表时就想到未来两三年。7.2 不写字符集后面乱码才追悔莫及这是一个被讲烂了但还是不断有人犯的错。建表时不指定CHARSET表就会继承数据库级别的默认字符集。如果数据库默认是latin1你存中文就会变成一堆问号或乱码。最稳妥的做法是建表语句里显式写DEFAULT CHARSETutf8mb4。用utf8mb4而不是utf8是因为utf8在MySQL里最多存3字节像emoji这样的4字节字符存不进去而utf8mb4完全兼容并扩展了它是目前最通用的选择。7.3 建表语句不备份的教训修改表结构之后如果原有的建表语句没有保存下来后面想做环境重建就只能用SHOW CREATE TABLE一条一条地捞。我现在的习惯是所有建表SQL都放进项目仓库的迁移脚本目录里和代码一起走版本管理。每次表结构变更新增一个带时间戳的SQL文件既能追溯变更历史出了问题也能快速回滚。因为没有备份建表语句而后悔的经历相信踩过坑的人都不想让别人再踩。还有一个隐藏多年的习惯分享一下建表SQL写完不要直接在生产库执行先在本地或测试库跑一遍确认执行结果和预期一致再走变更流程。我以前为了图快跳过了这一步结果一个字段长度写小了上线半天就被数据打爆。从那以后我建表必先在测试环境完整走一遍流程。最后的体会创建表是MySQL里最“入门”的操作但也是最能体现基本功的操作。这么多年的经验总结下来无非是几个朴素的道理建表前想清楚业务需求建表时把字段类型、约束、索引、字符集一次设计到位建表后用SHOW CREATE TABLE和测试数据验证一遍以后每次改动都走可回滚的脚本流程。如果你每次建表都按照这个节奏来不需要太久你写出来的建表语句就会有明显的“老手味道”。有一句常年在数据库圈子里流传的话我一直觉得很在理——“建表如建房地基打不好装修再好也白搭。”希望这篇内容能帮你把MySQL建表这块地基真正打得扎实一点。
