一力搜索

关系型数据库的行存储就不适合做AP分析，HTAP现在很多厂商也在做，思路也是多样的，比如比主库行存，备库列式存储

一方面你的中间件在解析语法树上保证下推效率高。得保证你的中间件中间数据可以写磁盘。账户跑批类型中间件建议和交易中间件拆分，我行过亿客户交易跑批都没问题，你们这种小行应该小菜一碟

这些场景完全可以读写分离。备库做就行，脚本自动寻找备库

看你的分布式数据库产品。我们核心交易系统在用，一个多亿用户。不过定制化优化必不可少，监控运维系统得跟上

是个能抓住问题要点的人。建议按业务拆分

你这些数据量和表数量都挺小的。mysql同样也有表分区的，往深里说，改innodb页大小也可以让b+深度不增加

性能其实不会有提升，为了解决全局读读写一致性，会引入复杂度和更多的耗时。如果容量不是问题，一个分片挺好的

表设计还好，选取唯一主键来做hash路由即可。但是得注意hash算法的选型和实现，建议一致性hash。否则后面线性扩容很麻烦