这是一个创建于 5121 天前的主题，其中的信息可能已经有所发展或是发生改变。
密码泄漏搜索工具，用于在5个已泄漏的数据库里综合搜索数据。
目前已经支持的5个数据库：CSDN, 7k7k, 人人, 嘟嘟牛, 多玩。虽然网上能下到猫扑的数据，但是实际压缩包是损坏的，所以在这里就先不支持了。
关键字长度要超过6位，同时只接受字母，数字以及点(.)，下划线(_)，AT(@)。
此工具仅提供7天，7天后关闭提交。如果还有未完成的搜索则等待搜索完成后彻底关闭。
http://vsean.net/blog/post/98
目前已经支持的5个数据库：CSDN, 7k7k, 人人, 嘟嘟牛, 多玩。虽然网上能下到猫扑的数据，但是实际压缩包是损坏的，所以在这里就先不支持了。
关键字长度要超过6位，同时只接受字母，数字以及点(.)，下划线(_)，AT(@)。
此工具仅提供7天，7天后关闭提交。如果还有未完成的搜索则等待搜索完成后彻底关闭。
http://vsean.net/blog/post/98
 | 1 evlos 2011-12-23 02:59:05 +08:00 。。。关键字要6位 。。。。我账号才5位。。。。 |
 | 3 vibbow OP 补充说明：不知道由于什么原因，我自己测试往QQ邮箱发信收不到，因此大家尽量用国外的邮箱收信吧。 |
| 4 vibbow OP 我了个去，发现一个严峻的问题：现在性能瓶颈居然不是硬盘，而是CPU... |
| 5 vibbow OP 因为修改代码时失误，导致给8位用户（应该都是v2ex的吧）发送了一封垃圾邮件，在此表示抱歉。 |
 | 6 carry 2011-12-23 10:16:16 +08:00 大恩不言谢 创意主很精通搜索吗 |
| 7 vibbow OP @carry 完全不精通搜索，服务端都是用PHP写的，先全部转小写然后用strstr比较... 要不然效率也不至于这么低了... |
| 8 vibbow OP 哈，用Process Explorer看了下服务器的运行状况，硬盘今天爽high了～ |
| 9 vibbow OP |
 | 10 delectate 2011-12-23 18:43:38 +08:00 win的服务器？这么大的数据库，还是grep等给力，既支持正则，速度又快。 |
| 12 vibbow OP 擦...服务器开始自动备份了...速度瞬间降低... |
| 13 vibbow OP 怎么优化都是4分钟，应该是到strstr函数的极限了... |
| 14 delectate 2011-12-23 19:47:31 +08:00 瓶颈。想想顺序读取1g的数据还要很久时间呢。 |
| 16 delectate 2011-12-23 20:09:19 +08:00 只是那很轻松的，问题是还要匹配。正则的引擎差一点就慢很多。反正不大，都放内存里速度能加倍；或者优化一下数据库，别简单的 cat *> database就拿去用…… |
| 17 vibbow OP 因为国内的服务器在搜索完成后回调国外的服务器失败（这个时段，你懂的…），所以之前给一些用户发送了可能错误的“搜索结果为空”email。因为我也不确定具体什么时间开始失败的，所以我按照缓存的记录，给之前所有搜索结果为空的用户重新搜索并且发送了邮件。 在此对再次收到我“垃圾邮件”的用户表示抱歉。 |
| 18 vibbow OP 继续优化了代码，全文搜索时间从4分多钟降到了2分钟，同时添加上了mop的库（虽然感觉这个库很奇怪，很假...） |
 | 19 liruqi 2011-12-24 08:54:56 +08:00 via Android 直接导入到 mongodb 或者 mysql 加索引啊。为啥要自己写查询呢。 |
 | 22 laiwei 2011-12-24 15:40:59 +08:00 你不想搞mysql的话，你搞个sqlite存起来，建个索引，比你这样strstr快多了。 |
| 23 vibbow OP @laiwei sqlite索引不行啊，如果关键字是从中间开始查那么一点效果都没有啊。目前在缓慢的用mysql给csdn库加全文索引中... |
| 25 vibbow OP 可是建完全文索引后貌似不能同时查多个关键字了... 不可以用 SELECT * FROM password WHERE keyword LIKE IN ('%keyword1%', '%keyword2%); 或者有其他sql语句可以用？ |
| 26 vibbow OP 好吧，貌似这样来速度也可以： SELECT * FROM password WHERE keyword LIKE '%keyword1%' OR keyword LIKE '%keyword2%'; |
| 27 liruqi 2011-12-24 16:38:17 +08:00 其实一般自己的id 都能准确记住的，没有必要用 like 做匹配。反而是恶意查询才有这种需求吧。 建议直接用id 做精确匹配。 |
| 28 vibbow OP @liruqi 就我这服务器速度，再加上还限制了并发数量，想批量恶意查询还不如自己把数据库下下来快... 一般查询，随他们去了。 |
| 29 vibbow OP 蛋疼了。加上17173的数据，总共有8千多万条数据，我觉得没个两三天是建立不完索引的了... 算了，还是继续文本搜索吧... |
| 30 delectate 2011-12-24 21:25:07 +08:00 用sed或者awk剔除重复的啊 |
Select Language