数据表可以分区，为什么还要分表呢？
数据库中的数据表可以分区，为什么还要分表？这个问题在评论区属于一个问的频率相对来说比较高的问题。对于实际的一些使用场景来说，分区也确实能够解决性能上的一些问题。它的实验逻辑跟分表差别并不是很大，都是属于水平拆分，都是物理分表，一部分数据分在这，一部分数据分在那。
而且对于分区来说，大家可能更加容易接受一点，毕竟分区表并没有像之前讲的分表一样，要手动建表，要管理主键，要管理索引等等。它的整体的数据服务对外是一个整体，也就是说只管查它的表名，至于到底查的哪个数据库文件，我不管。这一点我觉得分区对于开发的小伙伴来说还是相当友好的。
既然分区这么友好，为什么还要分表？这个时候就要提到分区的策略了。从目前MYSQL提供的分区的策略来看，它只提供了范围，哈希这些。分区的策略相对来说还是比较少的，只能按照范围，比如年月日来做一些数据的划分。
所以对于一些日志数据，历史记录来说，这个时候采用分区来处理了就比较合适，它会自动的按照时间范围找到对应的分区。但是对于一些个性化的分表策略，比如像这个，要根据地理位置，根据活跃度，根据业务类型等等多个因素来决定数据应该存储在哪个表里面。
这些拆分的策略就需要有较高的灵活度和自定义的能力，只能通过分表的方式来达到。分区通常也只能支持基于单一的字段或者简单的表达式来做一些拆分，这个是它的一个比较严重的问题。
另外就是对于跨数据库实例的拆分场景下，对于分表来说可以将数据表分散到不同的数据库实例，这个应该大家都能理解，甚至可以把不同的数据服务，放在不同的服务器上面，每一个实例或者是服务器只存储表的一部分数据。这种拆分策略特别方便业务的扩展，对于并发处理能力也能有一个很大的提升空间。
但是对于在分区的情况下，数据仍然存储在同一个数据库实例中，只能被逻辑上划分成不同的部分，在扩展性方面还是有一定限制的。简单来说分区主要就是用于同一个数据库实例里面，数据管理、查询性能的优化等等，它的应用场景相对来说还是比较窄的。
相对于分库、分表、分区，福报厂提供的大名鼎鼎的mycat分片策略可能对于中小厂来说更适合一些，它通过配置的方式定义好拆分策略。至于后面连的哪些物理表开发的小伙伴其实不用太多关心，只需要与mycat交互就可以了。从这一点上来看基本上也是综合了分区和分表的一些优势，感兴趣的小伙伴可以去看一看。
本期的视频就到这里了，如果您对本期内容有什么疑问，欢迎来到评论区，各位连谢谢大家。