问：关系模式：User（userId, userName）， Article（articleId, userId, title, content），Vote（articleId, score），User为用户关系，Article为用户发表的文章关系，Vote为文章得票关系，title为文章标题、score为得票数。
（1）用SQL语言查询所有没发表过文章的用户名；
（2）用SQL语言查询得票数大于100的所有文章标题，按得票数倒序排列；
（3）用SQL语言查询出发表文章数大于5，文章平均得票数大于100的用户名，按平均得票数倒序排列；
（4）设计这些表的主键、外键和索引，并指出上面三个查询所使用的索引。
（5）当用户数超过1000万，文章数超过1亿时，如何考虑存储及性能的改进和优化？
答：
1 select * from User where useid not in(select userid from Article);
2 select title from article inner join vote on article.articleid=vote.aritcleid and vote.score>100 order by vote.score asc;
3有点不太会，下面胡乱乱写了一通
3 select * from user where userid in(select userid from Article inner join vote on article.articleid = vote.articleid group by userId having avg(score)>100) group by userid having count(*) >5;
4主键外键应该很简单，索引第一个应该是userid,第二个是articleid 和score，第三个应该是articleid和 userid
5用户数按照id分割分布式存储，文章类似，还可以用读写分离等策略水平扩展数据库.
其他答案：
第四题：
主键的话是毫无疑问的，user表里的userid,article表里的articleid，vote表里的articleid。
一般来说，在设计主键时，最好采用字符型的．不采用自动递增，在新增记录时，系统生成主键值。而且，主键最好不具有任何实际意义，因为带有实际意义的字段，还是存在被修改的可能性．而对于主键最大的忌讳就是修改主键，这可能会导致非常严重的不可估计的后果。
外键的话就是article表里的userid，vote表里的ariticleid。
建立索引的时候要注意，复合索引对多条件查询的速度提速是很明显的，但是用不好的话，不但对sql查询的速度没有提升，还会拖慢数据插入的速度。当数据量达到100万的时候，复合索引甚至会成倍的拖慢插入速度。比如article表中，建立(articleid,userid)索引，必须同时使用两列查询条件，才能使用复合索引，用userid关联user表和article表时，就不会走索引。
同理，SQL Server里面的聚类索引也要慎用。索引递增插入还好，否则就是悲剧了。
唯一性索引是效率最高的。
个人认为，user下userid列建立一个索引，article表建立两个索引，一个是articleid，一个是userid，vote建立一个索引，是articleid。
第三题：
平常习惯就不太常用having，跟前面不用in是一样的道理，having的效率总不会比where条件更快。语句如下：
select userid from(
select a.userid,count(1) articleqty, avg(c.score) scoreavg
from user a,artical b,vote c
where a.userid=b.userid
and b.articleid=c.articleid
group by a.userid
) aa where articleqty>5 and scoreavg>100
三表关联会消除没有发表文章的userid，但是为了减少子查询的条数，还可以进一步改进：
select userid,scoreavg from(
select aa.userid,avg(bb.score) scoreavg
from(
select a.userid,b.articleid,count(1) articleqty
from user a,artical b
where a.userid=b.userid
group by a.userid
) aa,vote bb
where aa.articleid=bb.articleid
and aa.articleqty>5
group by aa.userid
) aaa
where aaa.scoreavg>100
order by scoreavg desc
这样会根据发表文章数大于5做一个初步过滤，减小驱动表的数据量。如果大量存在非活跃用户，这种筛选还是能提速不少的。当然，最外面的一层查询可以改成having。
还有一种情况，就是如果没有人评分过的文章就在vote表中添加记录，而且大量存在未评分文章，那么vote表的数量就会比article小很多，可以使用第一个SQL，三表关联，以vote作为驱动表，也应该能提高不少效率。
第一题：
用not in还是not exists快，这要取决于不同数据库不同sql了。就此题来说，在SQL Server中两者是一样快的，正好有现成数据，刚试验了一下，user表跟article表各五万条数据，not in和not exists的写法运行时间均是五秒。分析执行计划也是一样的。主要的时间代价花费到了三个地方：两个表的索引扫描约是55%，多线程的并行分拆及合并11%，哈希匹配14%。看了一下执行计划，SQL Server对这两者皆做了优化，主要工作还是在索引和建立hash关系上，于是就有了第三种写法：
select count(userida) from(
select a.userid userida,b.userid useridb from user a left join article b on a.userid=b.userid
) aa where useridb is null
试了试，跟not in, not exists执行计划基本一致，运行时间也是一样的。
在oracle下就复杂多了，RBO还是CBO、表的大小都有可能改变执行计划。在基于规则的RBO优化器下，exists和in的执行计划是一致的，跟 not exists, in ,not in执行计划都不一样，其中exists, not exists使用了不同的hash计算，not in是效率最低的，用的是filter，要做笛卡尔积再用条件过滤，巨慢。不过通过加HINT，可以选择合适的执行计划，这点也是我喜欢oracle不喜欢sql server的一个重要原因，在上百行的复杂sql的优化中很是有用。
综上，写not exists是最保险的做法了，基本能保证速度最快。
第五题：
1、我把3个表合成一个表：Table（userId, userName，articleId, title, content，score）
理由：一个userName不占用很多存储空间，空间换取速度，如果有其他属性，可以分成用户表和文章表，甚至可以做一扩展属性表，把不常用的属性放入扩展表，减少查询数据的表连接，userName字段的变动不会很大，即使变Table不一定要跟着变，这样可以知道在发表该文章的时候userName是什么，如果一定要变建立userId的索引，update也是很高效率的。
2、根据用户的点击率和、登录频、文章点击率等高使用频率分级存储数据
3、建立相关查询的表索引，使用服务器缓存高使用频率的数据
上述答案的建议：
1首先3个表应该不能完全合并的，毕竟用户和文章是一对多的关系，
2索引，缓存数据库，分布式确实是第五题的通用解决方法，
3还有就是数据库的一些性能调优比如mysql的 table_cache key_buffer_cache，合理利用服务器超强的性能
第一题：
select username from user usr
left join article art on art.userid = user.userid
where art.userid is null;