分区、分表、分库

记得有一次，我帮一个做电商的朋友优化了他的数据库。
他的表，用户的产品表，实在是太大了，有几千万条记录，查起来太慢了。
他尝试分区，按时间分区，想把去年的数据放在一个单独的分区。
他发现有些查询必须跨分区运行，并且没有任何改进。

等等，还有一件事。
他告诉我，在他们业务和销售活动的高峰期，数据库的写入压力非常大，单个数据库无法承受。
于是，他们开始按照业务模块将数据库划分为不同的数据库。
数据库分区之后，写入确实快了很多，但是数据库之间的查询却成了新的问题。

我突然想到，他们后来把排行榜拆成了横表，把排行榜按照月份来划分，比如order_2 02 3 _01 ，order_2 02 3 _02 这样，单表数据量减少，查询速度更快。
但随之而来的是备份和恢复变得复杂，数据必须单独备份。

这件事让我深思。
分区、分表、分库就像数据库操作的三个阶段。
它们都无法治愈。
分区是先将数据分区到不同的地方，然后表分区进行分区，数据库分区最后将数据移动到不同的地方。
但每个阶段都有自己的陷阱。
例如，如果分区键选择不好，查询仍然很慢；如果分区表很多，链接查询就会出现问题；数据库分区后，必须花大力气解决分布式事务和数据一致性。

这么一想，数据库优化还真是让人头疼。
一定要结合实际业务，一层一层的，一层一层的测试。
不过话说回来，有没有一劳永逸的灵丹妙药可以一举解决所有问题呢？

一文搞懂MySQL数据库分库分表

分库、分表是处理大量数据的解决方案。
下面直接讨论要点：
1 ．子数据库：分为业务模块，独立的数据库，互相不接触。
2 、分表：对大表进行划分，优化表格设计。
3 、水平分表：按照规则进行分表，缓解性能瓶颈。
4 .分区：在数据库或机器中，MySQL分区仅限于单个数据库。
5 、哈希切片、区域切片：Sharding方法。
6 .中间件：ShardingJDBC、MyCat等，检测明显的欺诈行为。
7 、分布式事务：解决分片数据一致性如蝙蝠侠。
8 、选择子库和表：位置、性能、风险承受能力等因素。
9 .设计实践：主控控制、分片策略。

总结：应考虑分库和表的要求、SQL支持和选项。