浅谈数据库

数据库

数据库是一个软件的灵魂。软件 = 设计 + 程序 + 数据
那数据库需要注意什么呢？

数据库的索引

B+ Tree
为什么是B+ Tree 呢？首先要从B+ Tree 的数据结构考虑，（读者先行了解B+ Tree 的结构，如果理解困难，笔者再开一章另行解释）
因为B+ Tree 的结构，再基于数据库查询是一页一页（磁道）的，所以会以很小的复杂度查询到数据。
新增数据在索引建立方面，也会更加便捷。

推理

如果表字段有大文本，需拆出新表关联存储。不然将降低原表查询效率，因为大文本内容，使得一页数据量减少，必然增加寻找时间
联合索引 最左原则，因为联合索引的数据结构，类似K-V 结构, 这样理解的话，K的查询会很快，V的查询会遍布在多个K中，必然会走全表检索。
左like, 同理可得出为何左like能够走索引，因为左like 可以确定大致的范围，检索范围有限，如果不是左like, 那么检索时无法确定K的范围。

数据库分表

单表体量达到一定程度，整个性能必然会降低。那有哪些解决方案呢？
分区/分表/分库

分区

分区不需要考虑表结构的变更，只需要对表内容按照一定的逻辑进行执行即可。
分区逻辑上是一个表，但是物理上可能已经在不同的磁盘上存储。
索引不会影响原有查询逻辑

归档

归档的对象是冷热数据，不是所有的数据都是热数据，有些一年以上，低频访问的数据，不给用户查询，但提供客服查询功能，尽最大可能提高日常数据库查询效率

分库/分表

是建立在分区等手段已经不足以优化整体性能的基础上的手段，但有一定的运维成本，需要数据迁移。
需要考虑拆分多少个库？什么时候拆库？拆库的逻辑是什么？等等
一般考虑日常用户等增长情况，会一次性拆分为32 库 ✖ 32 表，如果计算还觉得不行可以拆分为64 库 ✖ 64 表

分库/分表的后续

分库后，是不是就万事大吉了呢？
显然不是，需要考虑分库后，查询怎么办？事务怎么办？
基于MyCat 的PXC 高可用方案