单表千万已经是比较大的数据量了，提几个思路：
1、数据能否归档，如只保留最近3个月数据，将单表的数据量降下来；
2、查询条件限制有必填字段，且这些字段在数据库中有合适的索引；
3、考虑表适当做字段冗余，避免表关联查询；

硬件方面如有条件，表数据文件放到SSD硬盘。

联查的时候确保用上主键与外键， 建相对应的搜索字段的索引

如果索引做的差不多，但是效果并不是很明显的话，可以使用一些sql的函数替代本身的sql查询，达到sql拆分的目的（exists 替代in查询等），其他的也没有什么太好的建议
ps：作为一个问题的读者，请再具体一下问题的描述，这种描述其实很笼统，没有办法直接定位问题的所在

用搜索引擎吧

根据描述其实只能给出比较通用的优化方式，建议给出性能问题比较严峻的表的表结构，以及查询使用的SQL

“不带搜索条件，两张表join都出现时间问题了”

单表千万，但只要索引合理join也是没有任何性能问题的，这锅不是千万数据量和join的。

多有是你join的字段的索引问题，explain一下那条sql看看，对照着结果优化一下索引。

如果join字段两边已经都是索引，那么就该升配置了

1.读写分离
2.建立相关的索引字段
3.常用列表页和搜索项建立缓存机制
4.加硬件吧(服务器问题影响很大)。

只要join的时候能确保用到被连接表的主键或者唯一索引，其实join并不慢

刚好也在做这么一个分表改造,我的业务实际比你还复杂,我针对app接口查询维度,分成3类表,并且是每类表都是拆分n个表,这就不细说了,我拆成3类表是为了app查询方便,同时后台聚合列表数据因为实时要求不高,我用搜索引擎来处理

仅供参考