认查询请求远大于写入请求时，应设置便于查询项的冗余表。

实战范例，

用户分表，将用户库分成若干数据表

基于用户名的查询和基于uid的查询都是高并发请求。

用户分表基于uid分成数据表，同时基于用户名做对应冗余表。

冗余表要点

数据一致性，简单说，同增，同删，同更新。

可以做全冗余，或者只做主键关联的冗余，比如通过用户名查询uid，再

基于uid查询源表。

中间数据表

为了减少会涉及大规模影响结果集的表数据操作，比如count，sum操作。应

将一些统计类数据通过中间数据表保存。

中间数据表应能通过源数据表恢复。

实战范例：

论坛板块的发帖量，回帖量，每日新增数据等

网站每日新增用户数等。

后台可以通过源数据表更新该数字。

历史数据表

历史数据表对应于热点数据表，将需求较少又不能丢弃的数据存入，仅在少数

情况下被访问。

主从架构

基本认识

读写分离对负载的减轻远远不如分库分表来的直接。

写压力会传递给从表，只读从库一样有写压力，一样会产生读写锁！

一主多从结构下，主库是单点隐患，很难解决（如主库当机，从库可以响应读写，

但是无法自动担当主库的分发功能）

主从延迟也是重大问题。一旦有较大写入问题，如表结构更新，主从会产生巨大延

迟。

应用场景

在线热备

异地分布

写分布，读统一。

仍然困难重重，受限于网络环境问题巨多！

自动障碍转移

主崩溃，从自动接管

个人建议，负载均衡主要使用分库方案，主从主要用于热备和障碍转移。

潜在优化点

为了减少写压力，有些人建议主不建索引提升i/o性能，从建立索引满足查询要求。

个人认为这样维护较为麻烦。而且从本身会继承主的i/o压力，因此优化价值有限。该思路特此分享，不做推荐。