易栈网-膘叔

字符串，恐怕应该算是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来开发网页。

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

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

 新闻来源：cnbeta.com

对于今天晚上的闭幕式，我有一句话要讲：春晚，又见春晚。
相对于贝克汉姆的出场，和最终的群星演唱，我实在想不出有什么可以形容我的心情的。对比于历年可见的类似节目，我只能感慨一下，今年我提前看到了春晚。
估计和我有同样想法的人不在少数吧？什么事情都是虎头蛇尾的，也应该算是我们的风俗了。可怜最后几个明星演出。我只看到了三个人。还有一个穿白衣的，我死活看不到脸。

镜头，走位。唉。。。拍摄风格也是和春晚相差无几，我还能说什么？

从MYSQL4.1开始，它终于支持了外键。在数据库设计中，主键和外键是一种能够把多个表组织为一个有效的关系数据库的粘合剂。它们的设计良好与否对数据库的性能和可用性有着决定性的影响。

不得不说的是，在系统设计的时候，必须将数据库模式从理论上的逻辑设计转换为实际的物理设计。而主键和外键的结构是这个设计过程的症结所在。毕竟，一旦将所设计的数据库用于了生产环境，就很难对他们进行修改，因此，在开发阶段设计好主键和外键就显得犹为重要。

对于主键而言，它是不可被重复的，而且尽量不包含特殊含义，毕竟主键的使用只是为了让数据库多一条高效的索引，而且在被外部引用的时候不会产生重复。同样重要的是主键最好不要和其他键一起组成复合主键，而应该单独用一列来表示。

正因为主键的特殊性，所以在大多数情况下我们都采用了自增字段来表示（但由于前台应用的特殊性，建议在表字段中增加一列有唯一约束的字段，用作前台显示用。比如，原来查看新闻可能是：news.php?newsId=123,这样别人很容易猜出下一条是124，前一条是122，平时这样使用是无所谓，但如果是使用在订单上，别人就很容易知道你的订单数量等，如果采用了GUID这样的值，虽然看起来复杂了一点，但永远不会被人猜出你的订单）

当然主键也可以使用这种GUID来进行设定，但确实是不太建议使用，我主要是指MYSQL，因为MYSQL默认没有默认生成这样键值的函数。而且使用定长字符串做主键，在被外部引用的时候，就显得太长了。

而外键就相对来说比主键约束要小的多，但也是有一定规范的。比如，用主键作外键，这是大多数人的用法。即使在MYSQL尚未支持外键的时候，大多数情况下。也都是通过这样的方式来进行关联。

在使用外键的时候，一般建议是不要超过4张表关联，超过4张，可能你在某些个表里就纯粹看到的是ID记录（类似于数据库的索引），这个时候麻烦的问题就来了。该如何维护这样一个全是ID记录的表呢？一旦这个表被人误操作了。那么。所有的数据都将失去关联了。（如果数据库支持外键功能，在删除这样的外键关联数据，我记得是会出错的。）

外键，除了使用主键外，还有就是那种具有唯一索引的列，仔细想想也确实这样，如果没有唯一，那么关联出来的数据怎么能够具有唯一性？

利用外键进行数据的更新删除，应该是最方便的了。这样也可以避免数据库里会存在冗余数据。

——END——

纯粹是在这里发发牢骚，真正的表设计不是这么简单的。还要根据实际的应用，但这些可以算是一些小小的经验。也许在真正的高手眼里这些都不值一提。但，千里马常有，而伯乐不常有啊。很多人都认为是理所当然的事情，不代表我们这些新手就明白。

记录下来，作为参考，也算是一个笔记