如何设计一个“已读”系统？

这个问题是一个很综合的问题，不是单靠 SQL 就能很好解决的（虽然也能）。

按你的思路分析技术可行性
新闻和每个人的已读状态，其实是一张二维表，横纵坐标分别是新闻ID和用户ID，这张二维表的大小是新闻数和用户数的乘积，那是相当的大。

所以，从建表来说，不管你是建一张新闻与用户的状态关系表，还是为用户建一张已读新闻状态表或者为新闻建一张已读用户状态表，都不是很好的方案。

如果是新闻用户状态关系表，假如有10,000用户，1,000新闻，这张表的数据在最大的情况会有10,000,000条记录。
建用户的新闻状态表和建新闻的用户状态表都一样，需要个巨大的字段，一般可能是TEXT和BLOB，非常不利用搜索。
在这种情况下，即使使用 No-SQL，都难以解决问题。所以需要变通。

分析合理的需求
首先一个问题，你显示在首页上的新闻可能会显示很旧的新闻么？换句话说，如果所有近一个月的新闻该用户都读完了，你会把上个月的新闻显示给他么……？不会吧！这样的话，新闻本身已经没有意义了。

那么，合理的作法是什么呢？应该是显示在某个时间段内的新闻，比如最近3天。先限定一个范围，然后再来思考这个范围内的逻辑。

但是要加一个逻辑处理，就是这3天的新闻，用户都看完了怎么办？理论上来说，应该显示最新的新闻出来，即使已经看过了。

当然这只是一个粗略的分析，具体是什么情况我并不清楚，需要你自己根据需求去研究细化。

合理需求下的实现
近3天的新闻已经是一个不大的量了，在这个范围内，完全可以按照之前的想法进行实施，不管用上面哪种方法，都不会有巨大的数据量（当然要记得删旧数据，即3天前的相关数据）。