2月 202018
 

Mysql中utf8_general_ci与utf8_unicode_ci有什么区别呢?在编程语言中,通常用unicode对中文字符做处理,防止出现乱码,那么在MySQL里,为什么大家都使用utf8_general_ci而不是utf8_unicode_ci呢?

用了这么长时间,发现自己竟然不知道utf_bin和utf_general_ci这两者到底有什么区别。。
ci是 case insensitive, 即 “大小写不敏感”, a 和 A 会在字符判断中会被当做一样的;
bin 是二进制, a 和 A 会别区别对待.
例如你运行:
SELECT * FROM table WHERE txt = ‘a’
那么在utf8_bin中你就找不到 txt = ‘A’ 的那一行, 而 utf8_general_ci 则可以.
utf8_general_ci 不区分大小写,这个你在注册用户名和邮箱的时候就要使用。
utf8_general_cs 区分大小写,如果用户名和邮箱用这个 就会照成不良后果
utf8_bin:字符串每个字符串用二进制数据编译存储。 区分大小写,而且可以存二进制的内容

一、官方文档说明
下面摘录一下Mysql 5.1中文手册中关于utf8_unicode_ci与utf8_general_ci的说明: Continue reading »

4月 272011
 

10.6 选择一种表类型

用MySQL,当前(版本 3.23.5)你能从一个速度观点在4可用表的格式之间选择。

静态MyISAM

这种格式是最简单且最安全的格式,它也是在磁盘格式最快的。速度来自于数据能在磁盘上被找的难易方式。当所定有一个索引和静态格式的东西时,它很简单,只是行长度乘以行数量。而且在扫描一张表时,用每次磁盘读取来读入常数个记录是很容易的。安全性来自于如果当写入一个静态MyISAM文件时,你的计算机崩溃,myisamchk能很容易指出每行在哪儿开始和结束,因此它通常能回收所有记录,除了部分被写入的那个。注意,在MySQL中,所有索引总能被重建。

动态MyISAM

这种格式有点复杂,因为每一行必须有一个头说明它有多长。当一个记录在更改时变长时,它也可以在多于一个位置上结束。你能使用OPTIMIZE table或myisamchk整理一张表。如果你在同一个表中有象某些VARCHAR或BLOB列那样存取/改变的静态数据,将动态列移入另外一个表以避免碎片可能是一个好主意。

压缩MyISAM

这是一个只读类型,用可选的myisampack工具生成。 Continue reading »

4月 272011
 

10.3 使你的数据尽可能小

最基本的优化之一是使你的数据(和索引)在磁盘上(并且在内存中)占据的空间尽可能小。这能给出巨大的改进,因为磁盘读入较快并且通常也用较少的主存储器。如果在更小的列上做索引,索引也占据较少的资源。

你能用下面的技术使表的性能更好并且使存储空间最小:

尽可能地使用最有效(最小)的类型。MySQL有很多节省磁盘空间和内存的专业化类型。

如果可能使表更小,使用较小的整数类型。例如,MEDIUMINT经常比INT好一些。

如果可能,声明列为NOT NULL。它使任何事情更快而且你为每列节省一位。注意如果在你的应用序中你确实需要NULL,你应该毫无疑问使用它,只是避免缺省地在所有列上有它。

如果你没有任何变长列(VARCHAR、TEXT或BLOB列),使用固定尺寸的记录格式。这比较快但是不幸地可能会浪费一些空间。见10.6 选择一种表类型。

每张桌子应该有尽可能短的主索引。这使一行的辨认容易而有效。

对每个表,你必须决定使用哪种存储/索引方法。见9.4 MySQL表类型。也可参见10.6 选择一种表类型。

只创建你确实需要的索引。索引对检索有好处但是当你需要快速存储东西时就变得糟糕。如果你主要通过搜索列的组合来存取一个表,以它们做一个索引。第一个索引部分应该是最常用的列。如果

你总是使用许多列,你应该首先以更多的副本使用列以获得更好的列索引压缩。

如果很可能一个索引在头几个字符上有唯一的前缀,仅仅索引该前缀比较好。MySQL支持在一个字符列的一部分上的索引。更短的索引更快,不仅因为他们占较少的磁盘空间而且因为他们将在索引缓存中给你更多的命中率并且因此有更少磁盘寻道。见10.2.3 调节服务器参数。 Continue reading »

4月 272011
 

10.2.3 调节服务器参数
你能用这个命令得到mysqld服务器缺省缓冲区大小:

shell>; mysqld –help

这个命令生成一张所有mysqld选项和可配置变量的表。输出包括缺省值并且看上去象这样一些东西:

Possible variables for option –set-variable (-O) are:
back_log              current value: 5
connect_timeout       current value: 5
delayed_insert_timeout  current value: 300
delayed_insert_limit  current value: 100
delayed_queue_size    current value: 1000
flush_time            current value: 0
interactive_timeout   current value: 28800
join_buffer_size      current value: 131072
key_buffer_size       current value: 1048540
lower_case_table_names  current value: 0
long_query_time       current value: 10 Continue reading »

4月 272011
 

MySQL中文参考手册
——————————————————————————–

10 从MySQL得到最大的性能

优化是一项复杂的任务,因为它最终需要对整个系统的理解。当用你的系统/应用的小知识做一些局部优化是可能的时候,你越想让你的系统更优化,你必须知道它也越多。

因此,本章将试图解释并给出优化MySQL的不同方法的一些例子。但是记住总是有某些(逐渐变难)是系统更快的方法留着去做。

10.1 优化概述
为了使一个系统更快的最重要部分当然是基本设计。你也需要知道你的系统将做这样的事情,那就是你的瓶颈。

最常见的瓶颈是:

磁盘寻道。磁盘花时间找到一个数据,用在1999年的现代磁盘其平均时间通常小于10ms,因此理论上我们能大约一秒寻道 1000 次。这个时间用新磁盘提高很慢并且很难对一个表优化。优化它的方法是将数据散布在多个磁盘上。

当磁盘在我们需要读数据的正确位置时,磁盘读/写。用1999年的现代,一个磁盘传输类似10-20Mb/s。这必寻道更容易优化,因为你能从多个磁盘并行地读。

CPU周期。当我们读数据进内存时,(或如果它已经在那里)我们需要处理它以达到我们的结果。当我们有相对内存较小的表时,这是最常见的限制因素,但是用小表速度通常不是问题。

内存带宽。当CPU需要超出适合cpu缓存的数据时,缓存带宽就成为内存的一个瓶颈。这是对大多数系统的一个不常见的瓶颈但是你应该知道它。 Continue reading »

4月 272011
 

作者: Jun 日期: 2010年01月11日

这两天,一台VPS服务器的MYSQL进程的物理内存(>700MB)和虚拟内存(>1.4G)使用率非常高(上面仅仅跑了4个站)。

开始怀疑是某个网站程序设计上出了问题,找程序员商量了,没查出问题,汗。。。。

最后发现是一低级错误:

优化mysql数据库性能的十个参数

(1)、max_connections
允许的同时客户的数量。增加该值增加 mysqld 要求的文件描述符的数量。这个数字应该增加,否则,你将经常看到 too many connections 错误。

(2)、record_buffer
每个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区。如果你做很多顺序扫描,你可能想要增加该值。

(3)、key_buffer_size
索引块是缓冲的并且被所有的线程共享。key_buffer_size是用于索引块的缓冲区大小,增加它可得到更好处理的索引(对所有读和多重写),到你能负担得起那样多。如果你使它太大,系统将开始换页并且真的变慢了。 Continue reading »

9月 182010
 

table_cache指示表高速缓存的大小。当Mysql访问一个表时,如果在Mysql表缓冲区中还有空间,那么这个表就被打开并放入表缓冲区,这样做的好处是可以更快速地访问表中的内容。一般来说,可以通过查看数据库运行峰值时间的状态值Open_tables和Opened_tables,用以判断是否需要增加table_cache的值,即如果open_tables接近table_cache的时候,并且Opened_tables这个值在逐步增加,那就要考虑增加这个值的大小了。

  在mysql默认安装情况下,table_cache的值在2G内存以下的机器中的值默认时256到512,如果机器有4G内存,则默认这个值是 2048,但这非意味着机器内存越大,这个值应该越大,因为table_cache加大后,使得mysql对SQL响应的速度更快了,不可避免的会产生更多的死锁(dead lock),这样反而使得数据库整个一套操作慢了下来,严重影响性能。所以平时维护中还是要根据库的实际情况去作出判断,找到最适合你维护的库的 table_cache值,有人说:“性能优化是一门艺术”,这话一点没错。大凡艺术品,大都是经过千锤百炼,精雕细琢而成。 Continue reading »

9月 182010
 

最近,帮一个朋友优化一个拥有20万主题,100万帖子,3万多会员,平均在线人数2000人的Discuz!论坛,采用Linux2.6+Apache2+mod_php5+MySQL5,服务器配置为双至强+4G内存,优化前,系统平均负载(load average)基本维持在10以上,MySQL的CPU占用率基本在90%以上,优化后,系统平均负载降到0.5以下,MySQL的CPU占用率很少有超过10%的时候。优化前YSlow得分只有35分,优化后YSlow得分86分。现将优化的过程和经验做一个记录:

首先,对Apache进行优化,编辑httpd.conf,设置HostnameLookups、KeepAlive、 MaxKeepAliveRequests以及KeepAliveTimeout四个参数,调整MaxSpareServers、 ServerLimit、MaxClients以及MaxRequestsPerChild参数,还可以考虑弃用prefork而采用worker MPM。设置mod_deflate及mod_expires模块,不过注意Discuz!不能对PHP文件开启Expires,否则会出现问题。另外还可以考虑开启mod_cache和mod_mem_cache模块。另外利用cronolog按天对日志进行轮循截断,如果日志特别大,也可以按小时截断。另外再加上Awstats对日志进行分析,并用gzip对日志进行压缩,自动删除1个月前的日志。

其次,对PHP进行优化,编辑php.ini,调整output_buffering、zlib.output_compression及 max_execution_time、max_input_time、memory_limit等参数,并安装Xcache和Zend Optimizer。

然后对MySQL进行优化。 Continue reading »