10分钟小幅优化亿级数据查询，优化亿级数据查询
前几天，一个用户研发QQ找我，如下：
自由的海豚。 16:12:01
岛主，我的一条SQL查不出来结果，能帮我看看不？
兰花岛主 16:12:10
多久不出结果？
自由的海豚 16:12:17
多久都没出结果，一直没看到结果过。
兰花岛主 16:12:26
呵呵，好。
兰花岛主 16:12:39
发下sql和执行计划。
自由的海豚 16:12:55
select n.c1, n.c2,n.c3,n.c4,n.c5
from (select count(t.c1), t.c1, t.c2,t.c3,t.c4,t.c5
from tab1 t
where t.c2 not in ('val1','val2','val3','val4','val5')
group by t.c1, t.c2,t.c3,t.c4,t.c5) n
where not exists
(select * from (
select count(s.c2), s.c1, s.c2
from (select m.c1, m.c2,m.c3,m.c4,m.c5
from tab1 m
where exists (select c1
from tab2 n
where c2 > sysdate - 14
and m.c1 = n.c1)
and m.c1 is not null
and m.c2 not in ('val1','val2', 'val3', 'val4', 'val5')) s
group by s.c1, s.c2) t1 where t1.c2 = n.c2)
and n.c1 is not null;
兰花岛主 16:13:12
这两张表大吗？
自由的海豚 16:13:16
tab1小，tab2亿级以上，两周数据在几千万。
兰化岛主 16:13:22
OK。
兰花岛主 16:16:29
这么改下sql吧:
with t1 as(
select count(t.c1), t.c1,t.c2,t.c3,t.c4,t.c5
from tab1 t
where t.c2 not in ('val1','val2','val3','val4','val5')
and c1 is not null
group by t.c1, t.c2,t.c3,t.c4,t.c5)
select t1.c1,t1.c2,t1.c3,t1.c4,t1.c5
from t1
where not exists(
select /*+ use_hash(m,n)*/ m.c1, m.c2,m.c3,m.c4,m.c5
from t1 m,tab2 n
where n.c2 > sysdate - 14
and m.c1 = n.c1
and t1.c2 = m.c2);
兰花岛主 16:16:43
取下执行计划。
自由的海豚 16:16:57
好的。
自由的海豚 16:17:25
兰花岛主 16:17:57
好的，试试吧。
自由的海豚 16:19:28
出结果了，37s
兰花岛主 17:20:21
嗯，好。
兰花岛主 17:20:34
这样可以吗？
自由的海豚 17:20:47
可以了可以了
兰花岛主 17:21:11
嗯，好，那就先这样，不继续调了。
自由的海豚 17:21:30
恩 好的 谢谢岛主
兰花岛主 17:21:53
不客气，忙吧，有事儿联系。
自由的海豚 17:22:18
恩，您忙。。。
至此，对用户这个sql的优化结束，其实，这个语句应该还有优化的空间，只是，用户说可以了那就可以了，因为优化是无止境的，而且，更进一步优化也许会需要更进一步的信息，且有时会需要更大的改动，鉴于各方面因素，文中对语句和计划进行了处理，记录于此，共勉！
建议采用oracle 数据库，可以把表按照规律分区，条件允许可以把不同的表放在不同的磁盘上也可以提升读写速度
单表一亿？还是全库1亿？
1.首先可以考虑业务层面优化，即垂直分表。
垂直分表就是把一个数据量很大的表,可以按某个字段的属性或使用频繁程度分类,拆分为多个表。
如有多种业务类型，每种业务类型入不同的表，table1,table2,table3.
如果日常业务不需要使用所有数据，可以按时间分表，比如说月表。每个表只存一个月记录。
2.架构上的优化，即水平分表。
水平分表就是根据一列或多列数据的值把数据行放到多个独立的表里，这里不具备业务意义。
如按照id分表，末尾是0-9的数据分别插入到10个表里面。
可能你要问，这样看起来和刚才说的垂直分表没什么区别。只不过是否具备业务意义的差异，都是按字段的值来分表。
实际上，水平分表现在最流行的实现方式，是通过水平分库来实现的。即刚才所说的10个表，分布在10个mysql数据库上。这样可以通过多个低配置主机整合起来，实现高性能。
最常见的解决方案是cobar，这个帖子介绍的比较完善，可以看看。
blog.csdn.net/shagoo/article/details/8191346
cobar的逻辑层次图：
不过这种分库方式也是有一定局限性的，需要应用程序做相应的配合，比如说分库的情况下，虽然可以实现跨库查询，但是不能进行相关的group by计算。
另外，之前关于水平分表的实现方式，也可以通过表分区来实现。
mysql优化的方式有很多，选择上主要还是要考虑个人的实际情况，如代码不可控的情况下，就不适合选择按字段属性分表的情况，这样可能会带来大量的重构以及很多不可预期的风险。
而架构的优化，虽然对应用是透明的，但对sql的写法有很多局限性，比如说不能使用聚合函数等等，同时也需要有充足的硬件资源，只有一台服务器的情况下是没有意义的。
相比起来，代价最低的是按时间分表或分区，这两种办法对应用来说都是透明的。
分区只需要一次本地数据迁移的操作。
而通过分表把现网数据和历史数据分离，唯一的代价是定期的数据维护。
一般如果表里面有1亿数据的情况下，索引的问题应该是常识了，这方面我就不说了。
另外如果觉得答的不错多给点分。
