实现了一个多站点多活动的抽奖程序，因为功能众多，建立了多个索引，最后导致添加时速度极慢，详情如下：
数据表zhongjiangma（MyISAM结构）
字段：
id
siteid 站点id
hdid 活动id
zjma 中奖码
status 中奖码的状态（0=未抽中，1=已抽中，2=已兑奖）
jpdengji 奖品等级（1等，2等，3等。。。）
userid 中奖者的会员id
zjtime 中奖时间
addtime 添加时间
要实现如下功能：
1.抽奖功能：查到某个活动某个奖品等级的一个未使用中奖码，发放给用户
2.查询某个用户在某个活动在一周内的中奖记录
3.查询某个活动的中奖码，用于数据更新
4.查询某个用户在某个站点的所有未兑奖的中奖码
针对4个功能，分别建了4个索引
索引1：hdid,jpdengji,status
索引2：hdid，userid，zjtime
索引3：hdid，zjma
索引4：siteid，userid，status
然后服务器为了防止一个php程序执行时间过长导致系统崩溃，作了运行时间的限制：超过10s就自动结束进程
开始只有索引1，2。
因为数据量加大，前端慢查询较多，加了索引3
这时在后台批量生成超过2万条中奖码时，就会出现502
后面又加了索引4，这时在后台批量生成超过3k条中奖码时，就会出现502
当前数据库中数据量为300万条左右
请问如何优化设计，既然减少慢索引，又能在后台正常添加大量数据？
------解决思路----------------------
这可以从几个方面来看这问题，后台批量生成一般都在活动开始前和空闲时生成，尽量不要影响正常业务，这需要在活动前作好足够的评估，生成足够的码，减少反复追加。
然后是数据库设计，既然码需要考虑频繁增加，那么最好把“源”码表独立开来，你的表在批量增加码时不是真正的生成，而是去“源”码表里去同步部分数据，而真正生成数据的是源码表，由于表是独立的，可以事先或者在码快接近用完前生成，而不影响你业务表的查询。
但仅这样在你同步码的时候可能还是会慢，所以你还需要把用户中奖信息独立出去，这也更加符合数据库设计范式。这样你的功能就被拆分三部分，功能1，3将查询你的业务表，功能2，4将查询用户的中奖信息表，源码表用来批量生成码，然后业务表在必要的时候提取已经生成好的码
以上仅代表个人意见