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

   

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

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

   

• 通过参数将时间高位放在最前，解决了 UUID 插入时乱序问题；   
  
• 去掉了无用的字符串"-"，精简存储空间；   
  
• 将字符串其转换为二进制值存储，空间最终从之前的 36 个字节缩短为了 16 字节。
  

MySQL> SELECT UUID_TO_BIN('23ebaa88-ce89-11eb-b431-0242ac110002',TRUE) as UUID_BIN;
+------------------------------------+
| UUID_BIN               |
+------------------------------------+
| 0x11EBCE8923EBAA88B4310242AC110002 |
+------------------------------------+
1 row in set (0.01 sec)

   

• decimal 是通过二进制实现的一种编码方式，计算效率不如 bigint   
  
• 使用 bigint 的话，字段是定长字段，存储高效，而 decimal 根据定义的宽度决定，在数据设计中，定长存储性能更好   
  
• 使用 bigint 存储分为单位的金额，也可以存储千兆级别的金额，完全够用
  

   

• 表达不清：这个表可能是其他同事设计的，你印象不是特别深的话，每次都需要去看字段注释，甚至有时候在编码的时候需要去数据库确认字段含义   
  
• 脏数据：虽然在应用层可以通过代码限制插入的数值，但是还是可以通过sql和可视化工具修改值
  

SELECT COUNT(*)
FROM user
WHERE id not in (
  SELECT user_id
  from blog
  where publish_time >= "2020-01-01" AND  publish_time <= "2020-12-31"
)

SELECT count(*)
FROM user LEFT JOIN blog
ON user.id = blog.user_id and blog.publish_time >= "2020-01-01" and blog.publish_time <= "2020-12-31"
where blog.user_id is NULL;

   

• UUID 也可以当主键，自增 UUID 比自增主键性能更好，多占用的空间也可忽略不计   
  
• 金融字段除了 decimal，也可以试试 bigint，存储分为单位的数据   
  
• 对于固定选项值的字段，MySQL8 以前推荐使用枚举字段，MySQL8 以后使用check函数约束，不要使用 0，1，2 表示   
  
• 一张表的索引个数并没有限制不能超过5个，可以根据业务情况添加和删除   
  
• MySQL8 对子查询有了优化，可以放心使用。