数据库中，一般来说我们在操作时，一般操作如下几个对象：

一、数据库(database)

二、模式（mysql中没有schema的概念，在其他的数据库中有schema，尤其是pg库中）

三、表(table)

四、字段(column)

五、字段类型(column_type)

六、字段长度(column_length)

七、是否为空

八、主键

九、外键

对于数据维护来说，关于数据库我们考虑这些对象如何操作就可以了。但是数据库在实际的使用过程中，只考虑这些是不够的。以当前遇到的业务场景来看，我们更多时候遇到的一个比较难搞定的事情是随着服务平台的运行，数据会越来越大，我们的一些查询操作就会变慢，这个时侯就会带来许多的问题，如一些看板，即使是常规的服务取数据也会变得很慢。类似于看板等业务，我们一般都会是以时间作为参数，进行where条件取值，在一般的数据库中，当数据量达到500w以上时，查询性能就会下降很多，而且对于许多对于效率有要求的业务系统来讲，是无法接受的。所以在设计的时候，建议先考虑一下这个隐患。

目前来说，简单一点的方案就是分表，把数据分为冷数据和热数据，如看板，一般显示一段时间的指标就可以了，这个时候我们就可以把一些历史数据存储到另外的一张表中，需要计算的表和需要被查询的表，我们尽量去保证其数据量不要超过某一值。这个就需要对表定期做调度处理。但是总有些时候，我们要对一些表的历史数据做分析，所以对于历史数据，从数据服务来讲，我们更多的时候，不做查询，只做存储，当数据量很大的时候，我们可能也会需要去选择按年、按季度分表存储，所以类似于这些表，我们要对其做生命周期的设置，并定期把历史数据进行迁移。这样才能保证需要进行查询的数据库中的查询效率。

如果在系统开始设计的时候未考虑到这一点，在实际操作的过程中，却已经发生了，建议先考虑一下业务需求，然后再考虑一下操作方案，不要上来就操作。对于我们来讲，我们已经知道了是由于表内的数据量过大，而影响到了其运行效率，所以我们第一想法或者说最合理的方案就是减少表内数据量。这个时候，我们需要考虑一点，带条件的删除，其运行速度也没有很快，所以如果时间不允许的话，几个小时的删除数据时间会带来更多的问题，甚至会出现锁表现象，然后再去解决一系列引发的问题。目前来看最快的方案其实是直接新建一张表，然后对表名称进行处理。将原表的名字进行更改，新建一张空白表，这样历史数据有了，新表也可以接收数据写入。如果无法接受在更新表名称时系统所带来的问题，那第问题就会比较麻烦了。如果有时间可以测一下的，当数据量很大的时候，但凡带条件的操作，都会需要很久才能返回结果，因为需要扫描全表。

其实还是有其他的方案，但是感觉还是一样的，就像阿里的Odps数据库，虽然表有分区，但是当分区的数量达到某一级别时，查找分区也会需要较多的时候。再换一个比喻就是我们现在是对数据分表进行查询，执行sql语句的时候，先找表再从表内找数据，但是假如我们的数据库中有很多表呢，先找到表就要花费较多的时间，当然，一般的数据库中有对表的数量进行限制，而我们在这里也只是想要做个类比。

其实上边说了许多，无法就讲了一个点，当数据库中数据量越来越大，我们应该采取什么样的方式进行解决？