高并发主键设计选择
索引：
-
聚簇索引
- 数据和索引存储在一起的。 key和value一起存在一起。
- 数据存储在主键索引中。
- 数据按主键顺序存储。
- 如何选择主键：自增主键 和 随机主键 UUID。对数据和存储的影响来看。 自增主键：写入性能高。
- 自增主键优点：数据插入顺序为索引数据。写入性能高。
- 随机主键缺点：插入不连续的主键导致page节点分裂。数据移动。写入性能相较于较低。
-
二级索引
- 除聚簇索引外的叫二级索引。/ 除主键索引以外的。
- 叶子中存储的的是主键值。 通过二级索引找到主键。通过主键回表到聚簇索引找到value。
- 一次查询需要走两遍索引。（性能衰减）
- 主键大小会影响所有索引文件的大小。（逻辑上影响查询效率）
-
联合索引
- 多个key组成的索引。
- 最左匹配原则。 （1.如果不是按照最左开始查询，无法使用索引。 2.不能跳过中间列。 3.列表使用范围查询，后面的列不能使用索引。）
- 一个索引只能创建一棵树。
- 第一列排序，第一列相同按第二列排序。
-
索引使用优化分析
- 存储空间
- 索引文件大小
- 字段大小->页面节点个数->树的层数
- 主键选择
- 自增主键，顺序写入，效率高。（为了不暴露信息不能用于主键查询，所以每次查询走二级索引。效率较慢）
- 随机主键，结点分裂、数据移动。写入磁盘利用率低，每次查询走二级查询；
- 业务主键：保证递增且不连续的情况下。写入、查询磁盘利用率都高，可以使用唯一索引。雪花算法（毫秒时间戳+分布式机器ID+计数器）
- 联合主键：影响索引大小，不易维护，不建议使用。
- 联合索引使用
- 按索引区分度排序。
- 覆盖索引。 不回表，直接取到数据。 数据和索引存放一起。
- 索引下推。
- 字符串索引
- 设置合理长度。
- 不支持%开头模糊查询。
经验：
- 联合索引：覆盖索引由于多列独立索引
- 索引顺序：选择性高的在前面
- 覆盖索引：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来进行分表可以让同一个用户的商品分到一个表中
- 系统消息库的拆分
- 时效性强。
- 冷热数据拆分。 按月份分
- 如果少分了库表怎么办？
合理利用主从同步，然后修改业务路由，分片算法，清理旧数据。
