Archive for the ‘Code’ Category

Must Read: Understanding Javascript OOP


08 3月
http://killdream.github.com/blog/2011/10/understanding-javascript-oop

「轉」如何学好C++语言


01 8月

by 陈皓 http://coolshell.cn/articles/4119.html

昨天写了一篇如何学好C语言,就有人回复问我如何学好C++,所以,我把我个人的一些学习经验写在这里,希望对大家有用。首先,因为如何学好C语言中谈到了算法和系统,所以这里就只谈C++语言。
  • C++是最难的语言。这个世界上最难的编程语言可能非C++莫属了。你千万不要以为几天就可以学好C++,C++的学习曲线是相当BT的,你可以看看这篇文章。C++是一门很自由的语言,自由到了有点BT和恐怖的地步。我甚至认为C++并不是一门成熟的编程语言,因为太容易犯错了。所以,你一定要在一开始就要有很小心谨慎的态度,并把C++当成一种难以训服的猛兽来看待
  • 多问“为什么要这样”的问题。学习C++一定要多问几个“为什么是这样”,“凭什么要这样”的问题。比如:很多人知道C++有拷贝构造函数和初始化列表,但你真的知道为什么要有拷贝构造函数?为什么要有初始化列表吗?为什么要有template,为什么要有RTTI,为什么不是别的呢?难道就是为了让一门语言变得Cool一些吗?完全不是这样的,C++中的任何一个feature都有些实实在在的原因,你一定要去了解为什么要把C++设计成这样的原因,你才能学好C++。有空看看《C++演化和设计》一书。
 
  • 看书,大量的C++书。你可以按如下先后顺序阅读(下面这些书,我花了大约4-5年的时间,今天我还在随时温习)
    • C++ Primer》,这本初级读本可能让会你啃得很痛苦,所有的语言的特性和为什么都在里面了,好好读读。当然由C++之父写的《C++程序设计语言》也不错。两本看一本就好了(我看的是前者)。
    • 了解C++的语法仅仅是万里长征的第一步,你还需要看看《Effective C++》和《More Effective C++》这两本书并不厚,但我从02年就一直看到现在,每次读我都有新的体会,这两本书太经典了。如果你对C语言不熟,这两本书会让你回去补C语言的课。
    • Think in C++同样是另一本经典之极的书,学c++必读,但是中文版的翻译的很不好,所以还是去读英文版的吧。
    • C++沉思录》同样非常值得一读,这里教的不是编程,而是思考的方法,这是相当珍贵的。
    • Exceptional C++》和《More Exceptional C++》让你看看各种问题的解决方法和一些常见的经典错误。
    • Advanced C++》和《Modern C++》可以让你知道C++各种神奇的用法。
    • 泛型编程与STL》是把C++实践到了极致的东西。很强大。STL——神一样的模板库(容器,算法和函数对象),不得不服。
    • 深入探索C++对象模型》让你了解编译器下的C++是什么样的,让你了解C++的性能并不差。这个对于C++的程序员太关键了。我以前写过的《C++虚函数表解析》还有《C++对象内存布局》属于这个范畴。
  • 和Java语言做对比。我个人以为Java对C++这个并不成熟的语言做了很多调整,规范和限制。所以,对比一下Java和C++,想一想,为什么一些东西在C++中可以做,但在Java中却不行。比如:Java的异常是必需要catch的,不然就会编译不通过。为什么Java不提供操作符重载?为什么Java会引入接口来做多重继承?为什么Java没有像C++那样的I/O字符流?为什么Java不支持指针?为什么Java可以做到垃圾回收?等等。Java体现着很多面向对象设计的东西,学习Java有助于你学会怎么更好地使用C++来编程
  • 面向对象设计 。虽然面向对象可能是个骗局。但是我觉得面向对象设计中的一些实践非常的不错,比如,单一原则,依赖倒置原则,等等,都非常地经典。《设计模式》必需一读,《面向对象的分析和设计》可以一读。但不可以设计模式为中心来编程,而应该是用设计模式来解藕
  • 类库学习。看看MFC是怎么封装Windows API的,看看ACE是怎么面向对象的,看看boost是怎么玩面向对象的,看看CPPUnit又是怎么设计的。当然,Java的JDK中有太多的设计模式,可以参考。
