我有三个表是这样的，：文章表 article：
关键字表 tag：
关键字与文章的关联表 article_tag：
要求：给定一个文章的id（article_id） 通过关键字获取其他的文章并根据关联度排序！我些的sql是这样的：
select article_id,count(*) as count from article_tag where tag_id in(select tag_id from article_tag where article_id=1) group by article_id order by count desc 但是对于article_tag 表在将近20w 的记录时 查询速度在3s多！ 大家有没有什么还的优化建议(sql语句优化，表结构的优化，索引添加.....)
解决方案
- article表可考虑增加一列
tag_ids做冗余，这样就省略了一个in的子查询。这个子查询如果在表article_tag的article_id列上没有索引的情况，效率很低。>select tag_id from article_tag where article_id=1 - 如果tag比较多的话，再增加
article_tag的tag_id列索引，提高根据tag_id查询的效率。
针对你的需求，仅仅就sql查询的优化，差不多能想到的就这么多！在数据量不大的情况下(你列举的20w的级别)，应该能够解决。下面说一些数据库之外的优化：
- 首先，从应用需求的角度，关联度排序后的文章列表完全不必全部展示，也不必每次都实时查询数据库，因为这个关联列表对更新频率的容忍度比较高，这样的话，就可以冗余存储关联文章列表，例如每个文章只需存储关联度最高的10条记录：这方面segmentfault中每个问题右边栏的相关问题就是个很好的示例。至于实现方式：可简单考虑在表
article增加一列most_related_article_ids，然后定时执行SQL去更新表article的这个字段； - 其次，从应用实现的角度，上述每个文章的关联列表可能根据相同标签的个数，相同标签的权重，不同标签的关联程度来计算，这是有可能的后续需求。很显然这是一个复杂的算法实现，不是一个简单的SQL能够实现，前面提到的冗余存储关联文章列表就可以很好的解决这个问题，原先的定时SQL执行更新逻辑，可以交给程序来完成。
- 最后，如果这样还是存在效率的话，可以考虑缓存方案。(PS: 不建议一开始就考虑缓存，毕竟缓存方案会引入数据不一致、缓存失效和缓存更新策略等一系列新的问题，在简单的应用场景下，得不偿失)