<?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://www.deepseath.com/?feed=rss2&#038;tag=mysql" rel="self" type="application/rss+xml" />
	<link>http://www.deepseath.com</link>
	<description></description>
	<lastBuildDate>Mon, 29 Jan 2024 09:55:11 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>[ERROR] Can&#8217;t open shared library &#8216;udf.dll&#8217; (errno: 0 )</title>
		<link>http://www.deepseath.com/?p=1161</link>
		<comments>http://www.deepseath.com/?p=1161#comments</comments>
		<pubDate>Tue, 10 Dec 2013 16:05:04 +0000</pubDate>
		<dc:creator>Deepseath</dc:creator>
				<category><![CDATA[日积月累]]></category>
		<category><![CDATA[MySQL]]></category>
		<category><![CDATA[升级]]></category>
		<category><![CDATA[数据库]]></category>
		<category><![CDATA[服务器]]></category>

		<guid isPermaLink="false">http://www.deepseath.com/?p=1161</guid>
		<description><![CDATA[有3个多月没写博客了，现在似乎越来越懒了:( 今天竟然忘记了登录密码，幸好，输入几次终于想起来了…… 如标题，[ERROR] Can&#8217;t open shared library &#8216;udf.dll&#8217; (errno: 0 ) 这是MySQL在启动时报的一个错误，在一个朋友的服务器上看到的，这个错误几乎已经持续了很久很久了，虽然报错，但似乎不影响使用，只不过，对于一个很洁癖的人来说，每次看到都很闹心。 之前曾经尝试过查找原因，包括建立plugin目录，以及遍历整个系统来查找udf.dll，都没什么结果。 也在谷歌和度娘上找过，说是什么提权文件，实话说，用了这么多年还真从来没听过这个功能……也按搜索到的文章操作过，但全部都是失败。 最后，考虑到可以尝试升级一下MySQL的版本（之前是5.0很早期的一个版本），由于系统还有很多不太熟悉的程序，所以为了考虑稳定性，所以只是升级到MySQL5.0的最后一个版本。 升级很简单，轻车熟路，一贯是我最懒人的做法： 1.由于想重新使用mysql的配置向导来配置my.ini所以，先将mysql的服务删除掉，命令行执行，mysqld-nt &#8211;remove即可。 2.不改变mysql的安装目录，因此，只需要将原来的安装目录改个名就行（权当备份了） 3.执行mysql安装程序，安装到之前的目录下。 4.执行mysql的配置向导，进行my.ini的配置。 5.手动打开my.ini，修改数据库文件储存目录变量“datadir”，修改为之前的数据库储存位置 6.重启mysql 升级操作就算完毕了，原来的帐号都可以继续使用，其他无须做什么改变。 回头再来看系统日志，发现一个很奇怪的现象，就是刚升级完启动mysql的时候那个错误是没有的，但改完数据库储存目录后再重启那个错误又出现了。 看来，这个错误本身应该还是来自于mysql数据库，而且只能是mysql自身的数据库（数据库名：mysql）， 于是，关闭mysql。 尝试将旧的mysql系统数据库（数据库名为mysql），改成其他名字，将新的mysql默认的系统数据库copy过来。 同时将旧系统数据库内的user表文件（三个）都覆盖到新系统数据库内。 这时候再启动mysql就不会有错误提示了。 查看了一下旧系统数据库表，发现其中一个数据表（mysql\func）里存在一条记录： mysql&#62; select * from func; +-------+-----+---------+----------+ &#124; name &#124; ret &#124; dl &#124; type &#124; +-------+-----+---------+----------+ &#124; baker &#124; 0 &#124; udf.dll &#124; function [...]]]></description>
		<wfw:commentRss>http://www.deepseath.com/?feed=rss2&#038;p=1161</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>MySQL5.0升级到5.5</title>
		<link>http://www.deepseath.com/?p=1056</link>
		<comments>http://www.deepseath.com/?p=1056#comments</comments>
		<pubDate>Wed, 08 Feb 2012 15:43:27 +0000</pubDate>
		<dc:creator>Deepseath</dc:creator>
				<category><![CDATA[日积月累]]></category>
		<category><![CDATA[MySQL]]></category>
		<category><![CDATA[代码]]></category>
		<category><![CDATA[升级]]></category>
		<category><![CDATA[数据库]]></category>
		<category><![CDATA[服务器]]></category>

		<guid isPermaLink="false">http://www.deepseath.com/?p=1056</guid>
		<description><![CDATA[服务器又出故障了，这次比较彻底——系统文件丢失:( 不得已重做了系统。 趁着这个重做系统，决定将MySQL自5.0升级到5.5。 先是安装MySQL，然后，配置my.ini，如果没特别需求的话，可以使用默认的就行，日后运行起来再根据具体情况进行优化。 关闭MySQL5.5。 将MySQL5.5默认安装的数据表进行备份（避免万一），然后将MySQL5.0的全部数据库文件直接Copy到MySQL5.5的数据库储存目录内。 此时如果你启动MySQL的话可能会看到类似 mysql.user has no `Event_priv` column at position 29 的错误（由于本文是在操作之后写的，具体的报错代码记的不是很清楚了……） 这是由于数据文件是MySQL5.0的，与标准的MySQL5.5数据文件格式不符，此时需要对数据进行升级操作。 先启动MySQL5.5 执行： mysql_upgrade 可能会有一些警告信息，可以忽略。 现在数据文件就升级完毕了，如果不太放心的话，可以执行： mysqlcheck -u root -p --databases [数据库名] 或者 mysqlcheck -u root -p --all-databases 检查具体的数据库文件状态。反正我全部执行了一下，没发现什么问题，MySQL5.5升级完毕^_^]]></description>
		<wfw:commentRss>http://www.deepseath.com/?feed=rss2&#038;p=1056</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>关于SQL注入的监测</title>
		<link>http://www.deepseath.com/?p=977</link>
		<comments>http://www.deepseath.com/?p=977#comments</comments>
		<pubDate>Mon, 26 Sep 2011 15:55:50 +0000</pubDate>
		<dc:creator>Deepseath</dc:creator>
				<category><![CDATA[程序人生]]></category>
		<category><![CDATA[Discuz]]></category>
		<category><![CDATA[MySQL]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[代码]]></category>
		<category><![CDATA[思路]]></category>

		<guid isPermaLink="false">http://www.deepseath.com/?p=977</guid>
		<description><![CDATA[网站被挂马，有一个方式就是对某个帐号进行提权操作，比如针对非管理用户提权至最高管理员的权限。 事后可以发现被提权的用户帐号，但检查经由哪个文件注入的是个麻烦的事情，特别是针对开源的文件结构比较复杂的程序来说。 以前有个思路，一直未实现，今天处理了一个，是针对Discuz!5.5（很老的一个版本了^^）的，处理思路就是事后诸葛亮。 对于此类的提权操作，其根本原因就是通过SQL去变更待提权的帐号的管理标识，如果程序对于涉及变更帐号权限的SQL查询都能有一个记录的话，这样日后一旦发现有未知的提权操作的时候便会相对容易的发现注入口是什么，大体也能进行应对处理，总比盲目的去查找注入文件要容易一些，当然，这个其实只是“事后诸葛亮”的做法，并不是根本的防御措施，真正想要防御其实还是程序开发的时候多考虑一些，比如，外部的输入要验证数据类型、进行字符转义等等，这不在本文讨论范围。 就Discuz!而言，所有的SQL操作都是经由数据类层进行操作的，这样就提供了一个比较方便的方式，我们可以在数据查询方法中加入一个判断，判断当前进行的操作是否是在更新用户表的权限字段，如果是，则记录下来相关的信息并保存到日志文件内，方便日后查询处理，针对Discuz!5.5我是按照如下的方式处理的，其实其他版本的Discuz!或者Discuz!X乃至其他类似的程序都可以利用这样的方式进行。 针对Discuz!5.5代码如下： &#60;?php /* @ By Deepseath 2011-09-26 @ 记录用户管理权限发生变动时的相关信息 */ if ( preg_match('/UPDATE\s+[`]*'.$GLOBALS['tablepre'].'members[`]*\s+SET(.+)/is',$sql,$match) &#38;amp;&#38;amp; preg_match('/[`]*\s*adminid[`]*\s*=\s*/is',$match[1],$m) ) { //判断当前执行语句是否为members表包含adminid的更新 $sql_md5 = md5($sql);//唯一查询md5值 $logfile = DISCUZ_ROOT.'./forumdata/log_adminid/'.$sql_md5.'.log';//日志储存的文件 if ( !file_exists($logfile) &#124;&#124; time() - filemtime($logfile) &#38;gt; 1800 ) { //如果查询日志文件不存在或者日志文件距离当前时间超过1800秒，则记录查询日志 if ( !is_dir(DISCUZ_ROOT.'./forumdata/log_adminid/') ) { //日志目录不存在则创建 @mkdir(DISCUZ_ROOT.'./forumdata/log_adminid/',0777,true); } if ( $fp = @fopen($logfile,'ab') ) [...]]]></description>
		<wfw:commentRss>http://www.deepseath.com/?feed=rss2&#038;p=977</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>MySQL报错Errcode: 28</title>
		<link>http://www.deepseath.com/?p=973</link>
		<comments>http://www.deepseath.com/?p=973#comments</comments>
		<pubDate>Fri, 23 Sep 2011 15:50:23 +0000</pubDate>
		<dc:creator>Deepseath</dc:creator>
				<category><![CDATA[程序人生]]></category>
		<category><![CDATA[MySQL]]></category>
		<category><![CDATA[WinXP]]></category>

		<guid isPermaLink="false">http://www.deepseath.com/?p=973</guid>
		<description><![CDATA[在对大数据进行查询操作（比如，排序操作）时候，有时候会有类似：Error writing file &#8216;x:/tmp/xxxx.tmp&#8217; (Errcode: 28)的错误提示。 今天在对多达120W的数据表进行全表排序的时候报的类似这样的错误。X的磁盘分区的权限没有问题，读写都很正常，唯一觉得有点问题的是空间比较小。机器装的是4G的内存，但使用的是WinXP32位版本，因此浪费掉了1G，为了节省磁盘写入量，我将多出的那1G内存利用工具当做一个磁盘来使用，将系统临时文件目录以及浏览器缓存文件存放于这里。正常使用一般是没什么问题的。但做这个大表扫描的时候导致空间不足。 现在的解决办法要么就是清理一下磁盘，但由于表太大了，恐怕着1G的容量全部使用也不会够的。 要么就是将系统的临时目录更改到一个新的大容量分区内，不过，这样做有点背离我要利用空闲的那1G的内存了，再说，还要重启机器。 看了看mysql的环境变量，发现有一个变量的目录就是X:，于是，直接编辑MySQL的配置文件my.ini，加入一行： tmpdir=”F:/MySQL_Data/Tmp/” 这样的话就是告诉MySQL，临时文件存放的路径。MySQL的tmpdir变量如果没有设置的话会自动以当前操作系统的临时目录作为自己的暂存目录。 重启mysql后问题解决。]]></description>
		<wfw:commentRss>http://www.deepseath.com/?feed=rss2&#038;p=973</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>建议所有的程序开发者一起来保护MySQL——《拯救MySQL》</title>
		<link>http://www.deepseath.com/?p=584</link>
		<comments>http://www.deepseath.com/?p=584#comments</comments>
		<pubDate>Wed, 20 Jan 2010 02:45:09 +0000</pubDate>
		<dc:creator>Deepseath</dc:creator>
				<category><![CDATA[程序人生]]></category>
		<category><![CDATA[MySQL]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[开发]]></category>
		<category><![CDATA[拯救MySQL]]></category>
		<category><![CDATA[数据库]]></category>

		<guid isPermaLink="false">http://www.deepseath.com/?p=584</guid>
		<description><![CDATA[对于其他程序不甚了解，但就PHP开发来说，估计99%的人都选择MySQL作为数据库，因为MySQL给大家的印象是轻巧、易用并且最重要的是它有一个免费的社区版本，这个版本同它收费版本是完全一样的区别仅在于它的商业版本提供技术服务而已。 作为一个PHPer来说，我自2000年接触PHP，因为没有任何程序语言基础，所以学习起来挺费劲，一直使用文本储存数据，但真的觉得既麻烦又不安全，然后2001年年初的时候第一次开始接触MySQL，对于我无任何数据库语言概念的人来说上手的确有一点点困难，但我清晰的记得，看完了几个例子以后，我便轻松的了解了MySQL知道了它的强大、易用，而且最主要的是它不像Orlce和SQL Server，它是免费的！！ 自那个时候起，我慢慢开始了解了这世上还有一些人，在维护着PHP、维护着MySQL、维护着Apache，我知道了一个名词“开源社区”，知道了还有一个免费的操作系统Linux ，知道这世界上还有一群具有创新、共享精神的人…… 到现在，熟练使用并在自己项目上应用部署MySQL已经有接近8年的时间了，从MySQL4.0用到MySQL5.1，这个过程是很奇妙的，我从未担心过什么，因为我知道MySQL精神会继续着 …… 突然有一天，我知道了那个卖得很贵的数据库Orcal的东家甲骨文开始“惦记”着MySQL了 ，就我个人的感觉来说，这不是什么好事，如果这个公司或者其他别有用心的公司去收购MySQL，那么可能会带来的两种情况就是：1.为了维护其自身收费的数据库产品，势必会打压MySQL的开发，致使MySQL慢慢落后于其他数据库，导致它的淘汰；2.将MySQL也变成一个完全收费的产品。我个人可能更容易想到第一种情况，如果是那样，那真的是一个灾难…… 为此，包括MySQL的创始人Michael Widenius在内的一些人组织了一个《拯救MySQL》的活动，请求所有MySQL的支持者支持和保护MySQL。 刚刚也在上面签名了，做为能力有限的支持者来说，我也许只能做到这些了。 希望支持MySQL的朋友们，一起来救救MySQL，点击进入这个链接填写表单就可以了：http://www.helpmysql.org/cn/petition 不要害怕E文，呵呵，是多语言的，我给的连接是中文版的^_^]]></description>
		<wfw:commentRss>http://www.deepseath.com/?feed=rss2&#038;p=584</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>MySQL字段的取值范围</title>
		<link>http://www.deepseath.com/?p=570</link>
		<comments>http://www.deepseath.com/?p=570#comments</comments>
		<pubDate>Thu, 24 Dec 2009 02:07:13 +0000</pubDate>
		<dc:creator>Deepseath</dc:creator>
				<category><![CDATA[日积月累]]></category>
		<category><![CDATA[MySQL]]></category>
		<category><![CDATA[字段]]></category>
		<category><![CDATA[开发]]></category>
		<category><![CDATA[数据库]]></category>

		<guid isPermaLink="false">http://www.deepseath.com/?p=570</guid>
		<description><![CDATA[设计数据库的时候会为表中涉及到的字段设定一个范围，如果不考虑这个取值范围可能会对未来的运营产生或者性能问题或者数据问题。如果实际的取值大于设计的取值则会造成数据无效或丢失导致程序出错，如果实际的取值小于设计的取值虽然不会对程序产生什么错误，但会白白的浪费储存空间导致性能问题。 MySQL的字段包括： TINYINT、SMALLINT、MEDIUMINT、INT、INTEGER、BIGINT。 FLOAT、DOUBLE、DOUBLE PRECISION、REAL、DECIMAL[(M,[D])]、NUMERIC(M,D)。 DATE、DATETIME、TIMESTAMP、 TIME、YEAR[(2&#124;4)]。 CHAR(M) [BINARY]、NCHAR(M) [BINARY]、[NATIONAL] VARCHAR(M) [BINARY]、TINYBLOB、TINYTEXT、BLOB、TEXT、MEDIUMBLOB、MEDIUMTEXT、LONGBLOB、LONGTEXT。 ENUM、SET。 列表显示一下它们的取值范围，常备常查^_^ TINYINT -128 至 127 TINYINT UNSIGNED 0 – 255 SMALLINT -32768 至 32767 SMALLINT UNSIGNED 0 至 65535 MEDIUMINT -8388608 至 8388607 MEDIUMINT UNSIGNED 0 至 16777215 INT 或 INTEGER -2147483648 至 2147483647 INT UNSIGNED 或 INTEGER UNSIGNED 0 至 4294967295 [...]]]></description>
		<wfw:commentRss>http://www.deepseath.com/?feed=rss2&#038;p=570</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>再遇MySQL4.0升级到MySQL5.1的时候</title>
		<link>http://www.deepseath.com/?p=459</link>
		<comments>http://www.deepseath.com/?p=459#comments</comments>
		<pubDate>Tue, 28 Apr 2009 03:33:51 +0000</pubDate>
		<dc:creator>Deepseath</dc:creator>
				<category><![CDATA[程序人生]]></category>
		<category><![CDATA[backup file]]></category>
		<category><![CDATA[database name]]></category>
		<category><![CDATA[mydatabase]]></category>
		<category><![CDATA[MySQL]]></category>
		<category><![CDATA[mysqldump]]></category>
		<category><![CDATA[升级]]></category>
		<category><![CDATA[朋友]]></category>
		<category><![CDATA[服务]]></category>
		<category><![CDATA[服务器]]></category>

		<guid isPermaLink="false">http://www.deepseath.com/?p=459</guid>
		<description><![CDATA[已经好久没搞过MySQL4.0升级到MySQL4.1/MySQL5.0/MySQL5.1的操作了。昨天晚上一个朋友的服务器有几个数据库需要做这样的操作。 冷不丁再遇到这样的情况的确有点楞，不过好在之前他打过招呼，我也测试过 ，所以升级过程没遇到大问题，比较成功。 发现记性不如以前那么好了，记下来操作过程留住备忘吧。 MySQL4.0升级到MySQL4.1+版本主要的情况其实就是字符集的问题，不能像原来的平行版本升级那样直接将数据库目录Copy就可以了。 首先要确认数据库的字符集是哪种，一般来说，就是考虑utf-8和非utf-8的情况。 无论哪种字符集，只要确定了，就在高版本mysql内 建立一个相应字符集的数据库。 在mysql4.0这边，直接使用mysqldump导出，数据多的话，最好选择扩展插入方式导出：mysqldump &#8211;opt -u[DB USER] -p[DB PASSWORD] [DATABASE NAME] &#62; [BACKUP FILE PATH] 比如： mysqldump &#8211;opt -u user -p password MyDATABASE &#62;f:/MyDATABASE_40.sql 这样就将mysql4.0的数据导出SQL文件了。 然后使用命令行方式登录mysql4.1+，进入要导入的数据库： use MyDATABASE; SET NAMES &#8216;你所设置的字符集&#8217;; source f:/MyDATABASE_40.sql 这样大体上就可以顺序导入了，字符集也没什么问题。不过实际运行中偶尔会出现某些表导入不成功的情况，原因没深究，因为发生的几率很小，涉及的数据也比较少，所以出错后，直接再把没导入的表重新导入就可以了^_^]]></description>
		<wfw:commentRss>http://www.deepseath.com/?feed=rss2&#038;p=459</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>error 1030 got error 127 from table handler</title>
		<link>http://www.deepseath.com/?p=402</link>
		<comments>http://www.deepseath.com/?p=402#comments</comments>
		<pubDate>Tue, 11 Nov 2008 08:06:37 +0000</pubDate>
		<dc:creator>Deepseath</dc:creator>
				<category><![CDATA[日积月累]]></category>
		<category><![CDATA[MYI]]></category>
		<category><![CDATA[myisamchk]]></category>
		<category><![CDATA[MySQL]]></category>
		<category><![CDATA[OPTIMIZE]]></category>
		<category><![CDATA[shell]]></category>

		<guid isPermaLink="false">http://www.deepseath.com/?p=402</guid>
		<description><![CDATA[转自网络，修复损坏的数据表。我的经验是，修复大数据的时候最好将mysql关闭或者避免有其他应用程序正在访问数据表。否则有可能造成不必要的麻烦，我经历过那种恶梦……:( 问题： &#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;     在使用mysql的过程中,机器重启后     使用一个表,提示 error 1030 got error 127 from table handler &#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;- 解决方案： &#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;- 其实就是将损坏的表进行修复。 1,简单的修复模式myisamchk -r -q path/数据库/坏表.MYI 注:-r     &#8212;-恢复模式     -q     &#8212;-快速修复 2,使用安全修复模式 myisamchk &#8211;safe-recover path/数据库/坏表.MYI 3,困难的修复模式 如果在索引文件的第一个16K块被破坏，或包含不正确的信息，或如果索引文件丢失，你只应该到这个阶段 。在这种情况下，创建一个新的索引文件是必要的。按如下这样做： 把数据文件移更安全的地方。 使用表描述文件创建新的(空)数据和索引文件： shell&#62; mysql db_name mysql&#62; DELETE FROM tbl_name; mysql&#62; quit 将老的数据文件拷贝到新创建的数据文件之中。（不要只是将老文件移回新文件之中；你要保留一个副本以防某些东西出错。） 回到阶段2。现在myisamchk -r -q应该工作了。（这不应该是一个无限循环)。 4,非常困难的修复模式 只有描述文件也破坏了，你才应该到达这个阶段。这应该从未发生过，因为在表被创建以后，描述文件就不再改变了。 从一个备份恢复描述文件并且回到阶段3。你也可以恢复索引文件并且回到阶段2。对后者，你应该用myisamchk -r启动。 如果你没有一个备份但是确切地知道表是怎样被创建的，在另一个数据库中创建表的一个拷贝。删除新的数据文件，然后从其他数据库将描述和索引文件移到破坏的数据库中。这给了你新的描述和索引文件，但是让数据文件独自留下来了。回到阶段2并且尝试重建索引文件。 5,优化表结构 [...]]]></description>
		<wfw:commentRss>http://www.deepseath.com/?feed=rss2&#038;p=402</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>memcache是个好东西</title>
		<link>http://www.deepseath.com/?p=389</link>
		<comments>http://www.deepseath.com/?p=389#comments</comments>
		<pubDate>Wed, 05 Nov 2008 03:32:25 +0000</pubDate>
		<dc:creator>Deepseath</dc:creator>
				<category><![CDATA[程序人生]]></category>
		<category><![CDATA[memcache]]></category>
		<category><![CDATA[MySQL]]></category>
		<category><![CDATA[PHP]]></category>
		<category><![CDATA[底层]]></category>
		<category><![CDATA[技术]]></category>

		<guid isPermaLink="false">http://www.deepseath.com/?p=389</guid>
		<description><![CDATA[　标题是个废话，不好就不会有那么多人用了。 　一直在考虑利用PHP+mysql自己架构一个简单的类似memcache的简单应用，原理比较简单，基本可实现缓存的键值分配、过期的设置、数据的存储等等。功能上无非就是写入和读取。简单点说其实也就是利用一个查询的集去写入缓存。每次查询到公共部分的时候直接获取结果。这样虽然也是要经过数据库查询，但对于某些多次进行的相同查询的时候效果也是比较明显的。当然不会有类似memcache的分布式架构，仅仅是一个小型的应用，适用于不方便安装memcache的时候。属于项目级的一个数据层的小型缓存机制。可惜无法理解底层的内存操作技术，否则直接写入到内存可能效果会非常好，因为基于的功能仅仅为读、写没有memcache那么复杂的应用，应该效果会好一些^_^ 　尝试写了一下感觉还不错，呵呵，对于小型的项目应用自信还可以应付。最近状态不错。继续加油～～忙完手里的项目赶快忙自己的……]]></description>
		<wfw:commentRss>http://www.deepseath.com/?feed=rss2&#038;p=389</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>MySQL报错“Got a packet bigger than &#8216;max_allowed_packet&#8217; bytes”</title>
		<link>http://www.deepseath.com/?p=281</link>
		<comments>http://www.deepseath.com/?p=281#comments</comments>
		<pubDate>Wed, 27 Aug 2008 09:09:32 +0000</pubDate>
		<dc:creator>Deepseath</dc:creator>
				<category><![CDATA[程序人生]]></category>
		<category><![CDATA[max]]></category>
		<category><![CDATA[MySQL]]></category>
		<category><![CDATA[pack]]></category>
		<category><![CDATA[packet]]></category>

		<guid isPermaLink="false">http://www.deepseath.com/?p=281</guid>
		<description><![CDATA[在导入MySQL数据的时候发现会出现这样的报错信息。 “Got a packet bigger than &#8216;max_allowed_packet&#8217; bytes” 看手册了解到这个应该是当前导入的数据大于系统的限制的最大包大小。 也许插入的数据太大了，不过因为当前做的项目不可避免会遇到这个大数据插入的情况，因此只能更改MySQL的默认配置。 暂时加大到10M，即在MySQL配置文件中加入一个参数（如果已经存在这个参数那么就修改）： max_allowed_packet=10485760 我这里写的单位是字节，换算过来就是10M，当然为了直观也可以直接等于10M 希望这个数值应该够用了，呵呵。]]></description>
		<wfw:commentRss>http://www.deepseath.com/?feed=rss2&#038;p=281</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>MySql索引优化注意</title>
		<link>http://www.deepseath.com/?p=245</link>
		<comments>http://www.deepseath.com/?p=245#comments</comments>
		<pubDate>Mon, 04 Aug 2008 08:05:43 +0000</pubDate>
		<dc:creator>Deepseath</dc:creator>
				<category><![CDATA[日积月累]]></category>
		<category><![CDATA[MySQL]]></category>

		<guid isPermaLink="false">http://www.deepseath.com/?p=245</guid>
		<description><![CDATA[搜索的时候发现的，挺有用的转过来备记一下。 设计好MySql的索引可以让你的数据库飞起来，大大的提高数据库效率。设计MySql索引的时候有一下几点注意： 1，创建索引 对于查询占主要的应用来说，索引显得尤为重要。很多时候性能问题很简单的就是因为我们忘了添加索引而造成的，或者说没有添加更为有效的索引导致。如果不加索引的话，那么查找任何哪怕只是一条特定的数据都会进行一次全表扫描，如果一张表的数据量很大而符合条件的结果又很少，那么不加索引会引起致命的性能下降。但是也不是什么情况都非得建索引不可，比如性别可能就只有两个值，建索引不仅没什么优势，还会影响到更新速度，这被称为过度索引。 2，复合索引 比如有一条语句是这样的：select * from users where area=’beijing’ and age=22; 如果我们是在area和age上分别创建单个索引的话，由于mysql查询每次只能使用一个索引，所以虽然这样已经相对不做索引时全表扫描提高了很多效率，但是如果在area、age两列上创建复合索引的话将带来更高的效率。如果我们创建了(area, age, salary)的复合索引，那么其实相当于创建了(area,age,salary)、(area,age)、(area)三个索引，这被称为最佳左前缀特性。因此我们在创建复合索引时应该将最常用作限制条件的列放在最左边，依次递减。 3，索引不会包含有NULL值的列 只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。 4，使用短索引 对串列进行索引，如果可能应该指定一个前缀长度。例如，如果有一个CHAR(255)的 列，如果在前10 个或20 个字符内，多数值是惟一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。 5，排序的索引问题 mysql查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。 6，like语句操作 一般情况下不鼓励使用like操作，如果非使用不可，如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。 7，不要在列上进行运算 select * from users where YEAR(adddate)&#60;2007;将在每个行上进行运算，这将导致索引失效而进行全表扫描，因此我们可以改成select * from users where adddate&#60;‘2007-01-01’; 8，不使用NOT IN和&#60;&#62;操作 NOT IN和&#60;&#62;操作都不会使用索引将进行全表扫描。NOT IN可以NOT EXISTS代替，id&#60;&#62;3则可使用id&#62;3 or id&#60;3来代替。]]></description>
		<wfw:commentRss>http://www.deepseath.com/?feed=rss2&#038;p=245</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>系统性能相关的MySQL变量</title>
		<link>http://www.deepseath.com/?p=223</link>
		<comments>http://www.deepseath.com/?p=223#comments</comments>
		<pubDate>Sat, 12 Jul 2008 11:28:03 +0000</pubDate>
		<dc:creator>Deepseath</dc:creator>
				<category><![CDATA[日积月累]]></category>
		<category><![CDATA[cache size]]></category>
		<category><![CDATA[memory]]></category>
		<category><![CDATA[MySQL]]></category>
		<category><![CDATA[server variables]]></category>
		<category><![CDATA[服务器]]></category>

		<guid isPermaLink="false">http://www.deepseath.com/?p=223</guid>
		<description><![CDATA[来自:http://forge.mysql.com/wiki/ServerVariables Memory-Related Variables 内存相关变量 These server variables control the amount of memory allocated to the various buffers and caches within MySQL. 以下这些服务器变量控制这MySQL分配给各种缓冲或者换缓存的内存总数。 join_buffer_size (PER SESSION) Controls the amount of memory allocated to perform joins on tables that have no keys which can be used to perform a condition filter. Allocated for each table joined without [...]]]></description>
		<wfw:commentRss>http://www.deepseath.com/?feed=rss2&#038;p=223</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>在SELECT语句中同时使用COUNT和DISTINCT</title>
		<link>http://www.deepseath.com/?p=128</link>
		<comments>http://www.deepseath.com/?p=128#comments</comments>
		<pubDate>Thu, 13 Mar 2008 14:40:57 +0000</pubDate>
		<dc:creator>Deepseath</dc:creator>
				<category><![CDATA[程序人生]]></category>
		<category><![CDATA[MySQL]]></category>
		<category><![CDATA[SQL]]></category>

		<guid isPermaLink="false">http://www.deepseath.com/?p=128</guid>
		<description><![CDATA[SELECT COUNT(列名)…… 或 SELECT DISTINCT…… 如果需要同时使用COUNT和DISTINCT，应该这样写： SELECT COUNT(DISTINCT 列名)…… 其中，“列名”不能使用*，至少要给出一个列的名称。]]></description>
		<wfw:commentRss>http://www.deepseath.com/?feed=rss2&#038;p=128</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>MySQL优化的想法</title>
		<link>http://www.deepseath.com/?p=4</link>
		<comments>http://www.deepseath.com/?p=4#comments</comments>
		<pubDate>Tue, 15 Jan 2008 08:50:16 +0000</pubDate>
		<dc:creator>Deepseath</dc:creator>
				<category><![CDATA[程序人生]]></category>
		<category><![CDATA[MySQL]]></category>
		<category><![CDATA[服务器]]></category>

		<guid isPermaLink="false">http://www.deepseath.com/?p=4</guid>
		<description><![CDATA[MyISAM表个人觉得有几个参数：
key_buffer_size,query_cache_size,table_cache
对于性能影响很大。

首先是key_buffer_size，这个是设置数据索引缓存区的大小的。从这个意思上就大体明白他的作用了。大量的数据是靠索引进行快速检索的，而索引利用的好与坏就取决于这个参数的设置。那么如何判断这个参数设置是否合理呢？第一，这个参数的意思就很明确了它是索引的缓存区，所以大的值至少应该是数据库中所有数据表索引容量的大小即所有数据库中所有的*.MYI的大小总和，在不确定什么值是比较合适的，那么设置这个值应该是最保守的了。当然随着数据量增加索引的容量也势必会增加，因此我觉得应该将这个值设置当前所有索引文件总量的1.5倍为好如果内存很大甚至可以设置为2～2.5倍。设置完毕重起服务生效后。可以通过mysql运行状态中的两个值来判断设置的是否合理，这两个参数值是：Key_read_requests和Key_reads，一般认为Key_read_requests的值应该至少是Key_reads的100倍左右，这样才能达到好的性能，如果能达到1000倍以上那就更好了。
]]></description>
		<wfw:commentRss>http://www.deepseath.com/?feed=rss2&#038;p=4</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
