纠结了好多天的事，今天终于告一段落，rabbitMQ可算是正常了（哦不对，应该说是某表某字段的索引终于正常工作了），话说前些日子，这个rabbitMQ消费者的处理效率低到零点，领导给出建议，要消费者集群并行处理（目前两台mq消费者服务器并行处理），该优化方案执行后，两台消费者并行处理的速度还是和一台处理的速度一样，让偶百思不得其解，代码review半天，也没看出个端倪，最后想想千万级的数据表，是不是查询性能已到极限，经过对比几张同业务的表，发现只有该地区表会查询过慢（事实上我已经打印log分析就是某地区某业务查询超慢），领导说 年后就要优化好，我都醉了，欲哭无泪啊，找了好多朋友做了咨询，发现无济于事啊，不过也长了不少知识（期间查机器性能，查各种...）。

今早不知道是什么指引着我四点多起来测试查询sql执行效率，很明显的发现了 同表，两个带索引的条件字段的查询效率有着明显的差别，一个平均花费一分多，一个平均花费是毫秒级的，啊，突然恍然大悟， 太有可能是 “索引失效” 导致查询效率下降，接下来就准备重建索引 （alter index idx_namerebuild online）在这个年关将至的最佳时机（用户量少，不用等到夜半），执行了重建索引命令后，mq处理速度立刻直线提升，堆压的一万多请求，分分钟消费完。
 

索引为什么会失效呢？纵览各路豪杰的blog后，回想起前阵子表空间满了的异常报警，有人给喊重启了rds，十有八九是这导致的（不是我重启的，换做是我，我也会重启）。
好多万的用户，月活也挺高，木有IM，只有MQ，大量依赖oracle的service，不是锁表就是掉索引。
rabbitMQ kafka 孰？

alter index JA_REMIND_MSG_RECEIVERIDX nomonitoring usage;//取消索引监控
commit
select * from v$object_usage where index_name='JA_REMIND_MSG_RECEIVERIDX';
select 'alter index '||'JA_REMIND_MSG_RECEIVERIDX'||' monitoring usage;' from user_indexes; //生成索引监控
alter index JA_REMIND_MSG_RECEIVERIDX monitoring usage;//新增索引监控

select * from v$object_usage where index_name='JA_REMIND_MSG_SENDERIDX';
select 'alter index '||'JA_REMIND_MSG_SENDERIDX'||' monitoring usage;' from user_indexes; //生成索引监控
alter index JA_REMIND_MSG_SENDERIDX monitoring usage; //新增索引监控

select * from ja_remind_msg where send_type=4 and  sender_id=10674110 order by id desc
select * from ja_remind_msg where send_type=4 and  receiver_id=454208 order by id desc

引子本人即将不用的sinaBlog_http://blog.sina.com.cn/u/1031590535