彩票号码的检索性能

目前有一组彩票号码,比如:0105080915 23从数据库中检索该号码的中奖用户,注意数据库中的号码记录可能为上亿条数据,是针对全世界范围的彩票项目,讨论一下采取什么方式从数据库中检索配对的中奖号码效率更好,更合理,更快速.

每个人买彩票如果为单式，则存为1条记录，表结构：(组号，号码)；
如果为复式，则计算转化为对应的多个单式，每个单式同样存1条记录
如，某人买了一张彩票，里面有两组号码，第二组为010508091523，假设这一组系统分配的id为12，则存为：
12,010508091523

同时，建立反向索引，类似全文检索技术(比如你就可以使用全文检索产品来完成这个功能)：
01->12, [其他的彩票组]
08->12, [其他的彩票组]
...
23->12, [其他的彩票组]
这样形成了01,...,31到对应彩票和组的关系

利用全文检索的原理去检索，就能很快得到答案了，不管是多少海量的数据。

[这种情况，一般不会存放一个数据库，而是每个地区/县/范围分配一个数据库，保证每个数据库数据量不大，
然后直接使用sql进行匹配计算，就不必使用倒排序的算法了]

[而是每个地区/县/范围分配一个数据库，保证每个数据库数据量不大]
这一点,由于我这边的彩票全部是采取网上销售的,不像双色彩这样的彩票,只能用一个数据库,所以在这方面的性能检索有很大的问题,如果采用反向索引?先试试看的,谢了

可以试着把两进制 结果 放到数据库中 （。。矩阵一样）
。。。以减少一定的数据量。。。

id  message 01 02 03 。。。验证
 1  010203  1   1  1 。。。7
 2  0203    0   1  1 。。。4
 3  03      0   0  1 。。。1

挺好，这样每组中奖号码 亦可转为 只有一个二进制的号码
不仅仅降低了数据量 更重要的是 降低了计算中奖的计算量

同时
使用二进制这种设计，反向索引的必要性看起来不是很有必要
只要select id from 这个一亿数据量的表 where 二进制的号码=二进制中奖号码

但是注意，是否对“二进制号码”这字段进行索引，有待考虑

针对这个问题,有过类似经验的朋友,有没有成熟的解决方案的