MySQL 那些常见的错误设计规范,你都知道吗

依托于互联网的发达，我们可以随时随地利用一些等车或坐地铁的碎片时间学习以及了解资讯。同时发达的互联网也方便人们能够快速分享自己的知识，与相同爱好和需求的朋友们一起共同讨论。

但是过于方便的分享也让知识变得五花八门，很容易让人接收到错误的信息。这些错误最多的都是因为技术发展迅速，而且没有空闲时间去及时更新已经发布的内容所导致。为了避免给后面学习的人造成误解，我们今天来看一看 MySQL 设计规范中几个常见的错误例子。

主键的设计

错误的设计规范：主键建议使用自增 ID 值，不要使用 UUID，MD5，HASH，字符串作为主键

这个设计规范在很多文章中都能看到，自增主键的优点有占用空间小，有序，使用起来简单等优点。

下面先来看看自增主键的缺点：

• 自增值由于在服务器端产生，需要有一把自增的 AI 锁保护，若这时有大量的插入请求，就可能存在自增引起的性能瓶颈，所以存在并发性能问题；
• 自增值做主键，只能在当前实例中保证唯一，不能保证全局唯一，这就导致无法在分布式架构中使用；
• 公开数据值，容易引发安全问题，如果我们的商品 ID 是自增主键的话，用户可以通过修改 ID 值来获取商品，严重的情况下可以知道我们数据库中一共存了多少商品。
• MGR（MySQL Group Replication） 可能引起的性能问题；

因为自增值是在 MySQL 服务端产生的值，需要有一把自增的 AI 锁保护，若这时有大量的插入请求，就可能存在自增引起的性能瓶颈。比如在 MySQL 数据库中，参数 innodb_autoinc_lock_mode 用于控制自增锁持有的时间。虽然，我们可以调整参数 innodb_autoinc_lock_mode 获得自增的最大性能，但是由于其还存在其它问题。因此，在并发场景中，更推荐 UUID 做主键或业务自定义生成主键。

我们可以直接在 MySQ L使用 UUID() 函数来获取 UUID 的值。

MySQL> select UUID();
+--------------------------------------+
| UUID()                               |
+--------------------------------------+
| 23ebaa88-ce89-11eb-b431-0242ac110002 |
+--------------------------------------+
1 row in set (0.00 sec)