2008 年 09 月

Imagick的DLL在windows上本来无法装上，前面一篇博客里介绍说团队好友hihiyou帮忙找了一个DLL，可以用在PHP 5.2.X上面的，今天一大早COPY到服务器上，并扩展出来。。

看图说话,OH YEAH。可惜。。。sablog不支持Imagick，它还是用GD的，不知道新版本会不会采用。

好象小图看不太清楚。还是点击一下看大图吧。。。

字符串，恐怕应该算是MYSQL里面最复杂的类型了吧？几乎目前所有的问题，都是出在与字符有关的数据列上，大致有几种
1、字符串的查询（以下如果不特指，都是指中文），搜索一个中文的时候，不管是模糊还是精确，往往结果都会有与搜索内容不一致的数据在里面
2、编码，现在大家都知道MYSQL连接上后，先执行一下mysql_query('set names GBK',$conn)这类的语句，从MYSQL4.0升级到4.1及以上版本的朋友在这上面吃的苦不少了。网上关于这类的提问也是最多的
3、索引、效率，varchar是MYSQL所特有的字段，而且长度可变，char则是固定长度的字符串。
在MYSQL所支持的几个字符串格式里面，char和varchar是用的最多的，char是定长字段，，也就是说，不管字符串的实际长度有多少，CHAR(10)将永远占用10个字节。字符串如果前端有空格，那么在存储的时候会自动被数据库去掉，相当于先执行trim($string)，再进行存储，如果不满10个字节，将会采用空格填满，读取数据时，MYSQL会自动将这些空格去掉。看到这里，恐怕它的缺点之一就明显的暴露了，CHAR不能存储那些结尾确实有空格的字符串（因为读取时会被MYSQL自动去掉）。

数据类型	含义
char(n)	固定长度的字符串，最多255个字符
varchar(n)	可变长度字符串，最多255个字符（MYSQL<5.0.3,n<=255 , mysql>=5.0.3,n<=65535）
tinytext	可变长度字符串，最多255
text	可变长度字符串，最多65535-1
medinumtext	可变长度字符串，最多16,777,216-1
longtext	可变长度字符串，最多4,294,967,296-1

除了char类型外，其余类型均为可变长度，实际所占空间由该字段所存的内容决定。虽然varchar与tinytext一样都是255个字节，但不同的是varchar可以指定存储的长度，而tinytext只能由存储的时候数据长度而定。
在数据表被创建的时候，MYSQL 把数据列的定义改成一种对MYSQL来说更有效率的形式。这种自动方式的修改称为默许的数据列修改（client column changes）。一般来说是对CHAR和VARCHAR数据列都有影响：如果n<4，varchar(n)将被修改为char(n),而如果n>3并且在同一个数据表里还有其他的可变长度的字段，char将被修改成varchar格式。如果数据表里只有固定长度的数据列，char列将不发生变化。也就是说，你在数据表里的字段如果有多种格式，那么你通过alter table 是无法进行修改的。
上表提到，varchar在新版本里变成了65535个字节，但最大字符个数还是要取决于具体的字符集（GBK中文占两个字节，而UTF8中文则占三个字节）。上面这些所有的数据类型都有一个BINARY属性，一旦该字段添加了这个属性，那么MYSQL就会将他们视同BLOB字段来处理。BINARY的好处是在排序时把字符视为二进制，这样就可以把字母的大小写分开，而且由于是二进制字符串，所耗费的时间也会更短。可惜，在实陆应用中我们存储的大多是中文，所以这一点对我们来说并没有太大的区别。中文，本来就没有大小写之分，再怎么二进制，还是那样。呵呵。
在MYSQL4.0及以前的版本里，各种文本字段的字符集和排序方式都由MYSQL服务器决定，默认值是latin1字符集和瑞典排序方式。虽然允许在MYSQL配置文件里指定一种字符集和排序方式，但这会导致所有的数据库受到影响，还有，对字符集和排序方式做了任何修改都必须重启数据库服务器方能生效，更可恨的是，重启后，还必须重新创建所有的索引，同时，MYSQL4.0之前的版本并不支持UNICODE字符集。
4.1后，这些问题得到了很大的改状况，可以单独为某一个数据列指定一种字符集和排序方式，而且字符集和排序方式的选择范围也大了很多，因为从4.1开始支持了UNICODE和UCS-2等。与字符集及相关排序方式相关的命令是：SHOW COLLATION（必须要注意的是，字符集和排序方式不是随意组合的，每种字符集都有该字符集对应的一些排序方式，而不能混用）。如果没有为某个数据列指定一个字符集和排序方式，它将使用数据表、数据库或MYSQL数据库的默认字符集。至于数据库应该使用哪种字符类型，还是由你的项目所决定，如果你的项目采用了GBK编码，那数据库也同样使用这种编码比较好。如果你在项目初始时对于采用哪种编码未知，那么UTF8应该算是比较好的一种解决方法，数据迁移以及对于JAVA、.net等程序的支持也是最好的，唯一的缺点就是占用数据库空间太大。
说到现在，一直在说latin1和unicode字符集，这代表了什么意思呢？
latin1：在最初的MYSQL版本里都是默认采用了这种字符集，它是符合ISO-8859-1的规范的，收录了西欧国家的常用字符，在那个年代，国内还没有多少人使用MYSQL，而真正使用这些的大多是欧美国家，所以这个字符集主要就是用于收集这些国家常用的字符。随后latin的标准 在不停的变化，有latin2,latin9等，但它们当中并没有一个能够把所有欧洲语言里所有的字符都收录齐全，也就是说latin库里并没有一个可以适用于整个欧洲。
UNICODE：正由于latin不能解决这个问题，所以人们开发出了双字节的UNICODE字符集，两个字集意味着是2的16次方，可以存储65535个字符，所以UNICODE字符集不仅涵盖了所有的欧洲语言，还覆盖了绝大多数的亚洲语言。然而UNICODE只定义了每个字符的编码，没有定义如何存储这些编码。
在这个基础上，也同样发展出了好多变体。最重要的是UCS-2和UTF8，UCS-2又称UTF-16，即每种字符都用两个字节表示，所以几乎所有的字符都被涵盖了。但是这种也是有弊端的：存储空间大了一倍，即使是ASCII字符也是这样；字节编码0会出现在字符串中（比如ASCII写出来的文本里，每一个的第2个字节都是0），可是一些程序会把0当成结束标志，而导致出错。
UTF8是UTF16的替代品，在这里所有的ASCII（7位）仍然象以前一样用第一位是0的单字节表示，所有其他的UNICODE字符用2~4个字节表示。它的缺点也同样明显：同一份文档的字节数和字符数没有任何显而易见的关系，但由于它与现有的程序高度兼容，所以UTF8几乎已经成为了一种事实上的标准，而且大多数软件都把它作为自己的默认字符集。
可惜，PHP发展到现在对于UNICODE的支持还是一般性，并没有内置，处理的时候，不是用ICONV就是mb_string库（PHP6是说内置支持了），但并不能妨碍我们使用UTF8来开发网页。

字符串就介绍到这里。太累了。。。。。这个方面的问题太多了，在以后的连载中遇到再详细说明吧。

ImagIck这个控件应该算是最近两年来，各个WEB程序员都比较推荐的一个编辑图片的软件。
其实这也是一个分支吧？如果我没有记错，都是从XXX（忘了是哪个了）分出来的，一个是MagickWand,另一个就是这个Imagick了，只是MagicWand好象比较难以控制，并不如这个Imagick方便，再加上Imagick的类及使用方法也集成在PHP手册里了。

本来我是安装了ImageMagick-6.2.5-4-Q16-windows-dll.exe的，然而，愿望总是美好的，结果在Apache下运行的时候，总是提示挂接不上某个动态链接库，装回5.5.7后一切正常，但却无法使用PHP手册里所提供的函数。

本来都想放弃了，可是同事在单位里的Linux上装上了这个软件，但由于我们的PHP版本太低，在大多数的情况下都是直接使用命令行进行操作的。

