商城数据库那些事儿，MySQL部分细节和实操经验分享

根据多位资深开发者在技术社区如CSDN、博客园、知乎上的经验分享帖，以及《高性能MySQL》等书籍中的实用章节，结合常见的电商项目实战总结而成。）

商城数据库这块儿,MySQL用得好不好，直接决定了网站是顺滑如丝还是卡成狗，我见过太多项目，一开始随便建表，等到用户量一上来，各种奇葩问题就全冒出来了，今天就不扯那些高大上的理论，直接说点干活时遇到的细节和踩过的坑。

最核心的就是表结构设计,商城最关键的几个表：用户表、商品表、订单表、订单明细表，这里面的门道可多了，比如用户表，密码字段千万别用明文存，这是常识，得用哈希加密，比如bcrypt，而且字段长度要留够，别varchar(32)就以为够了，万一以后要换更安全的算法呢？地址信息不要和用户主表放在一起，要单独拆一个地址表，一个用户可能有多个收货地址，这样拆开才灵活，不然每次查询用户信息都把一堆地址数据带出来，浪费资源。

商品表的设计,sku（库存量单位）的概念一定要理清楚，比如一件T恤，有S、M、L三个尺码，有红色、蓝色两个颜色，这其实就是2*3=6个不同的sku，你不能只在商品表里放一个“库存”字段，必须用单独的sku表来管理每个具体规格的库存、价格（可能促销价不一样）、图片，不然用户选不同规格时，库存和价格根本无法对应，这个坑我见过很多新手踩。

订单表是重灾区,订单状态字段的设计，不要用数字0,1,2,3，时间久了鬼才知道3代表什么，最好用有意义的字符串，pending_payment’（待支付）、‘paid’（已支付）、‘shipped’（已发货），虽然占点空间，但可读性不知道强了多少倍，查问题的时候你会回来感谢我的，订单号千万别用数据库自增的ID，因为容易被竞争对手猜到你的订单量，要用有规则的、不连续的号码，比如时间戳+随机数，或者用雪花算法生成。

说到订单,就不得不提金额字段，金额一定要用decimal类型，千万别用float或double！因为浮点数计算有精度损失，一分钱的误差在金融场景下都是灾难，比如decimal(10,2)表示总共10位数，小数点后2位。

表设计好了,索引就是加速器，但索引不是乱建的，原则是：尽量给经常用来查询、排序、分组的字段加索引，比如订单表的用户ID字段上一定要建索引，不然用户查自己订单历史的时候，数据库就得全表扫描，订单量大了直接崩溃，但是索引也不是越多越好，因为每次增删改数据，都要更新索引，会影响写入速度，像那些状态字段，比如订单状态，如果它的值只有寥寥几种（比如已支付、未支付），区分度不高，建索引效果不大，有时候数据库优化器甚至会选择不走索引。

联表查询是另一个性能杀手,比如要查“某个用户最近三个月买过的所有商品名称”，可能需要联用户表、订单表、订单明细表、商品表，这种查询一多，数据库就喘不过气来，一个很实用的优化方法是“反范式化”，就是在订单明细表里，不仅存商品ID，也直接把商品名称冗余存一份，这样查询的时候，就不用再去联商品表了，虽然会多占点存储空间，数据一致性维护稍微麻烦点（商品改名了要同步更新所有相关订单明细），但换来的查询性能提升是巨大的，这在电商这种读多写少的场景下非常划算。

当单表数据量达到百万甚至千万级,查询速度还是会慢下来，这时候就要考虑分区表了，比如订单表，可以按创建时间按月或者按年进行分区，查最近一个月的数据，MySQL就只需要在一个小的分区里找，而不是扫描整个上亿条记录的大表，速度飞快，但是分区表对查询条件有要求，where条件里最好带上分区键（比如时间），不然它还是会扫描所有分区。

最后说说慢查询日志,这个功能一定要开启，它会把执行时间超过你设定阈值（比如1秒）的SQL语句记录下来，定期去分析这个日志，找到那些拖慢数据库的元凶SQL，然后针对性地优化，比如看看能不能加个索引，或者改写一下SQL语句，这是提升数据库性能最直接有效的方法。

商城数据库没啥捷径,就是在这些细节上一点点抠出来的，设计的时候多想想以后的数据量和查询场景，别只图眼前省事，出了问题再补救，那成本可就高多了。

（注：以上经验融合了如《高性能MySQL》中关于数据类型、索引的强调，以及技术社区中关于电商表结构设计、慢查询优化的高频讨论点。）