企业千亿级海量数据并发分库分表设计方法论学习笔记

高并发主键设计选择

索引：

1. 聚簇索引

   1. 数据和索引存储在一起的。 key和value一起存在一起。
   2. 数据存储在主键索引中。
   3. 数据按主键顺序存储。
   4. 如何选择主键：自增主键 和 随机主键 UUID。对数据和存储的影响来看。 自增主键：写入性能高。
   5. 自增主键优点：数据插入顺序为索引数据。写入性能高。
   6. 随机主键缺点：插入不连续的主键导致page节点分裂。数据移动。写入性能相较于较低。

2. 二级索引

   1. 除聚簇索引外的叫二级索引。/ 除主键索引以外的。
   2. 叶子中存储的的是主键值。 通过二级索引找到主键。通过主键回表到聚簇索引找到value。
   3. 一次查询需要走两遍索引。（性能衰减）
   4. 主键大小会影响所有索引文件的大小。（逻辑上影响查询效率）

3. 联合索引

   1. 多个key组成的索引。
   2. 最左匹配原则。 （1.如果不是按照最左开始查询，无法使用索引。 2.不能跳过中间列。 3.列表使用范围查询，后面的列不能使用索引。）
   3. 一个索引只能创建一棵树。
   4. 第一列排序，第一列相同按第二列排序。

4. 索引使用优化分析

   1. 存储空间
      1. 索引文件大小
      2. 字段大小->页面节点个数->树的层数
   2. 主键选择
      1. 自增主键，顺序写入，效率高。（为了不暴露信息不能用于主键查询，所以每次查询走二级索引。效率较慢）
      2. 随机主键，结点分裂、数据移动。写入磁盘利用率低，每次查询走二级查询；
      3. 业务主键：保证递增且不连续的情况下。写入、查询磁盘利用率都高，可以使用唯一索引。雪花算法（毫秒时间戳+分布式机器ID+计数器）
      4. 联合主键：影响索引大小，不易维护，不建议使用。
   3. 联合索引使用
      1. 按索引区分度排序。
      2. 覆盖索引。 不回表，直接取到数据。 数据和索引存放一起。
      3. 索引下推。
   4. 字符串索引
      1. 设置合理长度。
      2. 不支持%开头模糊查询。
         经验：
   • 联合索引：覆盖索引由于多列独立索引
   • 索引顺序：选择性高的在前面
   • 覆盖索引：key里面包含要查询的数据
   • 索引排序：索引同时满足查询和排序
   • 数据库字符集使用utf8mb4；
   • varchar：按照实际需要分配长度
   • 文本字段建议使用varchar
   • 时间字段建议使用long （时间戳）
   • bool字段建议使用tinyint
   • 枚举字段建议使用tinyint
   • 交易金额建议使用long 小数点前移乘以单位
   • 禁止使用“%”前导的查询
   • 禁止在索引列进行数据运算，会导致索引失效
   • 表必须有主键建议使用业务主键
   • 单表中索引数量不超过5个
   • 单个索引字段数不超过5个
   • 字符串索引使用前缀索引，前缀长度不超过10个字符
   • 是否分表
     • 看一单表不超过1kw
   • 分表方式
     • 取模：存储均匀&访问均匀
     • 按时间：冷热库
   • 分库
     • 按业务垂直分
     • 水平拆分多个库

分库分表

• 垂直拆分
  • 微服务拆分。（业务模块拆，分开库）
  • 垂直拆表。 将经常写入的列和经常查询的列拆开来。
• 水平拆分
  • 取模 读写均匀
  • 时间戳 按时间
  • 冷热库 按时间

高并发场景分库实践落地方案

• 用户库的拆分：选查询条件最高的那个。
  • uid（pk），phone（index）1.对uid取模。2.对phone做索引map，回表查uid。
• 商品库的拆分
  • pid（pk），uid（index）1.对商品pid做取模分表。但是要根据uid查到发布的商品，需要做分组。解决方案：给用户表生成一个字段
  • uid 【TS + pubilc + NO + count】
  • PID 【TS + NO + count + public】
  • 使用public来进行分表可以让同一个用户的商品分到一个表中
• 系统消息库的拆分
  • 时效性强。
  • 冷热数据拆分。 按月份分

1. 如果少分了库表怎么办？
   合理利用主从同步，然后修改业务路由，分片算法，清理旧数据。