mysql和redis的关系？
- 要根据具体的业务情景去选型：
- mysql存储在磁盘中 redis存储在内存中
- redis适合存在一些比较热的数据，使用频繁的数据，比如下面的应用场景
- 排行榜
- 粉丝 关注
- 消息队列推送
数据库
- 降级处理
- 其作用是为了适应不同版本的sql，不同型号的硬件设备，做到向下兼容
- 通过日志文件分析 查看日志
- 如何进行分库分表（sharding）
- 数据库sharding，多表多数据适合做垂直切分；如果表不多，但是每张表的数据多适合做水平切分。
- 垂直切分：规则简单实施方便；根据不同的表来拆分，对程序的影响较小，拆分规则简单（share nothing）
- 水平拆分：将同一个表的不同数据拆分到不同的数据库中。
- 分布式矩阵（先垂直切分再水平切分）:这是企业应用比较多的策略。
- 切分策略：①垂直切分的思路是分析表间的聚合关系，把关系紧密的表放到一起。
- 切分策略之key：跨shard(数据切片)关联、社交网站基于用户切分、论坛基于用户和讨论切分，对于讨论模块来说，forum（讨论）是 聚合根因此按Forum进行水平切分，把Forum里所有的帖子和回帖放到一个shard里。
- 数据库引擎
- 数据库引擎是用来存储，处理和保护数据的核心服务。
- key：访问权限、开启事务、联机事务处理
- 索引的作用
- 索引是对数据库表中一列或多列的值进行排序的一种结构，使用索引可以快速访问数据库表中的特定信息。
- 分类：==聚簇索引==，按照数据存放的物理位置为顺序，能提高多行的检索速度；==非聚簇索引==，对单行的检索更快。
- 数据库索引好比是一本书的目录，通过索引能加快数据的查询速度。
- key：唯一索引、主键索引、聚集索引(数据库表中数据的物理顺序和与键值的逻辑（索引）数据相同)、索引列
- 掌握mysql数据库的多表查询，但是不建议使用数据库的多表查询，多表查询的逻辑放在程序逻辑中进行处理 参考
- 事务处理：分布式事务、通过应用程序与数据库功能管理事务
- 分布式事务：优点是交由数据库管理，简单有效；缺点是当数据库切片（shard）较多时性能代价高
- 由应用程序和数据库共同控制：性能优越，但是需要灵活的设计技巧，尤其当使用spring事务管理时，改动将面临问题；原理：将一个跨多个数据库的分布式事务，拆分成多个仅处于单个数据库上的小事务，并通过应用程序来总控各个小事务。
- mysql的基本操作：
- query cache 参考
- delete
- group
- limit
- where
- order
- count
- sum
- where
- explain
问题
- 降级处理 http://blog.csdn.net/dba_huangzj/article/details/7952403
- 数据库索引的设计 http://bbs.csdn.net/topics/390143448
小技巧
- 写逻辑判断的时候不用Boolean，用tinyint
- 表名称规范 常规的 _info 明细 _log
- 同一个逻辑处理可以采用分表，减少数据库的逻辑处理。用笔者写过的八字的项目举例，有一个总的贡献表，还需要有一个按周统计的实时贡献表,按周更新_week
- mysql中不建议直接写主外键关联关系，而是通过程序控制
名词
- shard：数据库切片
- sharding：分表分库
延伸（架构相关）
- 跨节点Join问题
- 只要是进行切片，跨节点的Join问题是不可避免的。
- 解决方法：分两次查询，在第一次查询的结果集中找到关联数据的id，根据这些id发起第二次请求得到关联数据。（类比一下bmob的管理查询，推测他们就是这么做的）
参考
- 数据库sharding
