本章我们探讨下数据库架构设计的基本原则，以MySQL为例，这些原则可以指导我们去实现高性能数据库架构设计。

“表结构”设计原则

在“”表设计”方面可以遵循这么几个原则：

1、 注释原则

那注释原则是指在我们设计表结构的时候，所有的表以及所有的字段，都必须添加注释，以便于后续维护。这个注释原则虽然简单，但是有很多企业的很多项目，它其实都没有去遵循这个原则，导致后面项目维护起来会越来越困难，很多时候只能看代码，甚至靠猜，那这一点呢，我相信很多有项目经验的小伙伴会深有感触。这里把注释原则放到表结构设计原则的第一位，就是用来强调一下，很多时候规范是非常重要的。

2、 表数据量原则

当单表数据量达到800万的时候，可以考虑分库分表，那这里的800万只是一个经验之谈。如果你的项目没有分库分表的计划，那么可以把一些不常用的数据，通过归档的方式存放到其他的数据仓库里面，从而减少我们的数据量。

3、 表字段原则

首先不保存大字段，不要再数据库里面存储图片、文件等在大字段数据，否则的对数据库的压力，对应用的序列化，反序列化等都是一个挑战。一般来说建议把图片，文件等等存放到分布式文件系统里面是。这一点很多项目都是这么做的。其次，表字段不要过多，那建议单张表的字段应该控制在30个以内。如果某一张表的字段超过30个，则可以考虑拆分，也就是把这个表拆分成两张表或者是更多的表，让每张表的字段控制在30个以内。

4、 平衡冗余与范式，这一点在各个项目也是经常遇到。一般设计表都需要遵循第三范式，但合理运用冗余设计可以大幅度地提升应用性能。

以上这就是表设计相关的一些原则，再来看索引相关的原则。

索引相关原则

1、索引个数的原则

那对于普通的表单，单张表的索引数量不建议超过十个；而对于写入非常频繁的表，单个表的索引不应该超过五个，因为创建索引会带增删改的IO开销。

2、单个索引包含的字段，一般不建议超过五个。

3、对于组合作用要满足最左前缀原则，尽量把区分度高的字段放在前面，鉴于篇幅有限，如果不了解什么是最左前缀原则的话，可以先百度一下。

4、不要在索引面里进行计算。不管是数学计算还是函数计算，就是在where查询条件里，等号右边不要做任何的计算。我们应该在应用层进行计算之后，再把计算后的数值设置到这里来，

5、JOIN的字段创建索引，且拥有相同类型与字符集，避免隐式转换，导致索引失效。

以上就是索引相关的最重要的五个原则，接下来再看一看数据库的优化原则。

数据库优化原则

数据库优化原则可以遵循数据库调优金字塔。

数据库优化应该先从业务需求和系统架构的层面进行调优。如果没有调优空间的话，再去考虑SQL以及索引调优、表结构调优、数据库参数调优等，以获得更好的投入产出比。

数据库调优并不是架构设计阶段的重点，这个阶段的应该站得更高一点，重点探讨数据库的架构设计。

数据库架构设计的时候，要选择合适的数据库架构和方案。在这个阶段需要考虑的问题很多，是选一主一从、一主多从，还是多主的方案呢？采用读写分离，双写，还是多写呢？分库分表是选择数据中间件，还是直接在应用上实现呢？分库分表的规则又是什么？高可用的方案应该怎么设计？是使用mmm、pxc还是MGR呢？如何实现容灾呢？

这些问题都是在架构设计中需要去考虑的，并去选择合适的方案。

总之，最合适的架构其实是结合业务场景、软件特性、以及实施成本的一个平衡，我们要综合各方面的因素去选择合适的技术解决问题。那么实际项目中，本文中探讨的所有原则都可以活学活用，在必要的情况下甚至可以违反，因为原则只是一个指导，实际项目里面遇到的情况会复杂很多，合理采用反模式往往会有意想不到的效果。