select * from (select * from tb order by id limit 20) t1 order by weight limit 5;

@virushuo 老湿也这么圆，真好。

你数据要写那么多，往磁盘写多少数据是不可避免的。

你的问题是什么？怎么设置让数据写内存不写磁盘？数据库崩溃了你怎么办？服务器崩溃了你怎么办？

@sdjl 如果这样你可以把这个表引擎改成memory引擎，自己写个crontab定时dump出来这个表的数据，并且这个表不记录binlog，设置如下

binlog-wild-ignore-table = your_table

使用一种可追加的压缩包，比如zip，之后写个脚本很容易做到。

for i in `ls /tmp/a/`; do zip -r /tmp/a.zip $i;rm -rf $i; done

不好意思，转了10块，不是6的倍数，破坏你规则了。额。加油。

并不是平均每秒要写入1-2M的数据IO就有压力了吧，你确定你IO有压力了？

要优化IO也是让MySQL尽量Merge IO以减少随机IO和过多小IO，你数据要写那么多，往磁盘写多少数据是不可避免的，sync_binlog的设置对IO的影响比较大。

the things you own end up owning you.

@acpp https://github.com/napoleonu/merge_schema 我之前写的一个。

cd /exmaple/ ; ls | grep -v 'd' | xargs -n1 -i cp -rf {} /example2

LZ用了innodb并且使用共享表空间吧。

@gfreezy

如果用上覆盖索引（index1(last_reply_time,topicid)，index2(post_time,topicid)，index3(tagid,topicid)）之后再通过get_multi获得列表详细确实比走覆盖索引再join一下topic 表或者再回表获得详细信息效率高很多，mysql数据量大之后join的效果不是那么理想。多谢指导，获益匪浅。

这是建立在从cache拿数据比直接从数据库拿数据效率高，没有测试，实际上也不一定，别的不说，直接从数据库join拿，只需要一次网络IO，而从数据库拿到再去cache获得详细得两次网络IO。当然当数据量很大并且越来越大，随着join性能越来越低的时候走cache的效率会越高，水平切分的分布式系统就更不用说了。

还有一点我想说的是，即使是 stackoverflow.com 这种全球排名百名内的站点，这么多年来也就400万topic的数据，大网站并没有想象的那么多。百万量级甚至千万量级的数据规模下，LZ这种设计可以说一点问题都没有，特别是在内存廉价和SSD出现后，facebook数据库服务器标配内存不都128G还是256G了么。

从楼上的各个回答来看，使用或者赞同这种设计的人不在少数。退一万步讲，冗余下tags对于生成cache也是有好处的，而业务复杂度和空间上损失的代价也不是那么高，当然如果cache用的好看起来必要性似乎也没那么高，但肯定称不上幼稚的设计。

@gfreezy id list哪里来的？数据库读？

用户记不住

@ElmerZhang 用户通过某条post的tag查找这一tag的所有信息流程可以这样

通过tag获得tagid（tagid_tag表）

通过tagid获得这一tag的所有post （tagid_postid表）