我线上数据库有些记录表的数据量，已经达到千万级别，查询效率有点慢。于是想通过分表进行优化，因为不想在代码层面改动。百度说merge可以做到。但是测试发现 merge 引擎并没有像我想的那么友好，我以为 meger 引擎会自动开启并发检索子表，所以在速度上要比查询为分表的大表要好很多，但实测发现效率几乎无异，甚至会降低。 那么
1、merge分表也要在业务层上实现并发检索子表来实现分表带来的优势么？
2、分表后如何实现全局的分页场景？ 直接使用 merge 引擎的确很方便，但性能和不分表没什么区别....还是要自己在业务层实现并发检索子表来凸显分表的优势么？
百度的我都看过，测试过就不用发链接了。想听听大家实际上怎么处理的
首先，你要明确下，查询速度慢的根本原因是什么？单纯的单表1000w数据量，还是ok的，不算很大。主要还是看看查询条件和索引问题。如果做了水平
分表，查询列表这种场景就要被限制，分表主要还是解决了单一查询的性能问题，分还是不分，都有利弊，主要是看业务查询场景的侧重点。而且，分表的方式
有很多种，水平分，或者定期归档等等，具体拆分的方式要看业务场景。
如果数据日增长量不是很大，建议还是从其他方面优化性能。
千万级别不算大，查询语句合理的话还是可以0.00几秒的查询速度的。
首先先分析语句慢的原因，优先通过优化语句来解决问题。
如果语句是没办法优化，那么可以通过业务代码来优化，比如加上缓存。
千万级别真没到分表地步，如果真要分表，不要自己写分表的逻辑，不然增删改查都特别麻烦，推荐是使用一些免费开源的数据库中间件