请教一下高频率读写的情况下，mysql应该如何优化？

需求是这样的：目前手头项目有个帮用户发送点对点短信的功能，用户一次可能发送几千或上万条短信，服务端接受用户的发送任务后，使用一个待发池慢慢帮用户发。但是页面上用户需要能实时查询短信的发送任务的情况：比如本次发送任务的成功数，失败数，发送任务的状态（全部发完，或正在发送中）， 任务中每条短信当前状态（待发送，发送成功，发送失败）等。每条短信发出后，外系统会异步地将状态报告回来

目前数据库结构是这样的：

数据库是Mysql，存储引擎Innodb，除了主键外键外还没有加其他索引

涉及到几张表：

短信发送任务表：记录用户提交的发送任务，字段有：短信内容，发送数，成功数失败数（明细表状态变更后要重新计算）整个任务的状态，短信内容
短信明细表：记录具体每条短信的发送情况，字段有： 所属短信任务id（外键关联到任务表），接收方号码，发送状态（外系统状态报告过来后需要实时更新）
待发池表：结构与短信明细表类似，用来储存发送队列，调用外系统接口发送后，删除记录。

现在遇到的问题是：如果将待发池发送量调大，短信明细表 跟 短信发送任务表 读写会非常频繁（特别是发送任务表里的成功数与失败数，量大了经常因为行锁而访问不了，或者最后数量上统计出错，成功数+失败数！=发送数）

我想问下：这种情况下，该对数据库如何优化？加索引？读写分离？还是直接把读写频繁这些字段搬出来放到memcache之类的缓存里，再定时持久化回mysql？