高吞吐量的实时交易数据库设计
最近要帮朋友改一个实时交易的系统， 以前的系统做得比较差,数据库设计很简单，就是想办法将所有的数据的存起来，主要的问题是效率越来越慢。

特别是交易的表，几秒钟可能要插入几万条， 同时还要在业务表检索，客户端经常卡出，我觉得这应该是数据库设计中最常见的问题，不过我自己也就做过最简单的设计，所以想问问各位大神，有没有什么好的方法。

1， 是不是要把业务表水平分表，一个表储存所有记录，一个表储存实时记录，然后插入时，同时插入两条数据到各个表中

2， 临时表有没有帮助， 临时表怎么用，应该怎么设计呢

3， 是不是还要有什么分页技术的，这个完全不懂了。

4， 肯定有很多我不知道的方法，求指导

------解决方案--------------------
几秒钟可能要插入几万条？
什么系统？什么硬件配置？？

插入和查询分开
插入还能按业务、时间再分就更好
------解决方案--------------------
几秒钟插入几万条数据的交易系统，生意这么好，怎么会使用新手进行优化？

分表是最后手段，、分页技术挨不上优化技术。

加索引优化才是正道，实在大得没谱才用分表，因为看样子你们公司缺乏技术力量。

盲目搞分表，只会整乱系统业务逻辑。加索引不会影响生产系统运行。
------解决方案--------------------
对于在业务表检索，客户端经常卡出的问题，可以考虑创建一个存储过程+JOB实现超过3天（具体时间根据业务情况设定）的从当前表转存到附表，以减轻当前业务表的负担。
------解决方案--------------------
像证券交易，是可以分表
不过前提是性能压力太大，否则分表后查询会麻烦很多

分区表则是底层分表以得到高性能，应用操作照旧：sql面对的还是一个大表