如何在SQL中创建表？CREATETABLE语句的完整指南

嘿，您发布的创建 SQL 表的指南非常全面，但它有点像教科书。
我们来谈谈一些实际的事情吧？
上周，有客户问我，为什么他写的建表语句在测试环境下无法通过。
原来是使用了MySQL的InnoDB引擎，却忘记添加DEFAULT CHARSET=utf8 mb4 ，导致插入时出现中文乱码。
你认为这是巧合吗？
查看 CREATETABLE 语法。
其实问题的关键就这么几个：定义表名、列名、类型和各种约束。
例如，您提供的示例是 UserIDINTPRIMARYKEYAUTO_INCRMENT。
这是很标准的，但是在实际使用的时候一定要小心。
在上海的一个电商项目中，我看到有人将用户ID设置为BIGINT。
导致后来分库分表的时候，服务器之间的自增ID同步就出现问题了。
因此，在选择此类产品时，需要目光长远。

您需要更加注意数据类型。
你提到的TINYINTUNSIGNED在保存年龄时节省了空间，但问题是如果公司突然需要保存订阅级别，1 个字节不够用，就会爆炸。
我在北京的一个金融项目中遭受了这个损失。
我一开始没有考虑清楚，最终不得不将项目分成一张大表。
因此，对于精度要求较高的DECIMAL(p,s)，最好提前与公司确认位数，以免后期添加和更改。

设计约束也很容易陷入麻烦。
例如FOREIGNKEY，如果你写FOREIGNKEY(CustomerID)REFERENCESCustomers(CustomerID)，看起来是正确的，但是如果你不添加ONDELETECASCADE或ONUPDATECASCADE并且客户删除了一个用户，那么与他关联的所有订单会发生什么情况呢？这个需要和业务方讨论清楚。
我有一个朋友去年在杭州做一个项目。
由于这个设置不正确，当客户端删除用户时，整个表被锁定，导致系统瘫痪。

指数策略是技术债务的一大来源。
您所说的 CREATEINDEXidx_emailONUsers(Email) 是正确的，但不要随意添加。
上次在广东做一个O2 O项目，实习生加了全表索引。
结果每次查订单都要扫描全表，查询时间从1 秒增加到1 分钟。
这个索引失败陷阱将受到真正的赞赏。
尤其是像InnoDB这样大量写入、大量读取的场景，索引的设计一定是非常讲究的。

存储引擎的选择也涉及到场景。
InnoDB确实很棒，支持事务和锁，但是在一些非常高频的读报告场景中MyISAM可能比InnoDB表现更好。
这取决于业务场景。
我在深圳的一个广告平台上看到的。
他们使用 MyISAM 创建用户画像报告。
他们可以在几秒钟内从数亿个数据点生成结果。
即使不能写出来，但用过的人都会知道。

最后的范式和反范式，我建议不要走极端。
第三范式很好，但是就像订单表一样，如果您冗余用户名和地址等公共字段，以避免每次都检查用户表，那么性能提升可能会比预期更大。
想一想。
我在上海的一个生鲜平台上推广了这种做法。
数据同步在初始阶段有点烦人，但查询很快就开始增长，客户满意度立即提高。

但是，创建表时要多考虑业务场景，不要只关注语法。
这些例子都是我曾经踩过的陷阱或者是我见过的真实的事情。
你可以用它们作为参考，它们绝对是正确的。
如果您有具体问题，请随时问我。

写出创建如下三张数据表的SQL语句。

SQL 创建一个表项目（ 商品编号 CHAR(1 0) 主键 );
创建表 SC ( 斯诺查尔(7 ), NOC 字符(4 ), INT级， 主键（Sno、Cno）、 外键参考文献 (Sno) 项目（项目编号）， 外键 (Cno) 参考文献 课程（课程编号） );
创建表课程( 课程编号 CHAR(4 ) PRIMARY KEY, 课程名称 VARCHAR(5 0) );
SC 表的外键约束必须与正确的表和字段相匹配。
假设该程序称为“课程”。

数据库怎么建表啊

创建表首先选择数据类型，INT或VARCHAR，然后设置主键和外键，最后添加索引。

这里有一个陷阱：不要忽略数据类型和索引。

不要相信：不要只使用一种数据类型。

不要这样做：不要忘记设置外键约束。