今天有朋友在群里贴了这么一个网址:http://xiemi.unnoo.com/
说是密码泄漏很多。然后查了一下,靠。还真TMD泄漏了一两个。国内这些论坛、网站,怎么这么没有节操呢。怎么都TMD明文存密码呢。真TMD不要脸 .。。
这个网站申明说:
XML/HTML代码
- 声明:泄密库发布目的是让用户能通过多种方式查询自己的密码、隐私是否泄露。泄密库内容源于互联网,非泄密库主动采集。泄密库不对数据的真实性和有效性负责。泄密库不会记录用户信息。泄密库的数据库经过模糊化处理,请勿拖库。
其实这些人都不是好东西。NND,你知道了就知道呗,宣扬干嘛呢?哎。怪不得我现在越来越不想在国内的网站混日 子了。所以现在几乎我在国内的网站的密码都一样。随便你们折腾 .。。不关我事了
在群里突然看到一段代码:
XML/HTML代码
- package main
-
- import (
- "fmt"
- )
-
- var DomainId int
-
- func init() {
- DomainId, err := GetDomainId()
- if err != nil {
- DomainId = -1
- }
- fmt.Println(DomainId)
- }
-
- func GetDomainId() (int, error) {
- DomainId = 1
- return DomainId, nil
- }
注意看红色背景的一条,理论上这段代码没有错,但事实上会报错了。
XML/HTML代码
- [上海]Asta谢() 22:29:50
- 我知道
- [上海]Asta谢() 22:29:55
- 我踩过这个坑
- [上海]Asta谢() 22:30:04
- init里面不能用:=
所以,上面的代码应该是写成:
XML/HTML代码
- func init() {
- var err error
- DomainId, err = GetDomainId()
- if err != nil {
- DomainId=-1
- }
- }
对比两段红色背景的代码。主要是做个笔记 .怕会忘 .
Asta谢 是谁?看这里:https://github.com/astaxie/build-web-application-with-golang ,这里有一篇他的教程,适合广大人民群众查看
2013年就这样的来了,没在去年12月底的时候消失。所以日 子还是得一天天的过。
去年一年时间里,蛋疼了很多次。也越来越发现自己的身体日趋向下,缺乏锻炼经常 加班,导致身体无比虚弱
所以告诉自己,2013年:
1、在年底前,彻底转职,不再专职写程序
2、要锻炼身体,身体倍棒,吃嘛嘛香,不象现在,脸部肌肉都功能性紊乱了。
3、写一个图片管理程序,尽量以功能为主。不再是单文件版了。考虑到后期为加插件,所以最近正在筹划中
4、和bopo商讨的某程序会上线。
其他的不多说了。可能考虑会和一哥们开个茶叶店吧。如果有哥们想喝铁观音或者其他之类的茶叶,倒是可以找我。哥们的媳妇是福建人,黑黑
其实gist功能早就见过了。类似功能的网站也非常多,但那些是不要注册 的。不过github这个gist嘛,注册了也有好处。自己把自己曾经写过的代码,还算好的代码,或者有想法的代码缓存下来。对自己以后 回顾的时候也有好处。
毕竟存在自己的电脑上也容易丢掉。这样多了一个碎片的管理,多少也有点好处。
比如,我就有这样一段:
PHP代码
- <?php
-
- $str = "101|1;0|4;1|0;0|0;0|0";
-
-
-
- $array = explode(';', $str);
-
- $items = array();
-
- foreach ($array as $v) {
-
- list($k, $v) = explode('|', $v);
-
- if (emptyempty($v)) {
-
- continue;
-
- }
-
- $items[$v] = $k;
-
- }
-
- echo "<pre>";
-
- print_r($items);
-
- echo "</pre>";
-
-
-
- parse_str(preg_replace(array('/\d+\|0/','/;/','/\|/'),array("","&","="),$str),$result);
-
- echo "<pre>";
-
- print_r($result);
-
- echo "</pre>";
看上去有点乱。不过。。。到:https://gist.github.com/4405542看就好很多了。。
我看看在代码里能不能引用:
这是昨天SAE分享的一篇文章,开始的时候,我看了一遍,发现好象没有什么特别的内容,但再仔细看的时候,发现居然可以这样做。。。
问题描述:
我们要访问的表是一个非常大的表,四千万条记录,id是主键,program_id上建了索引。
执行一条SQL:
select * from program_access_log where program_id between 1 and 4000
这条SQL非常慢。我们原以为处理记录太多的原因,所以加了id限制,一次只读五十万条记录
select * from program_access_log where id between 1 and 500000 and program_id between 1 and 4000
但是这条SQL仍然很慢,速度比上面一条几乎没有提升。Mysql处理50万条记录的表,条件字段还建了索引,这条语句应该是瞬间完成的。
问题分析:
这张表大约容量30G,数据库服务器内存16G,无法一次载入。就是这个造成了问题。
这条SQL有两个条件,ID一到五十万和Program_id一到四千,因为program_id范围小得多,mysql选择它做为主要索引。
先通过索引文件找出了所有program_id在1到4000范围里所有的id,这个过程非常快。
接下来要通过这些id找出表里的记录,由于这些id是离散的,所以mysql对这个表的访问不是顺序读取。
而这个表又非常大,无法一次装入内存,所以每访问一条记录mysql都要重新在磁盘上定位并把附近的记录都载入内存,大量的IO操作导致了速度的下降。
问题解决方案:
1. 以program_id为条件对表进行分区
2. 分表处理,每张表的大小不超过内存的大小
然而,服务器用的是mysql5.0,不支持分区,而且这个表是公共表,无法在不影响其它项目的条件下修改表的结构。所以我们采取了第三种办法:
select * from program_access_log where id between 1 and 500000 and program_id between 1 and 15000000
现在program_id的范围远大于id的范围,id被当做主要索引进行查找,由于id是主键,所以查找的是连续50万条记录,速度和访问一个50万条记录的表基本一样
总结:
这是一个在千万笔记录表中由于使用了索引导致了数据查找变慢的问题,有一定的典型性和大家交流下!
-----------
看我标红的那一段,原来还能够这样做,以前真的没有注意过,也从来没有想过,先利用主键做一次过滤。这样效率会好很多啊
上述内容来自:http://ourmysql.com/archives/108?f=wb,该网站还有很多技巧值得一看。