您的位置:首页 > 数据库 > MySQL

3.3mysql数据库设计--课程笔记

2016-01-31 14:06 507 查看
基于性能的表设计

根据查询需要设计好索引

根据核心查询需求,适当调整表结构

基于一些特殊业务需求,调整实现方式

1. 索引

并发和数据量大的系统,更新尽可能使用主键或唯一索引

主键尽可能使用自增ID字段

2. 反范式,冗余必要字段

针对核心sql保留查询结果所必须的冗余字段,避免频繁join

3. 拆分大字段

拆分大字段到单独表中,避免范围扫描代价大

例:博文表拆分两份,标题表只保留标题和内容缩略部分,用于快速批量返回标题列表。正文表保存大段博文内容,用于点开文章单个读取。

 避免过多字段或过长行

1. 根据sql必须返回设计字段, 有必要就拆表,避免过多字段

2. 一次没有必要获取那么多列数据

3. 行过长导致表数据页记录变小,范围扫描性能降低

4. 更新数据页代价增加

5. 16k页最少放2行,可以出现行迁移

分页查询

 1. 避免limit + offset过大

 2. 应该使用自增主键ID模拟分页

1. 第一页,直接查

2. 得到第一页的max(id)=123(一般是最后一条记录)

3. 第二页,带上id>123查询where id>123 limit 100

 3.要求业务上禁止查询**页之后的数据

热度读数据特殊处理

根据数据获取的频率或数量不同对热点数据做特殊处理

 例:论坛系统中置顶贴,公告贴,可以单独拆分存储,由于每次访问都要全部读出来,单独放一起,避免每次都到普通表中随机找出来

热点写数据特殊处理

根据数据获取的频率或数量不同对热点数据做特殊处理

例:微博系统中对大量人关注的热点帐号消息从“堆”改为“拉”,避免过量insert操作

准实时统计

对不需要精确结果的计数等统计要求,建立定期更新结果表

例:首页要求展示动态成交总金额,维护一个计数表,每分钟根据原表注册时间获取增量sum值更新计数表,避免每次用户刷新都要扫描交易全记录表。



实时统计改进1--触发器实时统计

对需要精确统计的计数利用数据库触发器维护计数表

例:用户量冲亿活动要求实时统计,用户表上加触发器,每次有新用户插入就同时在计数表+1

实时统计改进2--缓存实时统计

对需要精确统计的计数利用前端缓存实时维护计数

例:用户量冲亿活动要求实施统计,注册数量在缓存中实时维护,每注册一个就+1, 完全避免数据库读写操作。缓存万一故障失效,可从数据库整体count重新获取

实时统计改进3--最大自增ID获取总数

很多逻辑可以利用自增ID主键最大值直接作为总数

可扩展性设计

可扩展性:硬件资源增长有极限的情况下处理尽可能久的线上业务

数据分级,冷数据归档与淘汰

为数据分布式做准备

1. 分区表和数据淘汰

1. range分区

2. 适合数据需要定期过期的大表

3. 单个分区扫描迁移数据到历史库避免全表扫描IO开销

4. 删除单个分区非常高效

2. 分区表和垂直分区

1. list分区

2. 适合将来可能要基于地区,类目等方式垂直拆分数据的方式

3. 清理节点上不要的数据非常高效

3. 分区表与水平分区

1. hash分区

2. 适合将来需要做水平拆分的表

3. 清理节点上不要的数据非常高效

mysql分区表的局限

主键或唯一键必须包含在分区字段内

分区字段必须是整数类型,或者加上返回整数的函数

满足周边需求

统计和后台需求

统计运行sql往往和线上有很大不同

利用mysql一主多从,主从可以建不同索引的特性将统计分流到特定从库

包括一些特殊用户批量查询等,所有对线上有IO压力的查询都要读写分离

自动更新时间戳

统计需求经常要求从线上读走增量数据

表的第一个timestamp类型字段在写入如果不填值,会自动写入系统时间戳

表的第一个timestamp类型字段每次记录发生更新后都会自动更新

在update_time字段上建索引用于定时导出增量数据
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: