手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜Qcloud , 注册 | 登陆
浏览模式: 标准 | 列表2008年12月的文章

年终总结

这篇日志被加密了,请输入密码后查看。

好图

看到好图不敢独享,是QQ里,其他好友当表情发来的。
于是发在博客上,也算是祝福新年

大小: 773.7 K
尺寸: 256 x 256
浏览: 874 次
点击打开新窗口浏览全图

顺便说一下,晚上写年终总结

Tags: 元旦, 快乐, 新年, 2009

PR值普降

PR值的升降与alexa的排名无关。听说今天是更新了PR值,立马冲上来查看了一下,发现phpoo.com升为2,neatstudio.com从5降为4,其他的没变。仍然保持原样。由于PR其实是衡量多少人愿意将他们的网站和你的网站挂钩的指标,所以对于它的变化,我还是相对比较关心的。当然还有alexa的排名。

此次,据说唯一一个国内没有降权,而且始终保持为PR=10的网站,就是信产部的网站,牛叉,极其的牛叉。

对我来说,我仍然会继续保持我的更新。当然我可能会更多的使用一些工具来优化一下站点。听说和一些与本站内容无关的网站进行互联会降低PR值 ,不知道是否真有此事。听说而已。。。

我每天都在看yahoo的网站分析 ,也会经常查看一些关键字。所以有时候会有针对的多添加此类的文章。但是不知道是出于什么原因,我的网站在百度上只有一条记录(传说中的被 K ?)或许吧。。。

随意喽。。。呵呵,即使这样,还是有人能够通过百度搜索到我的网站,太有意思了

Tags: pr, google, alexa

莫让 KPI 成为"作恶"诱因

KPI(Key Performance Indicators),目前大多用于公司中某一个部门的业绩考核,当然我们公司也不例外,还是从多方面进行了考核哦。记得发生过其中的一些笑话,KPI考核中有个员工满意度,有一次,KPI考核分好象还不错(因为公司业绩还行嘛),但是员工满意度很低,某些人就说了,员工满意度很低呀,那就少发点奖金了。我靠,这不是刺激别人将员工满意度等打满分吗?如果打满分他会不会又说,既然大家都满意,那我们也不需要发奖金了?

附上在DBA notes里的,就是本文标题的一篇博客:

年底了,受到的垃圾骚扰信息也多,到处都在搞年底业绩大跃进,什么中奖活动、折扣信息...... 眼看着元旦还有几天,最后的疯狂不能错过。

和朋友讨论类似的现象,都认为是 KPI (Key Performance Indicators) 惹得祸,完全以 KPI 为导向的团队,要想成员不作恶是不可能的。为完成小团体的业绩,管他什么企业价值观什么使命感,都是狗屁!赶紧把相关指标搞定,年底好分奖金才是真格的。

国内某些企业的败局,有些案例的导火索就是某些追求业绩的中层捅出的篓子。所谓"风起于青萍之末",未尝没有道理。

或许用企业价值观强行对 KPI 进行干预是一种办法 ? 可操作性还是个问题。

Don't be evil ! 与君共勉!

--EOF--

原文:http://www.dbanotes.net/review/kpi_evil.html

备注:该篇博客的下一篇中还有提到KPI和PV的关系 哦。。。黑黑,这点,我就不多谈了,不接触也没有什么好谈的。人嘛。。。懂的喽

Tags: kpi, 转摘, 小团体, 感慨

MYSQL中EXPLAIN的说明

EXPLAIN列的解释:

  • table:显示这一行的数据是关于哪张表的
  • type:这是重要的列,显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALL
  • possible_keys:显示可能应用在这张表中的索引。如果为空,没有可能的索引。可以为相关的域从WHERE语句中选择一个合适的语句
  • key:实际使用的索引。如果为NULL,则没有使用索引。很少的情况下,MYSQL会选择优化不足的索引。这种情况下,可以在SELECT语句 中使用USE INDEX(indexname)来强制使用一个索引或者用IGNORE INDEX(indexname)来强制MYSQL忽略索引
  • key_len:使用的索引的长度。在不损失精确性的情况下,长度越短越好
  • ref:显示索引的哪一列被使用了,如果可能的话,是一个常数
  • rows:MYSQL认为必须检查的用来返回请求数据的行数
  • Extra:关于MYSQL如何解析查询的额外信息。将在表4.3中讨论,但这里可以看到的坏的例子是Using temporary和Using filesort,意思MYSQL根本不能使用索引,结果是检索会很慢

extra列返回的描述的意义

  • Distinct:一旦MYSQL找到了与行相联合匹配的行,就不再搜索了
  • Not exists: MYSQL优化了LEFT JOIN,一旦它找到了匹配LEFT JOIN标准的行,就不再搜索了
  • Range checked for each Record(index map:#):没有找到理想的索引,因此对于从前面表中来的每一个行组合,MYSQL检查使用哪个索引,并用它来从表中返回行。这是使用索引的最慢的连接之一
  • Using filesort: 看到这个的时候,查询就需要优化了。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行
  • Using index: 列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的,这发生在对表的全部的请求列都是同一个索引的部分的时候
  • Using temporary 看到这个的时候,查询需要优化了。这里,MYSQL需要创建一个临时表来存储结果,这通常发生在对不同的列集进行ORDER BY上,而不是GROUP BY上
  • Where used 使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行,并且连接类型ALL或index,这就会发生,或者是查询有问题不同连接类型的解释(按照效率高低的顺序排序)
  • system 表只有一行:system表。这是const连接类型的特殊情况
  • const:表中的一个记录的最大值能够匹配这个查询(索引可以是主键或惟一索引)。因为只有一行,这个值实际就是常数,因为MYSQL先读这个值然后把它当做常数来对待
  • eq_ref:在连接中,MYSQL在查询时,从前面的表中,对每一个记录的联合都从表中读取一个记录,它在查询使用了索引为主键或惟一键的全部时使用
  • ref:这个连接类型只有在查询使用了不是惟一或主键的键或者是这些类型的部分(比如,利用最左边前缀)时发生。对于之前的表的每一个行联合,全部记录都将从表中读出。这个类型严重依赖于根据索引匹配的记录多少—越少越好
  • range:这个连接类型使用索引返回一个范围中的行,比如使用>或<查找东西时发生的情况
  • index: 这个连接类型对前面的表中的每一个记录联合进行完全扫描(比ALL更好,因为索引一般小于表数据)
  • ALL:这个连接类型对于前面的每一个记录联合进行完全扫描,这一般比较糟糕,应该尽量避免

Tags: mysql, database, explain

Records:7512345678910»