终于来到数据库设计的最后一步，前面说到的逻辑分析、物理设计是创建数据库必须经历的，这么看来数据库的维护以及优化似乎就没有那么重要，自然，如果你满足于自己的系统永远被少数人使用，不会慢慢壮大，那你的项目的确不需要做必要的优化措施，但在项目需求会在使用人数的壮大，功能的增强中不断变化，那数据库的结构自然也需要相应的变化才能适用。
那么数据库优化需要做些什么呢？下面是我们比较常做的数据库优化的操作。
维护数据字典
数据字典是对数据库中的表、字段甚至是处理逻辑的定义和描述，简单来说，就是数据库的注释，它可以让我们清楚了解数据库中每一个列，每一个字段表示的内容是什么，其中我们经常使用数字表示某个状态，如果没有数据字典清楚的描述清楚，那我们维护这些字段就会变得十分困难，我就尝试过需要在代码中寻找对应的数字所表示的状态，十分耗时耗力。
维护数据字典最常见的方法自然还是使用备注来维护，以 MySQL 为例，它可以对数据库、表、字段增加备注字段，之后我们导出数据结构的时候就可以作为我们的数据字典来使用了。
当然我们也可以用第三方工具来维护数据字典，但不同的数据库系统需要找对应的第三方工具，相对来说比较麻烦，不推荐。
索引的维护
数据库的索引是能让你做数据库查询时快速查到自己想要的数据的利器，当你面对着千万级别的数据做查询的时候你就能清楚的感受到好的索引设计是多么的必要了。而因为需求的变化，我们之前创建的十分适用的索引也会变得越来越不适用，所以索引的维护也是数据库维护中十分重要的一块。
当然索引作为很好用的工具，其中包含着十分多的知识点，是一个很大的话题，所以这里就简单说明下怎样创建索引比较合适，想要深入的可以从索引的工作原理开始了解，会给你带来不小的启发。
以下是创建合适索引需要注意的点
1.较频繁的作为查询条件字段应该创建索引（where、group by、order by 从句中的列）
2.唯一性太差的字段不适合单独创建索引，即使频繁作为查询条件，例如性别字段等
3.更新非常频繁的字段不适合创建索引（字段内容，例如状态）
4.索引中不要包含太长的数据类型
还有一些需要注意的点
- 会占用磁盘空间，不要创建过多的索引
- 对（update、delete、insert）语句有影响，甚至对读也会有影响。
这里提供一个小小的方法，在执行某个 sql 查询时，可以在查询语句前加入 explain 关键字，它可以让我们看到我们是否在查询时用上索引。
表结构的维护
一个项目功能的变更往往会导致数据库表的列的变更，所以对变更后的表结构进行维护也是十分必要的，表结构的维护分为以下几个步骤。
- 使用在线工具进行表结构变更
- 表结构变更后记得更新数据字典
- 控制表的宽度（列的多少）和大小
进行表拆分
表的拆分分为垂直拆分和水平拆分，简单来说，当一个表的列太大的情况下，需要考虑垂直拆分，当一个表的数据量太大的情况，需要考虑水平拆分。
1.垂直拆分
垂直拆分的主要目的就是控制表的宽度，正常情况下，一个表的列达到几十列的情况下，我们就要考虑表的垂直拆分。
垂直拆分可以根据以下的两点去拆分
- 经常一起查询的列放到一起，可以减少连表操作
- text、blob这类的大字段放到附加的表中
2.水平拆分
当一个表的数据量达到千万级别，我们就需要考虑表的水平拆分，简单来说就是把一张表复制成多份，每一份存储的数据不同。
比较常见的是通过主键哈希的方式
我们可以先确定将大表拆分为几个小的表，例如拆分为5个表，则 id=103 的数据 103%5=3，可以将这个数据放到表2中（因为余数为0的是表1），这样就可以做到将数据平均的放到各个表中了。
当然还有一些订单数据可以通过时间拆分，因为时间较久的订单往往比较少进行查询，将此类订单与近期常用到的订单拆分开来也比较方便查询。
本次的数据库维护相关的内容对于初入职场的程序员是比较少涉及的步骤，但也是我们作为一个后端成长起来的时候需要去熟悉的、十分重要的内容，希望大家注意提升。关注公众号回复【数据库思维导图】可获取本次数据库系列的思维导图。
8027
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
