大数据互联网架构阶段 大型电商项目数据库设计时应该注意的点

大型电商项目数据库设计时应该注意的点

一、 id的设计

1. int（int）类型： 性能高 ， 但是分布式数据库时 ， id易重复
2. long（bigint）类型：性能高 ， 比int类型容纳的数据更多 ， 但是还是会重复
3. String（varchar） ： 使用UUID ， 几乎不会重复 ， 但是性能略低
4. 大型电商的数据库是分布式的么？
   
   1. 究其原因 ， 数据库分布式设计就是为了提高数据库的性能 ， 能抗住更大的访问量 ， 但是仅仅靠增加数据库服务器台数 ， 来应对高并发， 似乎成本过高， 而且效果并不显著 ， 所以 ， 大型电商项目的数据库一般采用中央集中式 ， 后再引入缓存数据库 ， 此时大量重复的查询操作交给缓存数据库 ， 大大的减小了数据库的压力 ， 而且缓存存在于内存中 ， 用户获得数据的时间也更短 。

二、 价格的设计

1. 一般价格使用double表示 ， 但是double类型的数据对降低数据库的执行效率 ，而电商项目以性能最高为目的来设计整个架构 。 所以价格采用int存储
2. 在前台提交数据时 ， 先乘100 ， 的到一个整数 ， 进行存储 ， 在查询时 ， 前台在通过js将介个除以100 ， 得到真实的价格 。 这儿样就把数据库的压力分散到所有的客户机中 。

三 、 图片上传存储的设计

1. 在前台页面将图片进行上传 ， 然后将图片保存在服务器本地 。
2. 电商项目中以性能为核心， 肯定不能把图片存在数据库中（这样会破坏索引）
3. 把图片上传到服务器中后
   
   1. 判断是否是图片
   2. 判断是否是病毒
   3. 重新生成唯一的名字
   4. 生成实际存储路径（需要考虑 ， 同一文件夹下同名文件的问题 ， 同一文件夹下问价过多导致目录访问时间过长 ， 或不能访问的问题）
   5. 生成虚拟访问路径
   6. 创建实际路径对应的文件目录 ， 并存储
   7. 把虚拟访问路径存在数据库中
   8. 然后把虚拟访问路径返回客户端 ， 供图片回显使用 。
4. 索引介绍：
   
   1. 索引存在的目的就是为了减少磁盘IO的次数
   2. 如 ： 生活中查字典 ， 会用到字典索引：
      
      1. 查“李”
      2. 找L
      3. 找Li
      4. 找李
      5. 还有一些 笔画法， 偏旁法 ， ， 都惩治为索引 。
   3. B-Tree无论数据量多大， 三次IO即可查出数据
      
      1. 索引的特点是有序的
5. 所以 ， 像：图片 、 商品描述这样的大字段尽量不要存在数据库中 ， 破坏数据库索引之后 ， 查询将从索引查找变为遍历查找 ， 非常慢

四、 尽量使用单表设计

1. 在能使用单表设计的情况下尽量使用单表设计 ， 避免外键关联
2. 外键关联性能问题：
   
   1. 数据库需要内部维护外键关联（本身是if语句） ， 在主从不锁表的情况下我们在代码中维护他
   2. 在数据库中设计到增 、 删、 该 ，的操作都会触发相关的操作去检查外键 ， 从而不得不小号额外的资源 。
   3. 最主要的问题： 外键的存在很容易导致数据库的死锁 。

四、 商品描述的设计

1. 商品描述属于大字段 ， 而在数据库中大字段的存在会破坏表的索引 ， 导致查询操作十分的慢 ，所以要分表存储