如果你对长篇大论没有兴趣，也可以直接看看结果，或许你对结果感兴趣。在实际应用中经过存储、优化可以做到在超过9千万数据中的查询响应速度控制在1到20毫秒。看上去是个不错的成绩，不过优化这条路没有终点，当我们的系统有超过几百人、上千人同时使用时，仍然会显的力不从心。
目录：
分区存储
优化查询
改进分区
模糊搜索
持续改进的方案
正文：
分区存储
对于超大的数据来说，分区存储是一个不错的选择，或者说这是一个必选项。对于本例来说，数据记录来源不同，首先可以根据来源来划分这些数据。但是仅仅这样还不够，因为每个来源的分区的数据都可能超过千万。这对数据的存储和查询还是太大了。MySQL5.x以后已经比较好的支持了数据分区以及子分区。因此数据就采用分区+子分区来存储。
下面是基本的数据结构定义：
对于拥有分区及子分区的数据表，分区条件（包括子分区条件）中使用的数据列，都应该定义在primary key 或者 unique key中。详细的分区定义格式，可以参考MySQL的文档。上面的结构是第一稿的存储方式（后文还将进行修改）。采用load data infile的方式加载，用时30分钟加载8千万记录。感觉还是挺快的（bulk_insert_buffer_size=8m）。
基本查询优化
数据装载完毕后，我们测试了一个查询：
这是毋庸置疑的，通过id进行查询是使用了主键，查询速度会很快。但是这样的做法几乎没有意义。因为对于终端用户来说，不可能知晓任何的资料的id的。假如需要按照username来进行查询的话：
mysql> explain select * from tmp_sampledata where src between 1 and 7 and username = ‘yourusername'\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: tmp_sampledata
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 74352359
Extra: Using where
1 row in set (0.00 sec)
</div>
那这个查询就没法用了。根本就没人能等待一个上亿表的全表搜索！这是我们就考虑是否给username创建一个索引，这样肯定会提高查询速度：
create index idx_username on tmp_sampledata(username);
这个创建索引的时间很久，似乎超过了数据装载时间，不过好歹建好了。
&