单数据库和单表是最常见的数据库设计。例如，一个用户（用户）表放在数据库DB中，所有用户都可以在DB库的用户表中找到它。
数据存储进化思想二：单库多表
随着用户数量的增加，用户表中的数据量将增加。当数据量达到一定水平时，对用户表的查询将逐渐减慢，从而影响数据库的性能。如果使用MySQL，一个更严重的问题是，当需要添加一个列时，MySQL锁定表，而所有读写操作只能等待。
有可能以某种方式横向切断用户，产生两个表的结构是完全一样的user_0000，user_0001，user_0000 + user_0001 +。数据是一个完整的数据。
数据存储进化思想三：多库与多表
随着数据量的增加，单一数据库的存储空间不足。随着查询量的增加，单个数据库服务器无法支持它。此时，数据库可以再次进行水平分区。
MySQL数据库表仓库规则
当设计表需要根据拆分表的这种形式来确定什么样的规则时，例如，当有新用户时，程序必须决定向用户信息添加哪一个表。同样，当登录时，我们必须通过用户帐户在数据库中找到相应的记录，所有这些都需要遵循一定的规则。
路线
表格的拆分过程中找到相应的规则表和图书馆。如表库的规则是user_id mod 4，当新用户注册一个帐户，123的帐号，可以使用ID mod 4如何确定该帐户应存放在user_0003表。当123用户登录，我们决定在user_0003记录通过123国防部4。
下面是拆分表生成问题，以及注意事项
1。分维表问题
如果用户需要购买商品，交易记录，如果与用户的纬度表一致，每个用户记录存储在相同的表，所以迅速和容易地找到用户的购买，但购买商品可能分布在多个表中，找到更多的麻烦。另一方面，根据商品的尺寸，它是要找到货物的购买很方便，但它更是麻烦找到买家的交易记录。
所以一般的解决方案是：
通过扫描表解决。这种方法基本上是不可能的，而且效率太低了。
记录两个数据，一个根据用户的纬度，一个根据商品的尺寸。
C.是由搜索引擎解决的，但如果实时性要求很高，就必须与实时搜索有关。
2。联合查询问题
联合查询基本上是不可能的，因为关联表可能不在同一数据库中。
三.避免跨库事务
避免在一个事务中修改表DB0和修改表DB1中的同时。一种操作更复杂，对效率也有一定的影响。
4。尽量将同一组数据放在同一数据库服务器上。
例如，商品和交易信息的卖方一个放在DB0。当db1挂起来，卖方相关的东西都可以正常使用。也就是说，避免在数据库中数据依赖于另一个数据库中的数据。
一个主
在实际应用中，大多数情况下都是读比写。MySQL提供了读写分离的机制，所有的写操作必须符合主人，读操作可以在主机和从机进行的，奴隶和奴隶主的完全一样，可能有多个奴隶主，甚至还可以把奴隶的奴隶，通过这种方法可以有效地提高QPS。数据库集群
所有的写操作都是主控的第一次操作，然后由Slave向主从机更新，所以同步机有一定的延迟，当系统忙时，延时问题会更严重，从机也会增加机器的数量，使问题更糟。
此外，我们可以看到，主是集群的瓶颈。写得太多，会严重影响主人的稳定性。如果主机挂断，整个群集将不能正常工作。
所以，1。当读取大量压力时，可以考虑添加从机来解决小数从机，但当达到一定量时，应考虑在2下。当写作压力很大时，将不得不进行银行操作。
mysql为什么要拆分表
你可以用mysql说，只要有大量的数据，就会遇到问题，拆分表。
下面是一个问题的引用，为什么不拆分MySQL大表
它实际上是一个可以处理的大表。单台物理文件大小的单表我经历了超过80g，单表记录超过5亿，并且表超过5亿。
它属于一个非常核的手表：朋友关系表。
但这种方式并不是说最好的办法，因为一个文件系统，如ext3文件系统，有很多大文件处理问题。
这个水平可以与XFS文件系统所取代。但是当MySQL单表太大时，一个问题是它不好解决：表结构调整相关的操作基础
这是不可能的。在会议监控应用程序表仓库中使用的项目中。
从InnoDB本身，还有对数据文件树只有两把锁，叶节点的子节点的锁和锁，可想知道当页拆分或添加。
新的叶子不写数据的形式。
所以，仓库也是一个不错的选择。
那么拆分表有多少
在单表1000万记录测试后，写读性能更好。所以在左点缓冲区中，单个表就是所有的数据字体。
在800万记录下，只有一个字符类型的表保持在500万以下。
如果计划了100个库100个表，如用户服务：
500万×100×100＝5000亿＝5000亿记录。
有一个数字在心里，更容易计划的业务。
