数据库分库分表

什么情况下分库，什么情况下分表
请求数据库的网络io过大，带宽不够用；数据库磁盘io过大，降低读写性能 分库
单表数据量过大，优化sql，建立索引，查询依然很慢 分表
io瓶颈 分库
cpu瓶颈 分表

垂直切分？

是根据业务来拆分数据库，同一类业务的数据表拆分到一个独立的数据库，另一类的数据表拆分到其他数据库。
比如说一个新零售的电商数据库，我们可以把跟商品相关的数据表拆分成一个数据库，然后在这些数据表的基础之上，构建出商品系统。

水平切分

按照某个字段的某种规则，把数据切分到多张数据表。一张数据表化整为零，拆分成多张数据表，这样就可以起到缩表的效果了。

https://tech.meituan.com/2016/11/18/dianping-order-db-sharding.html添加链接描述 美团分库分表
数据库如何抗住高并发，如何提高查询效率？
分库

如何分库
停机维护。 具体情况具体分析。

上亿数据量的订单业务，生产环境，如何分库？
首先垂直拆分，然后针对数据量巨大的表再进行进行水平拆分。那么这张大表就被拆分成了多个有相同字段的小表，小标分散在不同服务器上的不同数据库中。查询业务的是后，先根据订单号，通过映射关系（映射关系可以通过取模等手段），查询到目标表的位置（在那天机子上，那个数据库中，数据库中的那张表）。

如何进行数据迁移

数据库双写（事务成功以老模型为准），查询走老模型。
每日job数据对账（通过DW），并将差异补平。
通过job导历史数据。

历史数据导入完毕并且数据对账无误。
依然是数据库双写，但是事务成功与否以新模型为准，在线查询切新模型。
每日job数据对账，将差异补平。

老模型不再同步写入，仅当订单有终态时才会异步补上。
此阶段只有离线数据依然依赖老的模型，并且下游的依赖非常多，经过时间验证（老模型中的数据全部处于终态），可以完全废除老模型了。

并非所有表都需要水平拆分，要看增长的类型和速度，水平拆分是大招，拆分后会增加开发的复杂度，不到万不得已不使用。
在大规模并发的业务上，尽量做到在线查询和离线查询隔离，交易查询和运营/客服查询隔离。
拆分维度的选择很重要，要尽可能在解决拆分前问题的基础上，便于开发。
数据库没你想象的那么坚强，需要保护，尽量使用简单的、良好索引的查询，这样数据库整体可控，也易于长期容量规划以及水平扩展。

分布式唯一id的生成?
利用数据库自增ID
优点：最简单。 缺点：单点风险、单机性能瓶颈。
Twitter Snowflake
优点：高性能高可用、易拓展。 缺点：需要独立的集群以及ZK。
美团做法
时间戳+用户标识码+随机数
优点：
方便、成本低。
基本无重复的可能。
自带分库规则，这里的用户标识码即为用户ID的后四位，在查询的场景下，只需要订单号就可以匹配到相应的库表而无需用户ID，只取四位是希望订单号尽可能的短一些，并且评估下来四位已经足够。
可排序，因为时间戳在最前面。
缺点：
长度稍长，性能要比int/bigint的稍差等

如果非要自增的，可以用redis。如果要的比较频繁可以一次多给这次请求一些。

mysql主从结构

主库负责写，然后同步到从库，从库负责读，分担数据库压力。

主从结构，从数据库会比主库慢，主从同步会有延迟，怎么解决
mysql可以设置半同步同步，一个写操作，至少有一个从数据库写入了（如果中数据同步的数据很高，可以设置全部同步完才算成功），才算写成功，才返回ack。
如果一个读一个数据，这个数据非常高（根据业务要求决定），主写了就必须读到，那这次读就直连主库。