遇到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都还不会，所以这种好东西我暂时也没有去了解。有空要学习学习吧。
　　结语
　　看起来复杂的东西其实道理不复杂，对，简单的是好的。