1.mysql问题

IO问题：

磁盘读IO瓶颈：热点数据太多，数据库缓存放不下 -> 分库和垂直分表

网络IO瓶颈：请求数据太多，网络带宽不够 -> 分库

cpu问题：

SQL问题：SQL中包含join group by order by 非索引字段查询，增加cpu运算的操作->SQL优化

单表数据量太大，SQL效率低，cpu先出现瓶颈->水平分表

---

2.分库和分表操作

水平分库：

以字段为依据，按照一定策略(hash、range等)，将一个库中的数据拆分到多个库中。

  特点：每个库结构相同，数据不同，没有交集。

系统绝对并发量上来了，分表难以根本上解决问题，并且还没有明显的业务归属来垂直分库。

分析：库多了，io和cpu的压力自然可以成倍缓解。

水平分表：

以字段为依据，按照一定策略（hash、range），将一个表中的数据拆分到多个表中。

 特点：表结构相同，数据不同，没有交集。

系统绝对并发量并没有上来，只是单表的数据量太多，影响了SQL效率，加重了CPU负担，以至于成为瓶颈。

分析：表的数据量少了，单次SQL执行效率高，自然减轻了CPU的负担。

垂直分库：

以表为依据，按照业务归属不同，将不同的表拆分到不同的库中

每个库的结构不一样，数据不同，没有交集

分析：随着业务的发展孵化出了一套业务模式，这时可以将相关的表拆到单独的库中，甚至可以服务化。

垂直分表：

操作数据库中某张表，把这张表中一部分字段数据存到一张新表里面，再把这张表另一 部分字段数据存到另外一张表里面 。

以字段为依据，按照字段的活跃性，将表中字段拆分到不同的表(主表和扩展表)中。

表的结构不同，数据不同

分析：不能使用join，因为join不仅会增加CPU负担并且会讲两个表耦合在一起（必须在一个数据库实例上）。关联数据，应该在业务Service层，分别获取主表和扩展表数据然后用关联字段关联得到全部数据。

端上除了partition key只有一个非partition key作为条件查询

1. 端上除了partition key只有一个非partition key作为条件查询映射法
   基因法注：写入时，基因法生成user_id，如图。关于xbit基因，例如要分8张表，2 3=8，故x取3，即3bit基因。根据user_id查询时可直接取模路由到对应的分库或分表。根据user_name查询时，先通过user_name_code生成函数生成user_name_code再对其取模路由到对应的分库或分表。id生成常用 snowflake算法。
2. 端上除了partition key不止一个非partition key作为条件查询映射法
   冗余法注：按照order_id或buyer_id查询时路由到db_o_buyer库中，按照seller_id查询时路由到db_o_seller库中。感觉有点本末倒置！有其他好的办法吗？改变技术栈呢？
3. 后台除了partition key还有各种非partition key组合条件查询NoSQL法
   冗余法

扩容问题：

1. 水平扩容库（升级从库法）注：扩容是成倍的。
2. 水平扩容表（双写迁移法）
   第一步：（同步双写）应用配置双写，部署；第二步：（同步双写）将老库中的老数据复制到新库中；第三步：（同步双写）以老库为准校对新库中的老数据；第四步：（同步双写）应用去掉双写，部署；

注： 双写是通用方案。