有如下几种解决思路：
查出所有的问答数据，然后调用用户服务进行拼装数据，再根据过滤字段state字段进行过滤，最后进行排序和分页并返回。
这种方式能够保证数据的准确性和完整性，但是性能影响非常大，不建议使用。
查询出state字段符合/不符合的UserId，在查询问答数据的时候使用in/not in进行过滤，排序，分页等。过滤出有效的问答数据后，再调用用户服务获取数据进行组装。
这种方式明显更优雅点。笔者之前在某个项目的特殊场景中就是采用过这种方式实现。
跨库事务(分布式事务)的问题
按业务拆分数据库之后，不可避免的就是“分布式事务”的问题。以往在代码中通过spring注解简单配置就能实现事务的，现在则需要花很大的成本去保证一致性。这里不展开介绍，
感兴趣的读者可以自行参考《分布式事务一致性解决方案》，链接地址：
http://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistency
垂直分库总结和实践建议
本篇中主要描述了几种常见的拆分方式，并着重介绍了垂直分库带来的一些问题和解决思路。读者朋友可能还有些问题和疑惑。
1. 我们目前的数据库是否需要进行垂直分库?
根据系统架构和公司实际情况来，如果你们的系统还是个简单的单体应用，并且没有什么访问量和数据量，那就别着急折腾“垂直分库”了，否则没有任何收益，也很难有好结果。
切记，“过度设计”和“过早优化”是很多架构师和技术人员常犯的毛病。
2. 垂直拆分有没有原则或者技巧?
没有什么黄金法则和标准答案。一般是参考系统的业务模块拆分来进行数据库的拆分。比如“用户服务”，对应的可能就是“用户数据库”。但是也不一定严格一一对应。有些情况下，数据库拆分的粒度可能会比系统拆分的粒度更粗。笔者也确实见过有些系统中的某些表原本应该放A库中的，却放在了B库中。有些库和表原本是可以合并的，却单独保存着。还有些表，看起来放在A库中也OK，放在B库中也合理。
如何设计和权衡，这个就看实际情况和架构师/开发人员的水平了。
3. 上面举例的都太简单了，我们的后台报表系统中join的表都有n个了，
分库后该怎么查?
有很多朋友跟我提过类似的问题。其实互联网的业务系统中，本来就应该尽量避免join的，如果有多个join的，要么是设计不合理，要么是技术选型有误。请自行科普下OLAP和OLTP，报表类的系统在传统BI时代都是通过OLAP数据仓库去实现的(现在则更多是借助离线分析、流式计算等手段实现)，而不该向上面描述的那样直接在业务库中执行大量join和统计。