why delayed_job's priority is: lower is more imporant ? (为什么delayed_job的priority是数字越小越重要？）

delayed_job有两个分支，一个是  collectiveidea的(https://github.com/collectiveidea/delayed_job/wiki, priority越小越重要），一个是 tobi的(https://github.com/tobi/delayed_job 已经不再维护) ;

今天用delayed_job生成了 5W个子任务，然后发现任务进行的很慢： 

mysql一直是占用150%的CPU

每秒 最多处理10个任务，而不是5K左右job下的 30job/s.  

考虑了很久查看了slow_query, 发现有时候一个update需要耗时 6秒以上。而且发现了这个文章： http://www.elevatedcode.com/2009/11/04/speeding-up-delayed-job.html

总结了一下，原来在大数据量下面， 问题的瓶颈在于一个查询，这个 查询的优化方式是需要对两个列进行排序的索引：

" ... where ....  order by priority desc, run_at asc " 

而对于一般的数据库来说（例如最常见的MYSQL），他可以进行两个column的组合索引，但是结果是 "priority asc, run_at asc"， 而不是 "priority desc, run_at asc" (据说oracle可以这样做）  

所以，解决的办法是：

1. 对priority + run_at 增加组合索引

2. 对 priority 越小越重要，这样就可以写出:  "... order by priority asc, run_at asc"