希望没有吓到大家,并欢迎大家补充。 —————更新 2011/03/30 19:20———— 更新几个观点:
  • 1)我不擅长写书评,所以推荐的这些书可能会让你有点看点没有感觉,你可以上豆瓣或是China-pub上看看书评。
  • 2)C++有很多奇淫技巧,有的很BT,包括虚函数表,也许会有人觉得有点没意思,但我觉得很有意思,一方面可以了解一门语言的实现细节,另一方面可以开阔思路。我从学习这些知识中受益很多。
  • 3)上述是我的个人的学习历程,我觉得对我很有效,所以是经验之谈。
  • 4)这类的文章在网上有很多很多,我不是第一个写这样的文章,我也不是写得最好的,我并不希望用长篇大论来谈论什么。只是想给大家了解一下大概的学习样子。毕竟,C++博大精深,任何一篇文章都无法说好。不如就简单一些。

「轉」如何学好C语言


01 8月

by 陈皓 http://coolshell.cn/articles/4102.html

 
有人在酷壳的留言版上询问下面的问题
keep_walker : 今天晚上我看到这篇文章。 http://programmers.stackexchange.com/questions/62502/small-c-projects 我也遇到了和提问的老外一样的问题。。能给像遇到这样烦恼的程序员一点建议嘛?谢谢!
我相信,这可能是很多朋友的问题,我以前也有这样的感觉,编程编到一定的时候,发现能力到了瓶颈,既不深,也不扎实,半吊子。比如:你长期地使用Java和.NET ,这些有虚拟机的语言对于开发便利是便利,但是对于程序员来说可能并不太好,原因有两个:
  1. 虚拟机屏蔽了操作系统的系统调用,以及很多底层机制。
  2. 大量的封装好的类库也屏蔽了很多实现细节。
