开发者社区> 问答> 正文

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

小旋风柴进 2016-03-10 15:13:17 1252

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

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

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

涉及到几张表:

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

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

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

存储 缓存 关系型数据库 MySQL 数据库 索引
分享到
取消 提交回答
全部回答(1)
  • 小旋风柴进
    2019-07-17 18:57:44

    1、数据放进缓存里,到达一定条件时存储到mysql一次,比如一万条信息的发送记录

    2、采用SSD硬盘

    3、发送列表不要实时更新

    4、如果插入频繁还是不要加其他索引的好,毕竟几千条数据,人家只看总结,不看具体

    0 0
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

推荐文章
相似问题
推荐课程