最近整理一篇MySQL 8建表的实操笔记起因是接手一个后端服务发现库里不少表是早期随手建的订单金额用FLOAT用户状态用VARCHAR存中文还有几张大表连主键都没有。排查问题时我把MySQL 8的CREATE TABLE完整过了一遍从表名、临时表、表克隆和复制、列数据类型到列属性发现这个版本相比5.7变化确实不少。比如默认字符集改成了utf8mb4CHECK约束从8.0.16开始真正强制执行自增ID持久化不再随重启回退DATETIME也支持了表达式默认值。这篇文章面向正在用MySQL 8做开发的同学也适合DBA把建表规范落进评审清单内容偏实战看完可以直接照着写表结构。1. 建表前的三个决定表名、引擎和字符集很多人建表上来就写CREATE TABLE其实表名、引擎、字符集这三个决定应该在写第一行SQL之前就想清楚因为它们一旦上线就不好改后面每次迁移、扩容都会牵扯到。1.1 表名不是随便取的大小写敏感是个隐形雷表名最长64个字符这个限制一般用不到真正容易踩坑的是大小写敏感问题。MySQL在Linux下默认区分大小写在Windows和macOS下默认不区分这就导致一个很经典的现场开发在本地建了一张UserAccount表代码里写user_account本地跑得好好的部署到Linux服务器就报“table doesnt exist”。我见过不止一个项目因为这个在凌晨上线时回滚。解决办法很简单团队里约定统一小写加下划线user_account这种风格并且把这条写进代码规范。另一个需要注意的点是避免保留字比如order、group、desc这些词建表时不会报错但写SQL时到处要加反引号麻烦且容易漏。如果真的碰上了要么改名要么用反引号包起来但从维护角度我强烈建议改名。表名最好带业务前缀比如订单域用ord_开头用户域用user_开头商品域用goods_开头。这样在库表数量超过几百张时按前缀就能快速定位权限管理也能按域区分否则光靠记忆找表非常痛苦。1.2 存储引擎业务表认准InnoDB临时表可以例外MySQL 8的默认存储引擎是InnoDB这意味着不写ENGINE关键字时就是InnoDB。InnoDB提供事务、行级锁、外键、崩溃恢复这些能力绝大多数业务表都该用它。有些老项目还在用MyISAM理由是查询快、占用小但MyISAM不支持事务崩溃后恢复也麻烦并发写入时表级锁会卡住整个表。MySQL 8里虽然还能用MyISAM但官方已经在边缘化了新业务表没必要给自己埋这个坑。不过临时表是个例外临时表经常用MEMORY引擎把数据放在内存里存取速度极快适合存中间计算结果。但MEMORY表有两个限制要注意一是表大小受max_heap_table_size限制默认16MB数据量大了会报“The table is full”二是VARCHAR和BLOB这些可变长度字段在内存里会按定长存储比较浪费空间。数据量超过阈值时临时表还是回到InnoDB更稳妥。1.3 字符集MySQL 8默认utf8mb4但建表时最好显式声明MySQL 8把默认字符集从latin1改成了utf8mb4默认排序规则是utf8mb4_0900_ai_ci。utf8mb4是utf8的超集支持emoji和生僻字后端存用户昵称、评论内容都不怕乱码。实际建表时我建议还是显式声明一遍CREATE TABLE user_account ( ... ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_0900_ai_ci;这么写不是为了显得专业而是防止实例级参数不一致。你本地是utf8mb4测试环境可能被人改成了gbk如果建表语句没写建出来的表就随环境走了。显式写清楚之后无论在哪执行表结构都一样迁移时少很多麻烦。另外要注意utf8mb4比utf8多一个“_0900_ai_ci”的排序规则选择ai表示口音不敏感ci表示大小写不敏感这是默认的。如果业务需要区分大小写可以改成utf8mb4_bin但要在列级别指定后面细讲。2. 临时表会话内的隔离工作台临时表我单独拿出来讲是因为很多开发同学虽然知道语法但没搞懂它的生命周期用起来出了不少问题。临时表在MySQL里是一个很实用的工具尤其适合处理复杂查询的中间结果。2.1 临时表是什么它和普通表有什么本质区别临时表用TEMPORARY关键字创建它只在当前会话内可见当前会话断开连接后临时表会自动删除。这个特性意味着同一时间线上可能有几十个会话各自创建同名临时表互不干扰。它和普通表的本质区别在于生命周期和作用域。普通表是持久化对象删除前一直存在所有连接都能看到临时表是会话私有的其他连接连名字都看不到也没法访问。这个特性特别适合做批处理你从几张表里汇总出中间数据存入临时表再继续做复杂计算算完会话结束一切自动清理不用操心删表。但要小心同名遮蔽问题。如果你在当前会话里创建了一张和普通表同名的临时表那么在这个会话内所有SQL操作都会优先访问临时表普通表被“遮蔽”了。正常情况你感觉不到一旦忘了删除临时表就会遇到“改了数据却不生效”的诡异问题。排查方法是用SHOW CREATE TABLE查看如果看到的建表语句里带TEMPORARY关键字说明当前有临时表。2.2 临时表的创建语法和内存引擎使用创建临时表和普通表几乎一样只是多了TEMPORARY关键字CREATE TEMPORARY TABLE tmp_user_order_summary ( user_id BIGINT NOT NULL, total_amount DECIMAL(10, 2) NOT NULL DEFAULT 0.00, order_count INT NOT NULL DEFAULT 0, PRIMARY KEY (user_id) ) ENGINEMEMORY;这个表把每个用户的订单汇总结果放在内存里后续查询直接读它不需要反复JOIN原始大表。ENGINEMEMORY是临时表常用的优化手段但要注意前文说的max_heap_table_size限制如果预估数据量超过阈值就别用MEMORY了让临时表落到磁盘用默认的InnoDB引擎。临时表还支持用LIKE克隆结构CREATE TEMPORARY TABLE tmp_user_ref LIKE user_account;这个语句只会复制表结构不会带数据如果你需要用到user_account的结构但不想动原表数据可以用它快速建一张空壳。实际使用中还有一个连接池的坑。应用连数据库通常走连接池连接是复用的理论上会话结束后临时表该删但如果你在代码里没有显式删除临时表连接归还到池子时临时表可能还在下次同一个连接执行相同逻辑时CREATE TEMPORARY TABLE就会报“Table already exists”。建议在每次创建前先执行DROP TEMPORARY TABLE IF EXISTS清理一遍养成习惯。3. LIKE和AS SELECT表克隆与复制的两把刀表克隆和复制是日常运维和开发的高频需求比如给大表建备份表、把生产表复制到测试库、按条件抽取数据生成报表表。MySQL 8提供了两种核心方式CREATE TABLE ... LIKE和CREATE TABLE ... AS SELECT两者差异很大选错了会意外丢索引或者丢数据。3.1 CREATE TABLE ... LIKE结构完整但数据不带CREATE TABLE user_account_bak LIKE user_account;这条语句会把源表的列定义、索引、生成列、CHECK约束都复制过来相当于做了一份完整结构拷贝。它有几个重要特性不复制数据所以执行完是一张空表。不复制外键约束虽然列和索引都在但外键关系需要手动添加。自增列不保留当前自增值从1重新开始。LIKE在MySQL 8里还支持括号写法CREATE TABLE user_account_bak (LIKE user_account)效果一样看个人习惯。如果你只需要一张和源表结构一样、但数据清空的表用LIKE最合适。我经常用它做两件事一是给大表做归档先LIKE建一张空表再按条件把历史数据搬进去二是做表结构变更演练先在备份表上试一试ALTER TABLE确认没问题再操作线上表。3.2 CREATE TABLE ... AS SELECT数据直接复制但结构不一定是你想要的CREATE TABLE user_account_copy AS SELECT * FROM user_account WHERE status 1;CTAS会把查询结果直接落成一张新表数据一步到位看着很方便。但它有几个隐藏的坑不注意就会踩新表不会继承索引、主键、外键哪怕源表有完好的索引新表也是一张没有任何索引的“裸表”数据量大时查询会全表扫描。类型会被推断不一定是你期望的类型。比如SELECT一个VARCHAR(20)的字符串新表可能推断成VARCHAR(255)白白浪费存储如果SELECT的是表达式比如SUM(amount)新表的列名会变成表达式文本使用时非常别扭。默认值不会保留源表的DEFAULT CURRENT_TIMESTAMP这些属性CTAS后都丢了。解决类型问题的办法是显式指定列类型CREATE TABLE tmp_salary_stat AS SELECT user_id, CAST(SUM(amount) AS DECIMAL(12,2)) AS total_salary FROM salary_log GROUP BY user_id;解决索引问题的办法是建表后手动补索引。但最推荐的完整复制方案其实是下面这个组合。3.3 完整复制一张表的推荐组合要真正复制一张表包括结构、数据、索引、外键一步到位的方法不存在至少不能靠单条CREATE TABLE实现。我推荐的组合是两步走CREATE TABLE user_account_dev LIKE user_account; INSERT INTO user_account_dev SELECT * FROM user_account; -- 如需外键执行后手动ALTER TABLE添加第一步用LIKE拿到完整结构第二步用INSERT SELECT把数据灌进去两步执行完基本就是一张和源表一致的复制表。如果数据量很大INSERT SELECT可以分批执行比如按id范围分多次插入避免一次锁住源表太长时间。三张表复制方式对比方式复制结构复制数据复制索引复制自增值复制外键CREATE TABLE ... LIKE是否是否否CREATE TABLE ... AS SELECT部分推断是否否否LIKE INSERT SELECT是是是否否从表格可以看出没有一种方式能完美复制外键所以凡是涉及表复制的操作最后都要检查外键约束这是最容易被忽略的一步。4. 列数据类型选型从整数到日期时间的实用对照列数据类型选型是整个建表过程里最考验经验的环节。选错类型不像语法错误那样立刻爆出来而是会在数据量大了之后慢慢出问题查询变慢、存储膨胀、精度丢失、排序异常。这一节我把常用的数据类型过一遍按数值、字符串、日期时间三个维度讲清楚选型逻辑。4.1 数值类型整数、小数和金额到底该怎么选整数类型按存储字节数和取值范围区分类型字节数有符号范围常见用途TINYINT1-128 ~ 127状态码、开关SMALLINT2-32768 ~ 32767中范围数量MEDIUMINT3-8388608 ~ 8388607中范围IDINT4-2147483648 ~ 2147483647常规ID、计数BIGINT8-9223372036854775808 ~ 9223372036854775807大表主键、时间戳主键建议用BIGINT UNSIGNED尤其是有分库分表预期的场景单表数据量过亿很常见INT到21亿就接近上限了到时再改造主键类型代价极大。状态码、性别、是否删除这些字段用TINYINT就够一个字节省不了多少空间但语义清晰。小数类型必须重点说。金额、汇率、重量这些对精度敏感的数据一律用DECIMAL不要用FLOAT或DOUBLE。FLOAT和DOUBLE是浮点数存在精度误差比如0.1在二进制里无法精确表示累加之后误差会越来越大。订单金额用FLOAT存初期看不出问题月底对账时差个几块钱就有的折腾了。DECIMAL(10,2)表示最多10位数字、小数部分2位整数部分最多8位也就是最大99999999.99这个精度对绝大多数业务的金额字段都够用。DECIMAL本质是字符串存储计算时由MySQL做定点运算不会丢精度代价是比浮点数慢一点点但为了数据准确完全值得。还有一个细节MySQL 8.0.17以后废弃了整数显示宽度也就是以前写的INT(11)、TINYINT(4)这种写法不再有实际作用虽然不报错但纯属多余。直接写INT、TINYINT就好别给自己加戏。4.2 字符串类型CHAR和VARCHAR的取舍以及TEXT的定位字符串类型最常用的是CHAR和VARCHAR两者区别在于存储方式CHAR(N)是定长声明多长就占用多长不足部分用空格填充VARCHAR(N)是变长实际存多长就占用多长另外加1到2字节记录长度。CHAR适合存长度基本固定的数据比如MD5、手机号、状态码定长存储避免了碎片访问速度也稳定。VARCHAR适合存长度变化大的数据比如用户名、邮箱、地址变长存储能显著节省空间。注意VARCHAR声明的是字符数不是字节数。在utf8mb4字符集下一个汉字占4字节VARCHAR(255)最多能存255个汉字占用最大1020字节。InnoDB的索引键最大是3072字节所以VARCHAR(255)做索引没问题但如果声明VARCHAR(768)再建索引就超了。长文本字段如果需要索引要么改成前缀索引要么考虑用生成列。CHAR和VARCHAR还有一个差异CHAR在存储时会去掉尾部空格VARCHAR会保留。这意味着如果你往CHAR(10)里存“abc”取出后是“abc”尾部空格被清了但如果业务数据本身依赖尾部空格就不要用CHAR。TEXT和BLOB要慎用。TEXT是变长文本类型最大64KB适合存文章、评论这类长内容。但它有几个限制不能直接建普通索引只能前缀索引、排序和GROUP BY时会有临时表落盘的风险、刚插入时性能正常但更新时因为行变长会产生碎片。能用VARCHAR解决的业务尽量用VARCHARTEXT留给自己真实的长文本场景。4.3 日期时间类型DATETIME和TIMESTAMP选错会出大问题MySQL 8提供了DATE、DATETIME、TIMESTAMP三种常用日期类型。DATE只存年月日DATETIME存年月日时分秒范围从1000年到9999年TIMESTAMP也是年月日时分秒但范围只有1970年到2038年。这个差异非常关键。TIMESTAMP的范围上限是2038年1月19日很多老系统在2038年临近时会开始出现时间溢出。如果你开发的是长期维护的业务系统比如金融、政务、保险日期字段一律用DATETIME不要用TIMESTAMP。TIMESTAMP还有一个特性它会跟随数据库时区自动转换。存入时从会话时区转成UTC取出时再转回会话时区。如果应用服务器和数据库服务器时区不一致或者迁移云主机时没注意时区时间数据就会出现偏差。DATETIME则不做任何转换存入什么就是什么不受时区影响这也是我推荐DATETIME的原因。设置默认值时MySQL 8推荐写法created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMPcreated_at在插入时自动取当前时间updated_at在更新时自动刷新。这个组合几乎是建表标配大部分业务表都该有这两个字段。MySQL 8.0.13开始DATETIME还支持用括号表达式做默认值比如DEFAULT (DATE_ADD(NOW(), INTERVAL 1 DAY))灵活性更高但日常用得不多。5. 列属性默认值、约束和自增的细节坑列属性决定了一列的约束行为包括是否允许为空、默认值是什么、是否自动递增、是否有CHECK约束。这些属性和数据类型配合起来构成了完整的表规则。很多建表问题不是语法错误而是属性设置不合理导致应用层要额外写很多判断代码。5.1 主键和AUTO_INCREMENT自增列在MySQL 8里的行为变化InnoDB是索引组织表数据按主键顺序组织存放。有显式主键时表结构清晰没有主键时InnoDB会挑第一个非空唯一索引作为主键实在没有就生成一个6字节的隐藏主键。隐藏主键对用户不可见但会占用额外空间而且没有任何业务意义。我见过一张没有主键的日志表数据量几千万偶尔做DELETE和UPDATE性能极差因为没有稳定主键条件扫描效率很低。强烈建议每张表都显式定义主键。自增列用AUTO_INCREMENT关键字有几个硬性规则一个表只能有一个自增列自增列必须是索引自增列必须是数值类型。常见写法id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT 主键ID, PRIMARY KEY (id)MySQL 8对自增的一个重大改进是自增值持久化。在MySQL 5.7及以前自增计数保存在内存里重启后会根据当前最大ID重新计算如果删过最大ID的数据重启后自增可能从被删的ID继续造成主键复用。MySQL 8把自增值写入了重做日志重启后不会回退这个坑算是彻底解决了。事务回滚时自增ID不会回退所以自增ID跳号是正常现象。不要试图让ID完全连续那是和数据库设计原理较劲。5.2 NOT NULL和DEFAULT能非空就非空默认值要合理建议建表时把能NOT NULL的字段都写成NOT NULL并给一个合理的默认值。原因有三一是不允许NULL可以提高查询效率索引里排除NULL的判断更简单二是避免应用层到处判空三是不为NULL的语义更明确字段要么有值要么有默认值不会有模棱两可的状态。比如用户昵称如果允许NULL代码里就要判断nickname ! null否则报空指针。但如果你设置DEFAULT 取出来就是个空字符串展示逻辑可以统一处理。默认值本身也有语法细节。MySQL 8.0.13以后默认值支持表达式除了CURRENT_TIMESTAMP这类关键字还能用括号表达式比如DEFAULT (UUID())或者DEFAULT (DATE_ADD(NOW(), INTERVAL 1 DAY))。注意表达式要加括号不加括号的写法会报语法错误。这里要专门提醒MySQL 8的默认sql_mode包含STRICT_TRANS_TABLES也就是严格模式。在严格模式下插入非法日期、超长字符串、不符合默认值要求的数据都会直接报错而不是像5.7以前那样只发警告然后截断。很多老项目迁移到MySQL 8后突然插入失败就是这个原因。排查时先查一下sql_mode再检查应用程序插入的数据是否规范。5.3 CHECK约束8.0.16之后才真正执行生成列也很实用很多从MySQL 5.6时代过来的开发都有个印象CHECK约束写了也白写因为MySQL解析后直接忽略。这个情况在MySQL 8.0.16之后彻底变了CHECK约束开始强制执行。CREATE TABLE user_profile ( user_id BIGINT NOT NULL, age TINYINT UNSIGNED NOT NULL, email VARCHAR(100), CONSTRAINT chk_age CHECK (age BETWEEN 0 AND 150), CONSTRAINT chk_email_format CHECK (email IS NULL OR email LIKE %%) );这样的约束写在表结构里应用层即使漏了校验数据库也会兜底拦截非法数据。不过要注意CHECK约束的表达式要求是确定性函数不能用NOW()这种随执行时间变化的函数也不能用存储过程或自定义函数。生成列是另一个实用属性它不需要应用层计算由MySQL根据其他列自动生成price DECIMAL(10,2) NOT NULL, quantity INT NOT NULL, total_amount DECIMAL(10,2) GENERATED ALWAYS AS (price * quantity) STORED生成列分VIRTUAL和STORED两种。VIRTUAL不占实际存储每次查询时现算适合计算量大但不频繁访问的字段STORED会真实落盘适合经常用来查询过滤的字段比如订单总价、优惠后价格之类。如果这个生成列还要建索引那就选STORED因为虚拟列建索引需要MySQL支持二级索引虽然8.0支持但性能上还是STORED更直观。5.4 列级字符集与排序规则混合字符集是乱码和慢查询的根源列级别可以单独指定字符集列没指定时继承表的默认字符集表没指定时继承实例默认字符集。这个继承链平时没问题但一旦某列被显式指定成不同字符集就会埋雷。比如一张表默认utf8mb4有个历史遗留列是latin1数据本身是英文和数字看着没问题。但如果你把这一列和其他utf8mb4列做JOIN或字符串比较MySQL会对其中一个做字符集转换转换不仅带来性能开销还可能因为编码差异导致匹配不上或者在大数据量下索引失效。所以建表时尽量统一字符集整个库、所有表、所有列都使用utf8mb4不给自己留例外。如果真有兼容老数据的场景在查询时显式用CONVERT函数转换而不是在表结构里混合字符集。排序规则决定字符串比较怎么排。utf8mb4_0900_ai_ci是默认的大小写不敏感、口音不敏感日常业务足够。如果业务需要精确区分大小写比如存储验证码、序列号可以指定utf8mb4_bin它会按二进制精确比较速度也更快。如果只是部分字段需要区分大小写就在列级别指定不影响全表。6. 建表现场排错我在生产环境踩过的5个坑建表SQL看着简单但真正上线时踩过的坑往往不在语法本身而在环境差异和数据行为。这一节整理几个我实际遇到过的问题当作避坑实录分享出来能帮助读者省不少排查时间。6.1 表名大小写导致“表不存在”问题现象应用日志报ERROR 1146 Table doesnt exist但用客户端工具看表明明在。排查发现本地开发和线上环境的lower_case_table_names参数不一致。这个参数在MySQL 8里默认是0即区分大小写但Windows和macOS上默认是1即不区分。如果你在本地建了一张UserAccount代码里查user_account本地环境正常部署到Linux后直接报表不存在。关键点lower_case_table_names在初始化实例后修改非常麻烦需要重启并且可能导致表名识别混乱。最省心的方案是统一规范建表全部小写下划线从根上规避这个问题。跨环境部署前也建议用SHOW VARIABLES LIKE lower_case_table_names检查一遍。6.2 临时表和普通表同名数据被默默改到临时表问题现象某应用晚上跑批跑完发现部分数据没记录。排查半天发现代码里创建了临时表tmp_user而线上刚好也有一张普通表叫tmp_user。在批处理会话里创建的临时表遮蔽了同名的普通表所有INSERT和UPDATE都写进了临时表会话结束临时表删除数据直接消失。这个坑的隐蔽性在于SHOW TABLES看不到临时表只有SHOW CREATE TABLE能看到TEMPORARY关键字。排查时如果怀疑当前连接有临时表执行SELECT CONNECTION_ID()确认会话再查information_schema.INNODB_TEMP_TABLE_INFO。日常规范里应该规定临时表命名带tmp_前缀并加上随机数后缀或者统一建在单独的临时库中避免和业务表混淆。6.3 CTAS复制表后索引和默认值全丢查询慢成爬问题现象给一张上亿的表做数据归档用CREATE TABLE archive_data AS SELECT * FROM source_table生成历史数据表结果查询历史数据时慢到无法接受。原因是CTAS复制出来的表没有任何索引主键也没了默认值也丢了相当于一张“裸表”。对比LIKE方式CTAS本质上更像“把查询结果导出成表”而不是“复制表结构”。如果业务需求是保留完整结构和索引一定要用LIKE加INSERT SELECT的组合。如果用CTAS是图省事那后续至少要把索引和主键手动补上。我自己的习惯是任何表复制操作执行完之后至少检查三个东西——主键、常用查询条件的索引、外键。一张表上线后没有主键等于给自己埋定时炸弹。6.4 时间列默认值报语法错误问题现象建表语句里写created_at DATETIME NOT NULL DEFAULT NOW()执行报语法错误。MySQL 8对默认值表达式的语法有要求CURRENT_TIMESTAMP可以直接写但其他函数写默认值时需要用括号比如DEFAULT (NOW())。更常见的写法是用DEFAULT CURRENT_TIMESTAMP这个从5.6开始就支持也是官方推荐。另一个容易踩的坑是DATETIME列没有加NOT NULL就直接配DEFAULT CURRENT_TIMESTAMP严格模式下行为会变得很微妙因为NULL值得默认值可能在插入时被覆盖也可能不生效不如直接写成NOT NULL DEFAULT CURRENT_TIMESTAMP语义干净。6.5 严格模式下插入失败问题现象老应用在MySQL 5.7上跑得好好的迁移到MySQL 8后某些INSERT语句开始报错错误信息明确指到某个字段超长或日期非法。原因很可能是MySQL 8的默认sql_mode包含了STRICT_TRANS_TABLES对数据做严格校验。5.7有些情况下只是warning8.0直接error。遇到这种问题先在数据库执行SELECT sql_mode看是否有STRICT_TRANS_TABLES。处理方式有三种修正应用程序插入的数据、调整字段长度、确认业务确实需要宽松行为后再调整会话级sql_mode。但我不建议为了兼容老代码全局关闭严格模式那会让脏数据悄悄混进来后面清洗成本更大。加上一个快速排查表方便日常对照现象可能原因处理建议CREATE TABLE报语法错误表名或列名用了保留字用反引号包住或改名插入数据出现乱码表、列字符集不一致统一utf8mb4自增ID跳号事务回滚、插入冲突正常现象不必处理CTAS生成的表查询很慢没有索引和主键改用LIKEINSERT SELECT或补索引时间默认值报错默认值表达式没加括号统一用CURRENT_TIMESTAMP最后聊一点我个人的体会。建表这件事看起来是所有SQL操作里最简单的但它决定了后面所有SQL的性能和稳定性。与其上线后不断ALTER TABLE打补丁不如在最开始就把引擎、字符集、数据类型、约束一次想清楚。我给自己定了一份建表检查清单表名统一小写下划线带业务前缀显式写InnoDB和utf8mb4一定有主键用BIGINT UNSIGNED自增能NOT NULL的字段都加默认值金额用DECIMAL时间用DATETIME业务规则能用CHECK表达就写进表结构。有了这份清单新表几乎不用返工。如果你最近也在折腾MySQL 8的建表希望能从这篇笔记里找到一些参考少踩几个我已经替你踩过的坑。
