<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>臭皮匠 &#187; mysql</title>
	<atom:link href="http://guogoul.com/tag/mysql/feed/" rel="self" type="application/rss+xml" />
	<link>http://guogoul.com</link>
	<description></description>
	<lastBuildDate>Wed, 07 Jul 2010 04:53:41 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>关于 MYSQL 字符串类型的存储需求</title>
		<link>http://guogoul.com/2010/01/30/storage_requirements_for_string_types/</link>
		<comments>http://guogoul.com/2010/01/30/storage_requirements_for_string_types/#comments</comments>
		<pubDate>Sat, 30 Jan 2010 12:41:14 +0000</pubDate>
		<dc:creator>shanfeng</dc:creator>
				<category><![CDATA[mysql]]></category>

		<guid isPermaLink="false">http://guogoul.com/?p=245</guid>
		<description><![CDATA[关于mysql中的列类型如何定义，是一个让初学者让人头痛的问题。列类型的恰当定义是一个数据库高效存储的重要保证,其中字符串类型的定义是最重要也是相对较难的。很不幸到至今我才清楚char，varchar的真正定义方式 。
原因有二.
1.没有亲自动手去试错，文档上说的怎么样，就天真的认为就是那样
2.是看过官方源文档，但没有查看官方原版英文文档
咱们通过对比来加深记忆
1.mysq中文文档http://dev.mysql.com/doc/refman/5.1/zh/column-types.html#storage-requirements
2. mysql英文文档http://dev.mysql.com/doc/refman/5.1-maria/en/storage-requirements.html


对比上面的两张表中char与varchar的描述
char：
中文版: char(M)     M个字节，0  &#60;= M &#60;= 255
英文版:  char(M) M × w bytes,               0 &#60;= M &#60;= 255, where w is               the number of bytes [...]]]></description>
		<wfw:commentRss>http://guogoul.com/2010/01/30/storage_requirements_for_string_types/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Mysql中索引的限制</title>
		<link>http://guogoul.com/2009/12/10/mysql-index-limi/</link>
		<comments>http://guogoul.com/2009/12/10/mysql-index-limi/#comments</comments>
		<pubDate>Thu, 10 Dec 2009 14:51:23 +0000</pubDate>
		<dc:creator>shanfeng</dc:creator>
				<category><![CDATA[mysql]]></category>

		<guid isPermaLink="false">http://guogoul.com/?p=228</guid>
		<description><![CDATA[##摘自mysql的性能调优与架构设计##（备忘）
1.myIsam存储引擎索引键长度的总和不能超过1000字节
2.BLOB和TEXT列只能创建前缘索引
3.Mysql目前不支持函数索引
4.使用不等于(!=或者)的时候，Mysql无法使用 索引
5.过滤字段如果使用 函数运算（如abs(column)）后，mysql无法使用索引
6.join语句中join条件字段类型不一致时，mysql无法使用索引
7.使用like操作的时候，如果条件以通配符开始（&#8221;%abc&#8230;&#8221;）时，mysql无法使用索引
8.使用非等值查询的时候，mysql无法使用hash索引
]]></description>
		<wfw:commentRss>http://guogoul.com/2009/12/10/mysql-index-limi/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>mysql，系统架构学习材料分享</title>
		<link>http://guogoul.com/2009/07/29/share_percona_pdf/</link>
		<comments>http://guogoul.com/2009/07/29/share_percona_pdf/#comments</comments>
		<pubDate>Wed, 29 Jul 2009 01:13:39 +0000</pubDate>
		<dc:creator>shanfeng</dc:creator>
				<category><![CDATA[linux]]></category>
		<category><![CDATA[mysql]]></category>

		<guid isPermaLink="false">http://guogoul.com/?p=191</guid>
		<description><![CDATA[最近花了点时间看完了国外的大牛在Percona会议上的演讲稿，选了一些个人觉得对我自己有用的Pdf，分享给大家。主要关于数据存储，备份，系统性能优化方面.本来的想法是把这些文档翻译到博客上，又怕糟蹋了人家的作品，还是直接上传原文件吧.由于文件有点大分两个压缩包上传。
learn1
learn2
里面包括以下几个文件:
1.Ideal Achitecture:  主要介绍了mysql表字段与索引的设计
2.Fighting_MySQL_Replication_Lag:介绍如何解决mysql主从复制的延时最小化问题
3.Innodb_Performance_Tuning： innodb相关介绍
4.mysql_pagination：   数据库分页查询的设计问题
5.non_disruptive_backups:  用lvm快照解决数据备份
6.percona_proactive:  dba，系统管理员所要关心的问题
]]></description>
		<wfw:commentRss>http://guogoul.com/2009/07/29/share_percona_pdf/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>mysql: logs-slave-updates备忘</title>
		<link>http://guogoul.com/2009/07/13/logs-slave-updates/</link>
		<comments>http://guogoul.com/2009/07/13/logs-slave-updates/#comments</comments>
		<pubDate>Mon, 13 Jul 2009 14:06:07 +0000</pubDate>
		<dc:creator>shanfeng</dc:creator>
				<category><![CDATA[jQuery]]></category>
		<category><![CDATA[linux]]></category>
		<category><![CDATA[mysql]]></category>
		<category><![CDATA[php]]></category>
		<category><![CDATA[tools]]></category>
		<category><![CDATA[技术]]></category>
		<category><![CDATA[replication]]></category>
		<category><![CDATA[slave]]></category>

		<guid isPermaLink="false">http://guogoul.com/?p=184</guid>
		<description><![CDATA[
 --logs-slave-updates
通常情况，从服务器从主服务器接收到的更新不记入它的二进制日志。该选项告诉从服务器将其SQL线程执行的更新记入到从服务器自己的二进制日志。为了使该选项生效，还必须用--logs-bin选项启动从服务器以启用二进制日志。如果想要应用链式复制服务器，应使用--logs-slave-updates。例如，可能你想要这样设置：
A -> B -> C
也就是说，A为从服务器B的主服务器，B为从服务器C的主服务器。为了能工作，B必须既为主服务器又为从服务器。你必须用--logs-bin启动A和B以启用二进制日志，并且用--logs-slave-updates选项启动B。

以上是摘自mysql对于logs-slave-updates启动选项的描述。
当然logs-slave-upates也可以写入my.cnf :
//////////////////
log_slave_updates=1
//////////////////
当然在这种机制下可能有的同学会存在这么个问题：
如果a->b   b->a   这样的双master架构下，a,b都打开log_slave_updates选项会不会出现无限循环的状态。
mysql已经考滤到了这个问题，每条bin-log都会记录执行语句的源server_id.当slave读到语句的server_id等于本身的ID的时候，不会忽略执行，所以我们不用担心a,b会不会无限循环下去。

基于以上这种情况，mysql的replication集群将更加灵活，你如果需要可以做成各种各样的链式复制。比如 a->b   b->a     b中设置log_slave_updates后还可以b->c.   这样a,c中的数据也是一致的。    
测试部分my.cnf

 26 [mysqld2]
 27 pid-file        = /home/shanfeng/mysql/data2/mysqld2.pid
 28 socket          = /home/shanfeng/mysql/data2/mysqld2.sock
 [...]]]></description>
		<wfw:commentRss>http://guogoul.com/2009/07/13/logs-slave-updates/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>innodb_log_file_size的一个问题</title>
		<link>http://guogoul.com/2009/06/10/innodb_log_file_size/</link>
		<comments>http://guogoul.com/2009/06/10/innodb_log_file_size/#comments</comments>
		<pubDate>Wed, 10 Jun 2009 15:13:08 +0000</pubDate>
		<dc:creator>john</dc:creator>
				<category><![CDATA[mysql]]></category>
		<category><![CDATA[技术]]></category>
		<category><![CDATA[innodb]]></category>

		<guid isPermaLink="false">http://john.renren.in/?p=122</guid>
		<description><![CDATA[备份一份mysql的数据到别的机器上的做法最简单的方案是先把运行的mysql关闭，然后把data目录下面的数据copy到别的机器上的mysql data文件夹下面去然后启动两边的mysql做主从备份。
如果数据库中有存在innodb表的话要注意innodb_log_file_size的问题。可能新的mysql启动会报这个错误
090225 23:50:08 [ERROR] /opt/lamp/apps/mysql/libexec/mysqld: Incorrect information in file: &#8216;./user/actor.frm&#8217;
主要是由于 原来的innodb_log_file_size新的参数不一致导致的。把这个参数改成原来的大小就OK了，当然还有其它的更好解决方案：
参考：
1.http://dev.mysql.com/doc/refman/5.0/en/adding-and-removing.html
2.http://qroom.blogspot.com/2007/03/incorrect-information-in-file.html
由于参考2文档需要要翻墙，把部分内容摘下：
=================
更改了innodb的日志文件大小，即innodb_log_file_size的值，重启mysql之后对innodb的表都会报错：[ERROR] /usr/local/mysql/bin/mysqld: Incorrect information in file: &#8216;./a/b.frm&#8217;。解决办法是修改其值后把日志文件ib_logfile删掉再启动mysql（请注意备份）。
注：删log之前确保innodb_fast_shutdown的值不是2，如果是2则需要先改为1，然后重启使之生效，再关闭mysql删log文件。其默认值是1。
=================
]]></description>
		<wfw:commentRss>http://guogoul.com/2009/06/10/innodb_log_file_size/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>mysqlreport</title>
		<link>http://guogoul.com/2009/06/09/mysqlreport/</link>
		<comments>http://guogoul.com/2009/06/09/mysqlreport/#comments</comments>
		<pubDate>Mon, 08 Jun 2009 16:07:14 +0000</pubDate>
		<dc:creator>john</dc:creator>
				<category><![CDATA[mysql]]></category>
		<category><![CDATA[tools]]></category>
		<category><![CDATA[技术]]></category>
		<category><![CDATA[mysqlreport]]></category>

		<guid isPermaLink="false">http://john.renren.in/?p=113</guid>
		<description><![CDATA[要掌握数据库状态，并了解其不足，然后作出一份详细可靠的优化方案，必须对数据库的各个参数进行量化的了解比如cache用了多，数据每秒有多少请求，select与insert的比例各占多少等。对mysql而言最简单的方案是直接show status,不过这些数据十分晦涩枯燥，不容易理解。mysqlreport的报表则易懂得多.
mysqlreport提供了几乎所有的mysql的关键status信息，而且对这些数据做了加工处理理解起来十分的方便。
参考文档：
1.http://hackmysql.com/mysqlreportguide
2.http://hi.baidu.com/xuwanbest/blog/item/f3f8fca1df8e2788461064fe.html
只有亲试之，才会体会其中的妙处
部分结果：

]]></description>
		<wfw:commentRss>http://guogoul.com/2009/06/09/mysqlreport/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>mysqldumpslow 参数</title>
		<link>http://guogoul.com/2009/06/04/mysqldumpslow/</link>
		<comments>http://guogoul.com/2009/06/04/mysqldumpslow/#comments</comments>
		<pubDate>Thu, 04 Jun 2009 11:29:15 +0000</pubDate>
		<dc:creator>john</dc:creator>
				<category><![CDATA[mysql]]></category>
		<category><![CDATA[技术]]></category>
		<category><![CDATA[mysqldumpslow]]></category>

		<guid isPermaLink="false">http://john.renren.in/?p=117</guid>
		<description><![CDATA[-s ORDER     what to sort by (t, at, l, al, r, ar etc), ‘at’ is default
t: 查询花费时间   l: lock时间    r: 返回的记录数  所有前面的a表示倒序
-r  按输出结果倒序排列
-a  不把字查询字符串与数据改成S,N
-t NUM       just show the top n queries
显示前面几条
-g PATTERN   grep: only consider stmts that include this string后边可以写一个正则匹配模式，大小写不敏感的
-l           don&#8217;t subtract lock [...]]]></description>
		<wfw:commentRss>http://guogoul.com/2009/06/04/mysqldumpslow/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>mysql存储引擎选择</title>
		<link>http://guogoul.com/2009/06/01/storage_engin/</link>
		<comments>http://guogoul.com/2009/06/01/storage_engin/#comments</comments>
		<pubDate>Mon, 01 Jun 2009 15:16:33 +0000</pubDate>
		<dc:creator>john</dc:creator>
				<category><![CDATA[mysql]]></category>
		<category><![CDATA[innodb]]></category>
		<category><![CDATA[myisam]]></category>

		<guid isPermaLink="false">http://john.renren.in/?p=121</guid>
		<description><![CDATA[每每建表自问:  用 MyISAM好呢，还是 InnoDB？N多次都是无解
各种存储引擎都有自己的优点。做出什么样的选择，在于你自己的需求

这下好了，所有的选择按这个来吧!
]]></description>
		<wfw:commentRss>http://guogoul.com/2009/06/01/storage_engin/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>mysql笔记(4)-复合索引的性能问题</title>
		<link>http://guogoul.com/2008/11/02/mysql_4_index/</link>
		<comments>http://guogoul.com/2008/11/02/mysql_4_index/#comments</comments>
		<pubDate>Sun, 02 Nov 2008 00:50:17 +0000</pubDate>
		<dc:creator>john</dc:creator>
				<category><![CDATA[mysql]]></category>
		<category><![CDATA[技术]]></category>

		<guid isPermaLink="false">http://www.guogoul.com/2008/11/02/mysql_4_index/</guid>
		<description><![CDATA[昨天有个朋友谈起复合索引，之前对复合索引只是大概了解没有专门的总结也不敢多言复合索引使用方法的优劣.查阅相关资料后把例子贴出与大家分享，希望可以抛砖引玉.
对于复合索引:Mysql从左到右的使用索引中的字段，一个查询可以只使用索引中的一部份，但只能是最左侧部分。例如索引是key index (a,b,c). 可以支持a &#124; a,b&#124; a,b,c 3种组合进行查找，但不支持 b,c进行查找 .当最左侧字段是常量引用时，索引就十分有效。下面用几个例子对比查询条件的不同对性能影响.
create table test(
  a int,
  b int,
  c int,
  KEY a(a,b,c)
);
优: select * from test where a=10 and b&#62;50
差: select * from test where a50
优: select * from test where  order by a
差: select * from test where  order by [...]]]></description>
		<wfw:commentRss>http://guogoul.com/2008/11/02/mysql_4_index/feed/</wfw:commentRss>
		<slash:comments>13</slash:comments>
		</item>
		<item>
		<title>关于web系统扩展的几点记录</title>
		<link>http://guogoul.com/2008/11/01/sys_web_extend/</link>
		<comments>http://guogoul.com/2008/11/01/sys_web_extend/#comments</comments>
		<pubDate>Sat, 01 Nov 2008 06:27:02 +0000</pubDate>
		<dc:creator>john</dc:creator>
				<category><![CDATA[linux]]></category>
		<category><![CDATA[php]]></category>
		<category><![CDATA[技巧]]></category>
		<category><![CDATA[技术]]></category>
		<category><![CDATA[mysql]]></category>
		<category><![CDATA[web]]></category>

		<guid isPermaLink="false">http://www.guogoul.com/2008/11/01/sys_web_extend/</guid>
		<description><![CDATA[注:本文只谈系统的可扩展点，并不涉及相关技术的具体实现。
可扩展性的定义特性: 1.系统可以容纳使用率的增加，可以简单的理解为用户数的增加2.系统可以容纳数据集的增加。3.系统可维护。
误区:
1.可扩展不是指原始速度，性能和可扩性是不同的问题2.可扩展性与是否选择某种语言无关。3.可扩展性与特定的技术是无关的。
扩展的几个方向与要点:
一,扩展硬件平台硬件扩展大体上可以分为两类：1.垂直扩展:原理：很简单当机器性能不足时买一台更大，更强，更猛的机器代替。优点:设计容易实现，只需在本地机器上构建系统。一定体系稳定，只要换好的机器就行。不足: 成本不是线性增加的，可能是指数级的。尽管你很有钱，不担心钱的问题,不过由于单台机器的能力有限的，那么这种模型最终会受到限制。2.水平扩展:原理:不断的增加更多的硬件,不同垂直扩展的是增长不需要超级强劲的机器，只要很多常规机器。优点:能够混用不同服务器并且能够配备最便宜服务器的应用程序，将一直保持成本上的优势。不足:添加减少机器可能比较容易，但不会过于简单.你将要花费大量的管理成本。3.冗余:不管是垂直扩展还是水平扩展，机器都有可能发生故障，这样的话给机器做完全热备是必要的，当一个组件故障时，其他组件自动接手它的工作。
二,负载平衡
1. DNS负载平衡这个最简单的平衡方案，同时存在不少的问题.1)做法:在 DNS中给一个域添加多个IP,这样请求域名解析的时候分随机的返回不同的IP地址实现平衡的目的2）问题： 更新dns的速度比较缓慢，如果要移除一台坏的机器比较的困难了,另一个问题就是无法实现精确控制，也不能定制化平衡。总得来说DNS负载不是一个好的方案。
2.VIP:这个名词比较有意思，记得有一回去yahoo,技术人员与我谈代码发布时谈到了VIP的一个问题，我就有点乱了，VIP===》贵宾？。还冒出了MVP之类的概念.：VIP是虚拟IP的意思，一个VIP是由负载平衡器提供的一个IP地址，背后其实有多个实际的IP地址在处理请求.负载平衡器也被称作虚拟服务器。
3.硬件方式的负载平衡:1)别名:web交换机,内容交换机,内容路由器.2)特点:非常的昂贵。
4.软件方式的负载平衡:1)前一段时间才知道lvs(http://www.linuxvirtualserver.org)是一个给linux打上内核补丁的负载平衡操作系统，不过lvs是为了处理极为复杂的负载情况，对于一般平衡就没有必要。
2)第四层与第7层负载平衡注意这个第字。刚接触的时候不理解，直接看成四层，与7层。呵呵，7层比4层多三层当然7层要牛很多。第7层的确比第4层更灵活，但原因绝对不是7比4大.第4层与第7层指的是网络分层.传统的负载平衡是在第四层处理的,用户的请求来源与目标IP地址与端口在这一层被捕获，有了这些信息就可以把这个连接引导到后台正常的端口上。最简单的第四层负载采用的是循环算法(round robin)。就是把请请求循环发送到生产服务器上。除了循环之外，也可以做随机算法。在两种方法中都可以加上权重，对权重比较高的生产服务器，只要有队列中重复出现几次那么被分配到流量的比重就越高。第7层负载比第4层负载出现的晚，它比第4层更加易活。因为第7层负载平衡器检测HTTP请求，这能够查看请求和请求的标头，并将这些信息纳入平衡策略的考虑中。这样就可以做基于URL平衡，可以确保对特定资源的所有请求都被调度到同一台机器上，这样的方便在同一台机器上做缓存，提高缓存命中率。这就是比第四层优秀的原因之一.听说apache的mod_rewrite模块加上一些脚本就可以做第7层的负载，具体我没有实施过，不过试过用ngnix做过第4层负载平衡，十分简单:)
三,扩展Mysql1.可以从主从(master-slave)复制方面考滤提高并行读写性能,当然选表的存储引引擎也很关键，MyISAM能非常快地进行读写操作，但是无法同时快速度的读写操作,而且也不支持事务操作，现在好像比较流行InnoDB。不过innoDB不提供fulltext索引,innoDB的占用的硬盘空间大约会是Myisam的3倍左右。
2.数据库分区也是数据库扩展的重要因素。不合理的数据库分区将会影响以后数据库的扩展.
四,缓存扩展在缓存的选择上我觉得分存式的缓存memcached(http://memcachedb.org/)是一个无可挑剔解决方案，可以解决大多数的问题
五,存储系统的扩展:&#160;目前只用过NFS,NFS在实际生产过程中还是存在很多不足。请各位有识之士,留下宝贵意见.!



]]></description>
		<wfw:commentRss>http://guogoul.com/2008/11/01/sys_web_extend/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