为了适应将来的PHP版本升级，所以不得不学习这个软件，在我以前的贴子里，也贴过了Imagick官网和一些例子的实现网站。
今后我也会重新拾起代码，尽量、争取把官网的例子也逐步一一实现，或者大部分常用的实现一下。

感谢团队好友hihiyou(http://www.hihiyou.com)为我找了一个可以在windows下使用的Imagick的DLL，可以让我开始学习它。

先来个例子，黑黑。。。

<?php
header('Content-type: image/gif');

$image = new Imagick('google_logo.gif');
$image->adaptiveResizeImage(400,NULL);

echo $image;
?>

原图：

重生成：

在DBA Notes网站上发现这篇文章，也到InfoQ去看了一下，再加上这个问题确实一直是一个让人头疼的问题，由谁来处理排序更合适。利用MYSQL排序，如果数据很大，一个order by就很有可能会让数据表锁死在那里，可是让PHP来处理，却是让数据被进行二次处理。所以看到本文的时候，就先复制过来，一来自己也可以做点备份，二来也可以给其他人留点资料。

---

此文首发在 InfoQ 中文站。作者：明灵(dragon) , Fenng . Note：要转载的朋友请注意注明这篇文章的第一作者!
这篇文章是dragon 朋友来邮探讨后他做的一个总结。在 DB 中排序还是在 应用程序中排序是个很有趣的话题，dragon 第一份邮件中其实已经总结的很好了，我添加了一点建议而已。现在放上来，与大家共享。这篇文章也投稿到了 InfoQ 中文站 。

Q：列出在 PHP 中执行排序要优于在 MYSQL 中排序的原因？给一些必须在MYSQL中排序的实例？

A：通常来说，执行效率需要考虑 CPU、内存和硬盘等的负载情况，假定 MYSQL 服务器和 PHP 的服务器都已经按照最适合的方式来配置，那么系统的可伸缩性（Scalability）和用户感知性能（User-perceived Performance）是我们追求的主要目标。在实际运行中，MYSQL 中数据往往以 HASH tables、BTREE 等方式存贮于内存，操作速度很快；同时 INDEX 已经进行了一些预排序；很多应用中，MYSQL 排序是首选。而在应用层（PHP）中排序，也必然在内存中进行，与 MYSQL 相比具有如下优势：

• 1、 考虑整个网站的可伸缩性和整体性能，在应用层（PHP）中排序明显会降低数据库的负载，从而提升整个网站的扩展能力。而数据库的排序，实际上成本是非常高的，消耗内存、CPU，如果并发的排序很多，DB 很容易到瓶颈。
• 2、 如果在应用层(PHP)和MYSQL之间还存在数据中间层，合理利用，PHP会有更好的收益。
• 3、 PHP在内存中的数据结构专门针对具体应用来设计，比数据库更为简洁、高效；
• 4、 PHP不用考虑数据灾难恢复问题，可以减少这部分的操作损耗；
• 5、 PHP不存在表的锁定问题；
• 6、 MYSQL中排序，请求和结果返回还需要通过网络连接来进行，而PHP中排序之后就可以直接返回了，减少了网络IO。

至于执行速度，差异应该不会很大，除非应用设计有问题，造成大量不必要的网络IO。另外，应用层要注意PHP 的 Cache 设置，如果超出会报告内部错误；此时要根据应用做好评估，或者调整Cache。具体选择，将取决于具体的应用。

列出一些 PHP 中执行排序更优的情况：

• 1、 数据源不在 MYSQL 中，存在硬盘、内存或者来自网络的请求等；
• 2、 数据存在 MYSQL 中，量不大，而且没有相应的索引，此时把数据取出来用PHP排序更快；
• 3、 数据源来自于多个 MYSQL 服务器，此时从多个 MYSQL 中取出数据，然后在PHP中排序更快；
• 4、 除了 MYSQL 之外，存在其他数据源，比如硬盘、内存或者来自网络的请求等，此时不适合把这些数据存入 MYSQL 后再排序；

列出一些必须在 MYSQL 中排序的实例：

• 1、 MYSQL 中已经存在这个排序的索引；
• 2、 MYSQL 中数据量较大，而结果集需要其中很小的一个子集；比如 1000000 行数据，取TOP 10；
• 3、 对于一次排序、多次调用的情况，比如统计聚合的情形，可以提供给不同的服务使用，那么在 MYSQL 中排序是首选的。另外，对于数据深度挖掘，通常做法是在应用层做完排序等复杂操作，把结果存入MYSQL即可，便于多次使用。
• 4、 不论数据源来自哪里，当数据量大到一定的规模后，由于占用内存/Cache 的关系，不再适合 PHP 中排序了；此时把数据复制、导入或者存在 MYSQL ，并用 INDEX 优化，是优于 PHP 的。不过，用 Java，甚至 C++ 来处理这类操作会更好。 [有些类似大数据集聚合或者汇总的数据，在客户端排序得不偿失。当然，也有用类似搜索引擎的思路来解决类似应用的情况。]

从网站整体考虑，就必须加入人力和成本的考虑。假如网站规模和负载较小，而人力有限（人数和能力都可能有限），此时在应用层（PHP）做排序要做不 少开发和调试工作，耗费时间，得不偿失；不如在 DB 中处理，简单快速。对于大规模的网站，电力、服务器的费用很高，在系统架构上精打细算，可以节约大量的费用，是公司持续发展之必要；此时如果能在应用层(PHP) 进行排序并满足业务需求，尽量在应用层进行。

最近为小家伙买了一辆推车，因为我家和我丈人家都在6楼，所以买了个最轻便的。否则以后我老婆一个人可扛不动（我是指我不在家的时候）。

拍了点照片，好象小家伙很兴奋的样子。。

先贴一点老照片：

在上传这次刚拍的，呵呵：

前两天，我终于使用wubi，在我的笔记本上装上了UBUNTU，然而问题随之而来：
1、部分软件装不上，比如wine
2、QQ无法使用，自带的piddig中的QQ协议是不支持群功能的，下载了qq for linux，结果DEB版本的无法安装，因为只支持i386，这时才发现，我INTEL的CPU，装的居然是for AMD64的UBUNTU（？不理解为什么，这个AMD64是指FOR AMD的芯片吗？），最后只能下载压缩包，解开后里面只有三个文件，运行QQ后，无法使用中文输入法。
3、SCIM输入法，默认没有中文输入，直到我把中文语言包安装好才行。
4、安装和卸载功能、新立得软件安装器，居然是分开的，而且却又互相关联，太郁闷了

虽然有这些缺点，但还是有很大的优点的：
1、硬件全部认出来了，一个驱动也不需要装：无线、SD读卡器，windows分区、蓝牙等等
2、显示器的刷新率终于上了60HZ，看网页再也没有烦恼了
3、很多软件安装还是比较方便的，比如zendstudio for eclipse 6.1等
4、重要操作和vista差不多，需要UNLOCK才能操作（命令行除外，sudo -s就行了）
5、界面友好，漂亮，性能也不错

在使用过程中，发生了一件事情，让我惊心动魄几小时。
我把佑阳的照片从SD卡读出来，放进mount后的windows D盘中，因为担心无法写入，于是，chmod -R 777了一下，然后建立了一个目录，cp 移动硬盘里所有的照片到该目录下。操作完毕，SD卡能够顺利认出确实很方便。自动mount到/media/mobile/目录下，因为我的盘符是mobile。

问题就这样产生了，我切换到windows系统的时候，居然间提示我D盘无法访问，很吃惊的回到了linux下，重新挂载D盘，chmod -R 777，再回去，还是无法访问（但在linux下面可以正常访问）

使用windows进入管理界面，发现该盘符所对应的文件系统不再是NTFS，而是不可识别的RAW，找了一些相关资料，也找了一些分区信息更改软件，发现均无效。（在此之前，回到linux里把D盘内容备份到了移动硬盘里。）
不得己，格式化D盘，把移动硬盘里的东西全部恢复到D盘。
折腾了两天的问题终于解决。

QQ不能输中文确实是遗憾。不过我会尽量到ubuntu下面使用。过两天就该是我安装apache+mysql+php的时候了。

PS：团队好友hihiyou传了个imagick for windows的DLL给我，终于可以在windows下面写imagick的代码了。我也会象我同事那样，逐步把imagick官网例子用imagick实现一下。

http://news.sina.com.cn/c/2008-09-19/074516317802.shtml
http://news.sina.com.cn/c/2008-09-17/131714460852s.shtml
不多说，看这两个页面源码，再联系XX门事件。

忘了提了，是懂SEO的人看。普通人看了也白看。不截图，不留把柄

Sorry.
Now i am using ubuntu,and i couldn't configure scim,so i can't input Chinese.

The contents of <Be good at using Mysql> maybe late.

English is very poor,please dont laugh at me.thanks

　　1931年9月18日，日本帝国主义对我国沈阳北大营的中国驻军发动武装进攻，接着对我国东北地区进行大规模武装侵略。这就是震惊中外的“九一八”事变。

　　1931年9月18日晚，驻扎在我国东北的日本关东军按照精心策划的阴谋，由铁道“守备队”炸毁了沈阳柳条湖附近的南满铁路路轨，并嫁祸于中国军队。这就是所谓的“柳条湖事件”。日军以此为借口，突然向驻守在沈阳北大营的中国军队发动进攻。当时，蒋介石正集中力量进行反共反人民的内战，执行“攘外必先安内”的反动政策，对日本侵略 者妥协退让。东北军执行蒋介石“不抵抗主义”的命令，未进行有组织的抵抗。当晚，日军攻占北大营，19日占领了整个沈阳城。接着，日军向辽宁、吉林和黑龙 江的广大地区进攻，东北军基本上不战自溃。1932年1月3日，日军占领锦州；2月5日，占领了北满最大城市哈尔滨。至此东北三省全部沦陷。1932年3 月，在日本帝国主义卵翼下，在长春建立起傀儡政权——伪满洲国。从此，日本帝国主义把东北变成它的殖民地，全面加强政治压迫、经济掠夺、文化奴役，使我国 东北3000多万同胞，惨遭涂炭，陷于水深火热之中。

　　刚刚在新浪新闻中看到：

　　今年是“九·一八”事变72周年，同时也是沈阳市定于9月18日晚上鸣响防空警报的第八个年头。据介绍，起初沈阳市鸣警报的时间定在9月18日晚10时20分，后考虑到市民的生活习惯等原因，于3年前将鸣响警报时间提前到晚上9时18分。

　　明晚9时18分，在市区道路上行驶的机动车辆要在行驶中鸣笛，当地广播电台和电视台中断正常节目，插播“勿忘国耻，振兴中华”画面和警报声音。警报解除后，节目恢复正常播出。

日期与时间型理论上应该是用的最多的，不管是什么时候，都需要使用时间，用户登录，文章编辑，甚至LOG，哪个不需要时间？然而在真正的应用中，却没有多少人在使用日期与时间型字段，大多数人都是使用int的时间戳来替代了日期型字段。那么，究竟应该怎样正确使用呢？日期型字段的优劣是什么？今天稍微介绍一下。
在MYSQL数据库中，关于日期和时间型字段有四种，date,time,datetime,year，还有一种比较特殊的timestamp字段。下面将一一介绍。

类型	含义
DATE	Y-m-d的时间格式，取值范围1000-01-01~9999-12-31，占用3个字节
TIME	H:i:s的时间格式，取值范围-838:59:59~+838:59:59，占用3个字节（说实话，我没有理解这个取值范围）
DATETIME	Y-m-d H:i:s的时间格式，是DATE+TIME的组合
YEAR	年份，取组范围1901~2155和0000，占用一个字节，YEAR有2位和4位之分，4位的就是前面的取值范围，2位的取值范围为70~69，代表了1970~2069
TIMESTAMP	虽然这个TIMESTAMP并非传统意义上的时间戳，但它的取值范围还是符合时间戳的标准，即从1970~2037，基本格式为：Y-m-d H:i:s，在以前的版本里，日期与时间之间并没有空格，如果为了兼容老的数据，在查询的时候则需要使用：select ts+0 from table来获取正确的时间

MYSQL在早期版本里对于时间类型的缺乏严格的判断，而只是仅仅判断数值是否在一个区间，却并不判断它是否合法：月份值允许0~12，日期值允许1~31，所有的数据验证都是由客户端判断好而数据库这边仅仅是一个存储作用。但这在5.0.2版本的时候，一切有了很大的改观，MYSQL开始对日期与时间型数据的判断非常严格，只有它认为合法的数据才存储到数据库，当然它认为0000-00-00仍然是合法数据。
不过，这仍然需要对MYSQL的系统变量sql_mode进行设置，大致有以下三个设置值：
1、ALLOW_INVALID_DATES 即不对数据有效性进行判断，仍然允许存入有明显错误的时间，比如：2001-02-31
2、NO_ZERO_DATE 在这种模式下，0000-00-00不再认为是合法日期
3、NO_ZERO_IN_DATE 不允许使用0作为月份值或者日期值
对于DATE,TIME,DATETIME,YEAR这四种格式，大家都可以从名字上能够看出来格式或者规范是什么样的，真正特殊的是TIMESTAMP格式。
对于TIMESTAMP格式，我想，用PHP开发的人应该是非常熟悉，时间戳嘛。在PHP里面直接使用time()函数，返回的就是当前时间的时间戳。可是，在MYSQL里，TIMESTAMP的存储值和PHP里的TIMESTAMP并不一样，就象上文说的，它存储的格式和DATETIME是一样的，只是它是自动存入的。
当你的表存在TIMESTAMP字段时，如果你对其他字段的内容进行修改，这个字段的值也会随之更新，几乎可以这么理解，这个字段就是MYSQL给你提供的数据记录的最后一次更新时间，正因为这个原因，所以TIMESTAMP字段大多数时候都是被用来管理和检查数据使用，而不会用来存储实际数据（因为一旦其他数据有更新，它就会自动更新）。
有一些需要与客户端程序或者函数进行交互的数据库操作，只有在数据表里存在一列TIMESTAMP字段才能正常工作，如Connector/ODBC，事实上就连MYSQL在对数据进行内部管理的时候，也需要知道它们的最后一次修改时间。虽然说该字段会被自动更新，但如果你在INSERT、UPDATE的时候，如果你指定了该字段的值，默认就会使用该值插入数据表。如果一个表里面有多个字段有TIMESTAMP属性，那么默认MYSQL是更新第一个有此属性的字段。
TIMESTAMP并没有想象中的那么不可控制，从mysql4.1.3开始，MYSQL为TIMESTAMP增加了两个属性，它们可以让用户更好的调控对TIMESTAMP列的刷新行为，使得这个字段可以更加好的为我们服务。

设置类型	含义
TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP	在创建新记录或者修改现有记录的时候对这个数据列进行刷新
TIMESTAMP	行为同上
TIMESTAMP DEFAULT CURRENT_TIMESTAMP	只在创建新记录的时候才刷新这个值，以后更新等操作时不会进行修改
TIMESTAMP ON UPDATE CURRENT_TIMESTAMP	在创建新记录的时候设置值为0，在修改的时候才会更新它。
TIMESTAMP DEFAULT 'YYYY-mm-dd hh:mm:ss' ON UPDATE CURRENT_TIMESTAMP	在创建新记录的时候设置值为指定值，以后在修改的时候刷新它。

如果偶尔遇到你在更新某条数据记录的时候，不想MYSQL自动刷新TIMESTAMP数据列，你只能按照下面的SQL格式来写：UPDATE table SET field = 'new value' , ts = ts;
有时候我们需要在时间列里面存入微秒，但目前而言，MYSQL还不能存储这样的结果。虽然这样的相关函数已经存在。
虽说MYSQL的日期格式往往都是'yyyy-mm-dd'这样的格式，但其实在insert和update的时候，还是可以接受'yyyy/mm/dd'这种符合日期规范格式的数据。所以，不要太担心。
对于日期处理，在SQL里面用date_format,format_unix等，这类函数太多了。如果以后有空我会慢慢介绍。