遇到1000万数据表

最近遇到一个问题，就是单表数据过1000万的存储及查询问题。举个例子：1000万的数据存在一个表中，字段4-5个样子，日常 开发中难免要做过滤、排序、分页。如果把这几个放在一起即要过滤又要排序，还要分页那么数据量大一些就会发现特别慢。

10多年前刚入行时就听许多的人讨论分页，说什么1000万大表分页存储过程啥的。我之后一直工作中也没怎么遇到大数据量的开发工作，也真是惭愧啊，现在算是补补课吧。

1000万数据分个页吧

常用的数据库产品对分页都是有一些支持的，SQL语句肯定是OK的，同样的问题在于如何高效。因为分页查询最大的问题在于查询越往后的数据就越慢，因为要扫描的数据多。比如要查询第9999900-10000000之前的记录，就得将前面的数据找起。

为什么会这样呢？因为数据存在存储介质里，是一种数据结构的，计算机通过指令来查找想要的数据就要有一种算法，因为机器本身不知道你想要哪些数据。所以在数据写入时的自然顺序会在具体查找时变成麻烦。

换句话说，如果不在乎时间长短，那么分页查询其实也没多大事，大不行等个几十秒也能出来数据。但现实是这很难被接受。所以现在有一些方法来加快这个过程。

比如人们就想出一个方法，在分页查询前记录一下最后那页的记录的ID，然后查询时直接从这个ID往后找数据，这种方法就解决了上面说的扫描问题，利用数据库的数据检索功能大大提升性能。

但这种方法有弊端，毕竟这个ID需要有顺序啊，所取的数据也要是排过序的。但这说明想要提升效率方法是有的。

索引

我也不知道为什么，一直以来就很惧怕数据库方面的开发，我心中索引一直是个很复杂的东西，所以工作许久也没有好好去学习一下。最近正好亲密接触了一下，才发现这东西真是好东西，也没有想象中的那么可怕。

所谓索引其实就是对特定的数据进行一种排序，然后与实际的数据记录作映射，这样的好处就是扫描数据时可以在一个有序的集合里查找，那么算法自然就简单高效啦。在实际应用中也发现，通过索引查询性能可以大幅提升。

当然索引并没有这么简单，在什么字段上建索引很有讲究，要根据实际业务情况来决定。这也就是为什么一些电商的网站很少会有所有字段都给排序的原因，因为这种成本是很昂贵的，甚至不可实现。大家注意淘宝是不是只给了特定的一些排序方式？

NoSQL

N多年前在NoSql开始流行时我就想学习来着，但可能是自己太懒的原因，直到今年我才开始了解了NoSql。目前听的最多的Mongodb，甚至还有Redis也称为Nosql，HBase之类的。它们有什么特别呢？

我觉得Nosql最大的特点在于基于Key-value，这个特点的好处就是易于数据的扩展。传统数据库一旦遇到数据大了要么就是分库、分表，还有垂直，水平分的。但是NoSql天然解决这个问题，因为数据可以通过算法进行横向扩展。而且Nosql通常保存的数据结构也比较特别。另外Nosql通常是利用内存多于磁盘，这样可以大大提升读写效率吧。

在K-V的基础上提供一些类SQL的功能，就变得非常好用了。比如Mongodb可以实现过滤、排序、分页等操作，这对于开发人员来说简直神了，不用担心跨库或者跨表查询啦。

但是也有弊端，比如join操作可能就没这么好玩啦。

SQL+NoSQL

最近看到国内有个团队在做一处TiDB的开源项目，是基于google的论文开发的一套数据库，特点就是兼容mysql，同时又有nosql的高效和扩展性。这简直更神了，我只能膜拜。只不过我连mongodb都还不会，所以这种好东西我暂时也没有去了解。有空要学习学习吧。

结语

看起来复杂的东西其实道理不复杂，对，简单的就是好的。