一段时间后,你会发现你知其然,不知所以然。。我以前在CSDN上写过一篇《Java NIO类库Selector机制解析(》,在那篇文章中我说提到过(有讥讽的语气)Java的程序员不懂底层实现,所以很难把技术学得更扎实。此时,一部分程序员会不自然地想学学底层的技术,很自然的,C语言就被提了上来。 下面是我给这位朋友的一些建议:  
  • 鼓励并为你叫好。我鼓励你想要去学C语言的想法和精神,很多人都觉得C语言好学,其实并不然。(你可以看看《C语言的迷题》)现在的这个社会更多地去关注那些时髦的技术,而忽略了这个流行了40+年的C语言。一门技术如果能够流行40多年,这才是你需要去关注和学习的技术,而不是那些刚出来的技术(过度炒作的技术Windows编程史)。这才是踏踏实实的精神。
  • 不要找借口。这一条路走下来并不容易,不要给自己找借口。我最不喜欢听到的就是“很忙,没有时间”这样的借口。我以前在银行做项目,早9点到晚10点,周一到周六,我一样可以每天抽1个小时来看书和专研,一年下来也能精读5、6本书。我现在的工作项目和招聘任务很紧张,刚生的小孩只有自己和老婆两人带,还需要准备讲课,但是我还是能够找到时间看文章写文章维护酷壳。所以,我可以告诉你,“时间就像乳沟,只要你肯挤,就一定会有”。
如果你能在2-3年内精读完这些书,并全部融会贯通,那么你就明白什么是一览众山小的感觉了!我足足花了5年时间才算是真正全部读完这些书的。最后,祝你好运!努力! ——-更新:2011/03/29 20:00——- 我想,这篇文章主要想告诉大家这么几件事:
  • 编程编到一定时候,你就需要了解底层系统的机制,否则,知其然不知所以然。
  • 我没有否定非C的程序员的逻辑,真正的逻辑是——如果你想要了解底层机制,请学习C语言和操作系统。
  • 40多年的Unix/C影响深远。包括影响了Windows。如果你想一通百通,一定要了解Unix。那是计算机文化真正的根。
  • 不要肤浅地去思考问题。比如,不要以为一个DBA就不会考虑数据库引擎的内存页面的问题。也不要以为Web程序员就不需要了解后台的服务器和脚本的运行性能以及TCP/IP的问题。
高手往往都是有很强的系统的基础知识的,表面的东西永远是肤浅的。

【转】Mysql Explain 详解


18 7月
from IT技术博客大学习 by phpor
explain显示了mysql如何使用索引来处理select语句以及连接表。可以帮助选择更好的索引和写出更优化的查询语句。
使用方法,在select语句前加上explain就可以了:
如:explain select * from test1
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:这个连接类型对于前面的每一个记录联合进行完全扫描,这一般比较糟糕,应该尽量避免
Mysql 的执行计划from IT技术博客大学习 by phpor1 person liked this - you标签:  explain mysql的执行计划: explain显示了mysql如何使用索引来处理select语句以及连接表。可以帮助选择更好的索引和写出更优化的查询语句。 使用方法,在select语句前加上explain就可以了: 如:explain select * from test1 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:这个连接类型对于前面的每一个记录联合进行完全扫描,这一般比较糟糕,应该尽量避免

【转】New MooTools Methods: .from()


22 6月
Full David Walsh Blog Post: New MooTools Methods: .from() MooTools 1.3 beta 2 was recently released and you may see a few new methods implemented to String, Array, Number, and Function: from. The from method of each of those Types returns an object of that type. Simply put: you’ll always receive back an object of that type based on what you give it.

The New Method Code

Function.from = function(item){
	return (typeOf(item) == 'function') ? item : function(){
		return item;
	};
};

Array.from = function(item){
	if (item == null) return [];
	return (Type.isEnumerable(item) && typeof item != 'string') ? (typeOf(item) == 'array') ? item : Array.prototype.slice.call(item) : [item];
};

Number.from = function(item){
	var number = parseFloat(item);
	return isFinite(number) ? number : null;
};

String.from = function(item){
	return item + '';
};
The from method is added to String, Array, Number, and Function natives. Enough with the underlying code though — examples are easier to understand.

Function.from, Array.from, Number.from, String.from Examples

Array.from('Item');
//returns ['Item'] (array type)

Function.from('Item, Whoa, Hey');
//returns function() { return 'Item, Whoa', Hey'; } (function type)

String.from(function() { alert('MooTools FTW!'); });
//returns function () { alert("MooTools FTW!"); } (string type)

Number.from('8765309');
//returns 8765309 (number type)
Each example above shows you what’s returned by each method. Being able to generate a given object type from any argument using from can save you a lot of time — especially when a given MooTools class or method requires an argument of a specific type. from is just another example of how MooTools can make your JavaScript life easier!

【转】HTML 5 令人期待的 5 项功能


21 6月
HTML 5 是超文本置标语言下一个重要版本,HTML 自1999年发布 HTML 4.01 以来,其开发一直处于停顿状态,而1999年至今正好是 Web 飞速发展的时间,现在的 HTML 版本已经无法适应现在的 Web 内容与应用。HTML 5 旨在提高 HTML 的交互行,支持当前多样的,复杂的 Web 内容。同时,它也会解决 HTML 4 Web 应用功能上的欠缺。

一点历史背景

HTML 5 的讨论开始于2003年,当时,W3C 对由 Web Hypertext Application Technology Working Group(WHATWG) 开发的 HTML 5 草案表示出兴趣,WHATWG 创始于2004年,由苹果,Mozilla 基金会,以及 Opera 公司的 代表组成。此后,W3C HTML Working Group 于2007年成立并着手开发 HTML 5。目前,开发工作仍在进行中,并将于2012年向 W3C 提交初步意见,不过现在已经有不少浏览器部分支持 HTML 5。本文介绍 HTML 5 的5大令人激动的新功能。

1. 一些帮助我们描述内容的新标签

Web 内容的多样性让 HTML4 力不从心,在描述一个网页时,HTML4 如下 表现: HTML 5 将如下表现: 这样,浏览器就知道一个网页的各个部分各代表什么,比如 <nav> 部分是导航,而 <article> 部分是主要内容 。除了更漂亮的 代码与语义标签,这种改变还带来更多好处,比如,搜索引擎可以更准确地知道一个网页的哪部分内容更重要。关于 HTML 5 新标签,IBM有详细的论述

2. 改进的 Web 表单处理

HTML 5 推出 Web Forms 2.0,为开发提供许多新选项和新功能,以更简单更有效地处理表单的输入与发布。Web Form 2.0 最令人兴奋的功能是输入验证。目前,我们需要通过 JavaScript 或服务器端的逻辑,实现同样的功能。 比如有下面这样一个表单: 在 HTML4 我们需要这样写代码,然后使用 JavaScript 或服务器端的脚本进行验证: 而 HTML5 中的  required 与 email 属性可以直接实现验证,如下:

3. 为 Web 开发提供 API

HTML 5 将提供多个 API,如音频和 视频标签可以让开发者不借助第三方工具直接播放 Web 视频和音频: Opera 在者方面有不少研究并有视频播放 demo 推出

4. <canvas>标签将允许直接在上面用脚本绘图

人更容易从图片获得信息,如,下面的信息通过表格和圆饼图两种方式显示,效果明显不一样: 然而以往要实现这种效果,只能使用静态图片,无法对图片进行调整。使用 <canvas> 标签,你可以实时修改参数对图形进行修改,比如,根据用户的投票,实时生成圆饼图。

5. 用户可以编辑网页的部分内容并实现同网页的交互

HTML 5 将支持用户的交互contenteditable属性允许你设定网页的哪一部分可以编辑,在基于 Wiki 的 站点,这非常实用。 转自:http://www.comsharp.com/GetKnowledge/zh-CN/It_News_K667.aspx

【转】javascript call apply区别


08 6月
JavaScript中有一个call和apply方法,其作用基本相同,但也有略微的区别。 先来看看JS手册中对call的解释:
call 方法 调用一个对象的一个方法,以另一个对象替换当前对象。 call([thisObj[,arg1[, arg2[,   [,.argN]]]]]) 参数 thisObj 可选项。将被用作当前对象的对象。 arg1, arg2,  , argN 可选项。将被传递方法参数序列。 说明 call 方法可以用来代替另一个对象调用一个方法。call 方法可将一个函数的对象上下文从初始的上下文改变为由 thisObj 指定的新对象。 如果没有提供 thisObj 参数,那么 Global 对象被用作 thisObj。
说明白一点其实就是更改对象的内部指针,即改变对象的this指向的内容。这在面向对象的js编程过程中有时是很有用的。 引用网上一个代码段,运行后自然就明白其道理。
<input type="text" id="myText"   value="input text"> <script>     function Obj(){this.value="对象!";}     var value="global 变量";     function Fun1(){alert(this.value);}     window.Fun1();   //global 变量     Fun1.call(window);  //global 变量     Fun1.call(document.getElementById('myText'));  //input text     Fun1.call(new Obj());   //对象! </script>
call函数和apply方法的第一个参数都是要传入给当前对象的对象,及函数内部的this。后面的参数都是传递给当前对象的参数。 运行如下代码:
<script>    var func=new function(){this.a="func"}     var myfunc=function(x){         var a="myfunc";         alert(this.a);         alert(x);     }     myfunc.call(func,"var"); </script>
可见分别弹出了func和var。到这里就对call的每个参数的意义有所了解了。 对于apply和call两者在作用上是相同的,但两者在参数上有区别的。 对于第一个参数意义都一样,但对第二个参数: apply传入的是一个参数数组,也就是将多个参数组合成为一个数组传入,而call则作为call的参数传入(从第二个参数开始)。 如 func.call(func1,var1,var2,var3)对应的apply写法为:func.apply(func1,[var1,var2,var3]) 同时使用apply的好处是可以直接将当前函数的arguments对象作为apply的第二个参数传入

【转】mysql sql 百万级数据库优化方案


08 6月
via IT技术博客大学习 by achao on 6/2/10
1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。 2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: select id from t where num is null 可以在num上设置默认值0,确保表中num列没有null值,然后这样查询: select id from t where num=0 3.应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描。 4.应尽量避免在 where 子句中使用 or 来连接条件,否则将导致引擎放弃使用索引而进行全表扫描,如: select id from t where num=10 or num=20 可以这样查询: select id from t where num=10 union all select id from t where num=20 5.in 和 not in 也要慎用,否则会导致全表扫描,如: select id from t where num in(1,2,3) 对于连续的数值,能用 between 就不要用 in 了: select id from t where num between 1 and 3 6.下面的查询也将导致全表扫描: select id from t where name like ‘%abc%’ 若要提高效率,可以考虑全文检索。 7.如果在 where 子句中使用参数,也会导致全表扫描。因为SQL只有在运行时才会解析局部变量,但优化程序不能将访问计划的选择推迟到运行时;它必须在编译时进行选择。然而,如果在编译时建立访问计划,变量的值还是未知的,因而无法作为索引选择的输入项。如下面语句将进行全表扫描: select id from t where num=@num <mailto:num=@num> 可以改为强制查询使用索引: select id from t with(index(索引名)) where num=@num <mailto:num=@num> 8.应尽量避免在 where 子句中对字段进行表达式操作,这将导致引擎放弃使用索引而进行全表扫描。如: select id from t where num/2=100 应改为: select id from t where num=100*2 9.应尽量避免在where子句中对字段进行函数操作,这将导致引擎放弃使用索引而进行全表扫描。如: select id from t where substring(name,1,3)=’abc’-name以abc开头的id select id from t where datediff(day,createdate,’2005-11-30′)=0-‘2005-11-30’生成的id 应改为: select id from t where name like ‘abc%’ select id from t where createdate>=’2005-11-30′ and createdate<’2005-12-1′ 10.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算,否则系统将可能无法正确使用索引。 11.在使用索引字段作为条件时,如果该索引是复合索引,那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引,否则该索引将不会被使用,并且应尽可能的让字段顺序与索引顺序相一致。 12.不要写一些没有意义的查询,如需要生成一个空表结构: select col1,col2 into #t from t where 1=0 这类代码不会返回任何结果集,但是会消耗系统资源的,应改成这样: create table #t(…) 13.很多时候用 exists 代替 in 是一个好的选择: select num from a where num in(select num from b) 用下面的语句替换: select num from a where exists(select 1 from b where num=a.num) 14.并不是所有索引对查询都有效,SQL是根据表中数据来进行查询优化的,当索引列有大量数据重复时,SQL查询可能不会去利用索引,如一表中有字段sex,male、female几乎各一半,那么即使在sex上建了索引也对查询效 率起不了作用。 15.索引并不是越多越好,索引固然可以提高相应的 select 的效率,但同时也降低了 insert 及 update 的效率,因为 insert 或 update 时有可能会重建索引,所以怎样建索引需要慎重考虑,视具体情况而定。一个表的索引数最好不要超过6个,若太多则应考虑一些不常使用到的列上建的索引是否有必要。 16.应尽可能的避免更新 clustered 索引数据列,因为 clustered 索引数据列的顺序就是表记录的物理存储顺序,一旦该列值改变将导致整个表记录的顺序的调整,会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列,那么需要考虑是否应将该索引建为 clustered 索引。 17.尽量使用数字型字段,若只含数值信息的字段尽量不要设计为字符型,这会降低查询和连接的性能,并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符,而对于数字型而言只需要比较一次就够了。 18.尽可能的使用 varchar/nvarchar 代替 char/nchar ,因为首先变长字段存储空间小,可以节省存储空间,其次对于查询来说,在一个相对较小的字段内搜索效率显然要高些。 19.任何地方都不要使用 select * from t ,用具体的字段列表代替“*”,不要返回用不到的任何字段。 20.尽量使用表变量来代替临时表。如果表变量包含大量数据,请注意索引非常有限(只有主键索引)。 21.避免频繁创建和删除临时表,以减少系统表资源的消耗。 22.临时表并不是不可使用,适当地使用它们可以使某些例程更有效,例如,当需要重复引用大型表或常用表中的某个数据集时。但是,对于一次性事件,最好使用导出表。 23.在新建临时表时,如果一次性插入数据量很大,那么可以使用 select into 代替 create table,避免造成大量 log ,以提高速度;如果数据量不大,为了缓和系统表的资源,应先create table,然后insert。 24.如果使用到了临时表,在存储过程的最后务必将所有的临时表显式删除,先 truncate table ,然后 drop table ,这样可以避免系统表的较长时间锁定。 25.尽量避免使用游标,因为游标的效率较差,如果游标操作的数据超过1万行,那么就应该考虑改写。 26.使用基于游标的方法或临时表方法之前,应先寻找基于集的解决方案来解决问题,基于集的方法通常更有效。 27.与临时表一样,游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法,尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许,基于游标的方法和基于集的方法都可以尝试一下,看哪一种方法的效果更好。 28.在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ,在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。 29.尽量避免大事务操作,提高系统并发能力。 30.尽量避免向客户端返回大数据量,若数据量过大,应该考虑相应需求是否合理。

SCWS中文分词


20 5月
因为在上一篇文章的末尾提到的,coreseek分词存在的问题,经过详细的测试,比较了原版sphinx和coreseek用同一种配置文件,都不分词索引的情况下,coreseek的速度仍然大幅度落后于原版sphinx,于是决定近期摒弃coreseek,换上原版的sphinx。但这样的话,coreseek提供的mmseg分词在搜索的时候也就无法继续使用了。(当然,除非你愿意2个都装,coreseek另外开端口只为分词服务- -) 基于这种情况,决定另外找一个分词的东东来支持搜索时的调用。使用传说中的Google搜了一下,基本锁定了几个分词的东东。 1. mmseg4j 同样是mmseg的算法,可惜是java版本的,功能上倒是比coreseek出品的那个mmseg要强大,新版本已经支持了max-word的分词方法,也就是“中华人民共和国”会被分成“中华人民 中华 人民 共和国 共和 国”类似这样的,可以说加大了搜索的智能性。 但可惜的是,对于我们这类纯php环境的朋友,要享受这个东东要付出的代价有点大。除了要整套java环境的支持,还要php-java-bridge这类方式的调用,无不让人望而止步啊。尝试了几个小时后,终于放弃抵抗,寻找其他方向去了。 mmseg4j对java的朋友可能会更有用吧,不过它的max-word分词强大程度还有待考量,我在linux下java调用测试的时候,结果也不是太满意,当然可能和词库有关吧,没有继续深究了。 2.ICTCLAS传说中的中科天玑出品,号称xx国际xx分词奖第一名,号称多少多少用户量,反正光环无数啦,虽然有共享版,但如果商用的话,似乎有不菲的费用。张宴自己搞的那套什么分词,也是基于这个东东的,尝试用他官网的demo测试一下,结果服务器链接错误 - -||| 怎么都感觉很有国企的风格啊。。。虽然似乎听起来算法不错,但想到我们最终还是要商用的,基本放弃。 3. SCWS,ftphp出品,ftphp貌似也是个搜索引擎,国人自己弄的?没太了解过反正。不过他的分词是开源的,号称自己是简易免费的分词,本来没抱什么太大希望其实,不过看他官方数据分词速度居然比楼上传说中的xx分词奖第一名的速度还要快。。。于是决定一试。 具体的文档可以参见官网(很详细很强大),下面我自己的一些心得,以备日后查看: 安装没什么花头,看doc的第一节照抄弄就行了,注意版本号换成最新的,然后因为我从来都是utf8的,所以所有gbk的地方替换掉,词库也只用了utf8的。值得注意的是,如果你和我一样要在php中调用的话,建议把php extension那段都做掉,起初我也偷懒想用php的exec去执行命令行就好了,结果比较下来,效率相差2个数量级。。。exec要上百毫秒,而extension只要几毫秒! 而最终xdebug分析下来,用extension的方式分词,比原来coreseek的mmseg也要快了1个数量级,笑~,估计近期就得和coreseek彻底说byebye了。 具体妙用大家自己看吧,maxwords也是支持的,感觉还不错,也可以另外加自己的词典,效率也很高,目前看来很完美。 ————————2010/5/31—————————————— 如果用txt自定义词库的话,第一次运行的时候,scws会自动把它编译成.xdb的格式,放到/tmp中去,也就是说,如果你的词典和我一样很大的话,而php的超时时间设定的又比较小的话,很有可能永远都无法生成出这个词典,也就是说,每次分词都会超时。 所以,建议大家第一次装好后,用命令行运行一下.txt的词库,类似: /usr/local/scws/bin/scws -c utf8 -r /usr/local/scws/etc/rules.utf8.ini -M 1 -i 中华人民共和国南京西路 -d /usr/local/scws/etc/dict.utf8.xdb:/usr/local/scws/etc/words.txt 之后:mv /tmp/scws-193b5b00.xdb /usr/local/scws/etc/ 以后用起来就是直接:  /usr/local/scws/bin/scws -c utf8 -r /usr/local/scws/etc/rules.utf8.ini -M 1 -i 中华人民共和国南京西路 -d /usr/local/scws/etc/dict.utf8.xdb:/usr/local/scws/etc/scws-193b5b00.xdb 这样就算第一次也不会很慢啦~

Sphinx conf infix, Sphinx api total vs total found, quorum match vs extended2 mode


14 5月
最近公司使用sphinx中碰到的一些问题,做下记录。
针对类似搜索“南京”时,无法搜出带有“南京西路”的数据问题的解决方案。
第一步设置相应的.conf文件,修改如下属性:
enable_star = 1 #开启传说中的wildcard syntax模式,详见手册9.2.19. enable_star
min_infix_len  = 1 #设置最短匹配词长,详见手册9.2.16. min_infix_len
infix_fields = estate_name,estate_address #要启用infix的字段,必须填!因为infix会加大开销,如果不填这个字段,会对所有字段做infix,那将是很恐怖的开销!详见手册9.2.18. infix_fields
最后一个参数,手册上没有提到的,如果没有设置正确会对中文造成无解的属性:
charset_table = U+FF10..U+FF19->0..9, 0..9, U+FF41..U+FF5A->a..z, U+FF21..U+FF3A->a..z,\ A..Z->a..z, a..z, U+0149, U+017F, U+0138, U+00DF, U+00FF, U+00C0..U+00D6->U+00E0..U+00F6,\ U+00E0..U+00F6, U+00D8..U+00DE->U+00F8..U+00FE, U+00F8..U+00FE, U+0100->U+0101, U+0101,\ U+0102->U+0103, U+0103, U+0104->U+0105, U+0105, U+0106->U+0107, U+0107, U+0108->U+0109,\ U+0109, U+010A->U+010B, U+010B, U+010C->U+010D, U+010D, U+010E->U+010F, U+010F,\ U+0110->U+0111, U+0111, U+0112->U+0113, U+0113, U+0114->U+0115, U+0115, \ U+0116->U+0117,U+0117, U+0118->U+0119, U+0119, U+011A->U+011B, U+011B, U+011C->U+011D,\ U+011D,U+011E->U+011F, U+011F, U+0130->U+0131, U+0131, U+0132->U+0133, U+0133, \ U+0134->U+0135,U+0135, U+0136->U+0137, U+0137, U+0139->U+013A, U+013A, U+013B->U+013C, \ U+013C,U+013D->U+013E, U+013E, U+013F->U+0140, U+0140, U+0141->U+0142, U+0142, \ U+0143->U+0144,U+0144, U+0145->U+0146, U+0146, U+0147->U+0148, U+0148, U+014A->U+014B, \ U+014B,U+014C->U+014D, U+014D, U+014E->U+014F, U+014F, U+0150->U+0151, U+0151, \ U+0152->U+0153,U+0153, U+0154->U+0155, U+0155, U+0156->U+0157, U+0157, U+0158->U+0159,\ U+0159,U+015A->U+015B, U+015B, U+015C->U+015D, U+015D, U+015E->U+015F, U+015F, \ U+0160->U+0161,U+0161, U+0162->U+0163, U+0163, U+0164->U+0165, U+0165, U+0166->U+0167, \ U+0167,U+0168->U+0169, U+0169, U+016A->U+016B, U+016B, U+016C->U+016D, U+016D, \ U+016E->U+016F,U+016F, U+0170->U+0171, U+0171, U+0172->U+0173, U+0173, U+0174->U+0175,\ U+0175,U+0176->U+0177, U+0177, U+0178->U+00FF, U+00FF, U+0179->U+017A, U+017A, \ U+017B->U+017C,U+017C, U+017D->U+017E, U+017E, U+0410..U+042F->U+0430..U+044F, \ U+0430..U+044F,U+05D0..U+05EA, U+0531..U+0556->U+0561..U+0586, U+0561..U+0587, \ U+0621..U+063A, U+01B9,U+01BF, U+0640..U+064A, U+0660..U+0669, U+066E, U+066F, \ U+0671..U+06D3, U+06F0..U+06FF,U+0904..U+0939, U+0958..U+095F, U+0960..U+0963, \ U+0966..U+096F, U+097B..U+097F,U+0985..U+09B9, U+09CE, U+09DC..U+09E3, U+09E6..U+09EF, \ U+0A05..U+0A39, U+0A59..U+0A5E,U+0A66..U+0A6F, U+0A85..U+0AB9, U+0AE0..U+0AE3, \ U+0AE6..U+0AEF, U+0B05..U+0B39,U+0B5C..U+0B61, U+0B66..U+0B6F, U+0B71, U+0B85..U+0BB9, \ U+0BE6..U+0BF2, U+0C05..U+0C39,U+0C66..U+0C6F, U+0C85..U+0CB9, U+0CDE..U+0CE3, \ U+0CE6..U+0CEF, U+0D05..U+0D39, U+0D60,U+0D61, U+0D66..U+0D6F, U+0D85..U+0DC6, \ U+1900..U+1938, U+1946..U+194F, U+A800..U+A805,U+A807..U+A822, U+0386->U+03B1, \ U+03AC->U+03B1, U+0388->U+03B5, U+03AD->U+03B5,U+0389->U+03B7, U+03AE->U+03B7, \ U+038A->U+03B9, U+0390->U+03B9, U+03AA->U+03B9,U+03AF->U+03B9, U+03CA->U+03B9, \ U+038C->U+03BF, U+03CC->U+03BF, U+038E->U+03C5,U+03AB->U+03C5, U+03B0->U+03C5, \ U+03CB->U+03C5, U+03CD->U+03C5, U+038F->U+03C9,U+03CE->U+03C9, U+03C2->U+03C3, \ U+0391..U+03A1->U+03B1..U+03C1,U+03A3..U+03A9->U+03C3..U+03C9, U+03B1..U+03C1, \ U+03C3..U+03C9, U+0E01..U+0E2E,U+0E30..U+0E3A, U+0E40..U+0E45, U+0E47, U+0E50..U+0E59, \ U+A000..U+A48F, U+4E00..U+9FBF,U+3400..U+4DBF, U+20000..U+2A6DF, U+F900..U+FAFF, \ U+2F800..U+2FA1F, U+2E80..U+2EFF,U+2F00..U+2FDF, U+3100..U+312F, U+31A0..U+31BF, \ U+3040..U+309F, U+30A0..U+30FF,U+31F0..U+31FF, U+AC00..U+D7AF, U+1100..U+11FF, \ U+3130..U+318F, U+A000..U+A48F,U+A490..U+A4CF
额,不要惊慌,照抄就行了,把中文的都包括进去就ok了。
完了后,停掉searchd,重建索引就好。
之后,在搜索的时候,就可以使用类似'*南京*'、'*南京'、'南京*'之类的query,去当类似sql 的like用了,OVER。
——————————我是分割线———————————————— 当我们使用API从sphinx执行了一个查询之后,接口会返回一个数组。在这个数组中存在total_found和total两个值。 当查询出的结果数小于sphin中配置的最大返回结果数(默认为1000)时,这两个值是相等的。 而查询出的结果数大于sphin中配置的最大返回结果数(默认为1000)时,total_found的值是在sphinx中所有满足搜索条件的结果数,而total返回的是sphin中配置的最大返回值。 因此,在分页等需要所有满足搜索条件的结果数的时候,应该使用total_found的值。 ——————————我这个分割线又来了———————————— 在使用@(column1,column2,column3) "关键词1 关键词2 关键词3 关键词4 关键词5 ... 关键词N"/2这种参数的时候,搜索模式应该设置为SPH_MATCH_EXTENDED模式,而不能用传说中效率更高的SPH_MATCH_EXTENDED2模式,否则将会发生不可预料的事情。。。(沿用sphinx官方风格比喻,就是可能屏幕里面跳出来一只大猩猩,对着你仍酒桶。) END P.S. 很多其他sphinx的常见问题在官方FAQ中都有,比如filter中要用or的话,怎么解决,FAQ中就很牛叉。膜拜一下。 ————————————2010/5/18补充—————————————————— 发现上周提出的infix方式与现有分词索引的方式起了比较大的冲突(用了infix就基本无法用分词了),于是顺道回顾了一下张宴大师的博客,发现他原来早碰到过这个问题了。而他的解决方案明显非常不错。直接贴了: 1、一元分词和中文分词的结合:  ①、一元分词位于索引更新模块。Sphinx索引引擎对于CJK(中日韩)语言(必须是UTF-8编码)支持一元切分,假设【反恐行动是国产主视角射击网络游戏】这段文字,Sphinx会将其切成【反 恐 行 动 是 国 产 主 视 角 射 击 网 络 游 戏】,然后对每个字建立反向索引。如果用这句话中包含的字组成一个不存在的词语,例如【恐动】,也会被搜索到,所以搜索时,需要加引号,例如搜索【"反恐行动"】,就能完全匹配连在一起的四个字,不连续的【"恐动"】就不会被搜索到。但是,这样还有一个问题,搜索【"反恐行动游戏"】或【"国产网络游戏"】就会搜索不到。对于这个问题,采用位于搜索查询模块的中文分词来处理。 sphinx.conf配置文件中关于UTF-8中文一元分词的配置如下: ...省略... index t_source_main { source                  = t_source_main path                    = /data0/search/sphinx/data/t_source_main docinfo                 = extern mlock                   = 0 morphology              = none min_word_len            = 1 charset_type            = utf-8 min_prefix_len          = 0 html_strip              = 1 charset_table           = 0..9, A..Z->a..z, _, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F ngram_len               = 1 ngram_chars             = U+3000..U+2FA1F } ...省略... ②、中文分词位于搜索查询模块。搜索“反恐行动游戏”、“国产网络游戏”,先调用独立的中文分词系统,分别切分为“反恐行动 游戏”、“国产 网络游戏”,这时候,再给以空格分隔的词语加上引号,去Sphinx搜索【"反恐行动" "游戏"】或【"国产" "网络游戏"】,就能搜索到这条记录了。中文分词词库发生增、删、改,无需重建整个Sphinx搜索索引。 henry解释:也就是说,做索引的时候,不用词库去分词,而是沿用sphinx原来的一元分词法。在搜索的时候才用分词去做词组的完全匹配搜索。另外一个原因,用原版的一元分词索引速度也要快很多,在他的博文中提到:   “我的环境是10000转的SAS硬盘,如果换成15000转的硬盘,速度要更快,Sphinx官方给出的索建引速度为10Mbytes/秒。原版的sphinx一元分词创建索引速度在5.5M/秒以上,而打了LibMMSeg中文分词补丁的Sphinx创建索引速度只有300KB/秒,所以采用原版的sphinx 0.9.9能够保证频繁更新情况下的索引实时性。一元分词的索引的数据量会大一些,但可以通过sphinx分布式索引来解决搜索效率问题。”   希望对大家有所借鉴,原文地址http://blog.s135.com/sphinx_search/

貓熊寶寶幼齒園

姜經緯的博客