关系型数据库分区

实际上可以多层分区自分区的形式
p b s item

如果按照item分区，是不是也更多张表各写一条数据一样慢？

实际上可以 p b s用column分区，好像column必须要range，那线性hash也不错，item用hash分区

Chapter 23 Partitioning
MySQL性能优化(六)：分区

维持现在的5张分表

• 按照时间分区
• 按照Hash分区

不闻此现在的5张表分区

为什么csv中前20列在一起就没问题，而item就不一样了呢
既然前20列可以看成一个自然整体，实际上每个item当然也对应一个测试记录也是一个整体，那么什么样的套路情况下就需要item分开了呢，也就所实际上任何信息都可以联系看成一条，分开的独立数据库这也有联系？

分开的方式又有哪些？这里首先想到的是垂直分表，

既然按照mongodb的索引
uername1 age1 ->2342asadf
uername1 age 2->2342asadf
uername2 age1 ->2342asadf
uername2 age2 ->2342asadf

也就说复合索引是有顺序的，那么实际山个value表增加item索引，那么数据库也能很快定位到连续的item，从而找到多个record的item列的所有值，即

item1 record1 -> 242342
item1 record2 -> 242342
item2 record1-> 242342
item2 record2 -> 242342
item3 record1-> 242342
item3 record2 -> 242342

或者

record1 item1 -> 242342
record1 item2 -> 242342
record1 item3 -> 242342
record2 item1 -> 242342
record2 item2 -> 242342
record2 item3 -> 242342

这两种索引顺序，在取出某列值得情况下哪种更好？

• 第一种的时间复杂度为log（3）*log（2）
• 第二种的时间复杂度为log（2）*log（3）

并没有区别，而且计算时间万个item，log之后也不大

这种复合索引和分区的比较，上面的情况感觉所有和分区的效果一样，不过好像索引导致的写入压力很大，而分区由于每个分区是一个文件可以并行

所有的不论分库，分表，分区，索引的方式都是将查找的时候能够很快的缩小范围，

Happy learning !!