易栈网-膘叔

想把自己所有的数据打个包，结果才发现，原来我的目录居然有30多G，把曾给卖给别人的空间中的19G数据清除后，发现还有12G的软件数据，惊讶的要死，去看了一下，用的是懒宝宝的告诉我的命令：du -sh /xxxxx/
发现mysql/data下的数据居然有12G，想着怎么也不可能会有这么大的数据啊？仔细一看，原来这12G全是log文件。找了一些资料，才把这个log清除掉。。
方法如下：
第一种技巧：

第二种技巧：

这两种情况都可以，比较偏 向于第一种，但我是因为要备份就直接用的第二种了。反正数据也没有出错过，资料来自于：http://www.tech-q.cn/thread-3198-1-1.html

昨天晚上asers.z问我怎么样使得数据在搜索的时候和58.com差不多，而且展示数据的速度要快。我一直想着用mysql的分区表解决，而乔楚（乔 大姐）则认为是采用sphinx来解决。
但后来我找了一个资料才发现，原来分区表还是有局限性的，比如他就不支持全文索引。我是看这里看到的。。

» 阅读全文

MYISAM和INNODB的争论由来已久，如今，我又找到两篇文章，让我们看看有关这两种引擎的优劣的文章：浅谈MySQL存储引擎选择 InnoDB还是MyISAM以及InnoDB还是MyISAM 再谈MySQL存储引擎的选择

第一篇：浅谈MySQL存储引擎选择 InnoDB还是MyISAM

作者：酷壳，来源于：http://database.51cto.com/art/200905/122382.htm

MyISAM 是MySQL中默认的存储引擎，一般来说不是有太多人关心这个东西。决定使用什么样的存储引擎是一个很tricky的事情，但是还是值我们去研究一下，这里的文章只考虑 MyISAM 和InnoDB这两个，因为这两个是最常见的。

下面先让我们回答一些问题：
◆你的数据库有外键吗？
◆你需要事务支持吗？
◆你需要全文索引吗？
◆你经常使用什么样的查询模式？
◆你的数据有多大？

思考上面这些问题可以让你找到合适的方向，但那并不是绝对的。如果你需要事务处理或是外键，那么InnoDB 可能是比较好的方式。如果你需要全文索引，那么通常来说 MyISAM是好的选择，因为这是系统内建的，然而，我们其实并不会经常地去测试两百万行记录。所以，就算是慢一点，我们可以通过使用Sphinx从 InnoDB中获得全文索引。

数据的大小，是一个影响你选择什么样存储引擎的重要因素，大尺寸的数据集趋向于选择InnoDB方式，因为其支持事务处理和故障恢复。数据库的在小 决定了故障恢复的时间长短，InnoDB可以利用事务日志进行数据恢复，这会比较快。而MyISAM可能会需要几个小时甚至几天来干这些事，InnoDB 只需要几分钟。

您操作数据库表的习惯可能也会是一个对性能影响很大的因素。比如： COUNT() 在 MyISAM 表中会非常快，而在InnoDB 表下可能会很痛苦。而主键查询则在InnoDB下会相当相当的快，但需要小心的是如果我们的主键太长了也会导致性能问题。大批的inserts 语句在MyISAM下会快一些，但是updates 在InnoDB 下会更快一些——尤其在并发量大的时候。

所以，到底你检使用哪一个呢？根据经验来看，如果是一些小型的应用或项目，那么MyISAM 也许会更适合。当然，在大型的环境下使用MyISAM 也会有很大成功的时候，但却不总是这样的。如果你正在计划使用一个超大数据量的项目，而且需要事务处理或外键支持，那么你真的应该直接使用InnoDB方 式。但需要记住InnoDB 的表需要更多的内存和存储，转换100GB 的MyISAM 表到InnoDB 表可能会让你有非常坏的体验。

第二篇：InnoDB还是MyISAM 再谈MySQL存储引擎的选择

作者：邵宗文，来源于：http://database.51cto.com/art/200905/124370.htm

两种类型最主要的差别就是Innodb 支持事务处理与外键和行级锁.而MyISAM不支持.所以MyISAM往往就容易被人认为只适合在小项目中使用。

我作为使用MySQL的用户角度出发，Innodb和MyISAM都是比较喜欢的，但是从我目前运维的数据库平台要达到需求：99.9%的稳定性，方便的扩展性和高可用性来说的话，MyISAM绝对是我的首选。

原因如下：

1、首先我目前平台上承载的大部分项目是读多写少的项目，而MyISAM的读性能是比Innodb强不少的。

2、MyISAM的索引和数据是分开的，并且索引是有压缩的，内存使用率就对应提高了不少。能加载更多索引，而Innodb是索引和数据是紧密捆绑的，没有使用压缩从而会造成Innodb比MyISAM体积庞大不小。

3、从平台角度来说，经常隔1，2个月就会发生应用开发人员不小心update一个表where写的范围不对，导致这个表没法正常用了，这个时候 MyISAM的优越性就体现出来了，随便从当天拷贝的压缩包取出对应表的文件，随便放到一个数据库目录下，然后dump成sql再导回到主库，并把对应的 binlog补上。如果是Innodb，恐怕不可能有这么快速度，别和我说让Innodb定期用导出xxx.sql机制备份，因为我平台上最小的一个数据 库实例的数据量基本都是几十G大小。

4、从我接触的应用逻辑来说，select count(*) 和order by 是最频繁的，大概能占了整个sql总语句的60%以上的操作，而这种操作Innodb其实也是会锁表的，很多人以为Innodb是行级锁，那个只是 where对它主键是有效，非主键的都会锁全表的。

5、还有就是经常有很多应用部门需要我给他们定期某些表的数据，MyISAM的话很方便，只要发给他们对应那表的frm.MYD,MYI的文件，让 他们自己在对应版本的数据库启动就行，而Innodb就需要导出xxx.sql了，因为光给别人文件，受字典数据文件的影响，对方是无法使用的。

6、如果和MyISAM比insert写操作的话，Innodb还达不到MyISAM的写性能，如果是针对基于索引的update操作，虽然MyISAM可能会逊色Innodb,但是那么高并发的写，从库能否追的上也是一个问题，还不如通过多实例分库分表架构来解决。

7、如果是用MyISAM的话，merge引擎可以大大加快应用部门的开发速度，他们只要对这个merge表做一些select count(*)操作，非常适合大项目总量约几亿的rows某一类型(如日志，调查统计)的业务表。

当然Innodb也不是绝对不用，用事务的项目如模拟炒股项目，我就是用Innodb的，活跃用户20多万时候，也是很轻松应付了，因此我个人也是很喜欢Innodb的，只是如果从数据库平台应用出发，我还是会首选MyISAM。

另外，可能有人会说你MyISAM无法抗太多写操作，但是我可以通过架构来弥补，说个我现有用的数据库平台容量：主从数据总量在几百T以上，每天十 多亿 pv的动态页面，还有几个大项目是通过数据接口方式调用未算进pv总数，(其中包括一个大项目因为初期memcached没部署,导致单台数据库每天处理 9千万的查询)。而我的整体数据库服务器平均负载都在0.5-1左右。

文章都不太长，适合着看看就行了。。

本以为自己用不上这类东西，因为自己的密码几乎都记得。然而经验是没有用的。我确实就忘记了密码。还好有google。找到了这篇：

可惜，在linux下好象不太正确。当然或许我用的是ubuntu的关系。。

找了一下，找不到safe_mysqld，于是我进入/etc/init.d/目录，打开mysql文件，查看了一下里面安全启动的文件发现居然是mysqld_safe。郁闷了一下。。。

作个笔记。

以前还真没有关注过这面的事情。自己在写的时候都是用了一个很简单的函数

但是这篇文章却告诉我，原来这三个函数的功能各有不同，前两个我当然知道，但如果没有加载mysql库，这两个功能是都用不上的，当然，现在有PDO的prepare然后setParam当然是很方便，mysqli函数也有这种功能。如果没有呢？怎么办？下面这篇文章告诉你上面三个函数的区别
来源：http://www.akii.org/2009-08/php-in-the-addslashes-mysql_real_escape_string-and-mysql_escape_string-the-difference-between/

SQL注入攻击是黑客攻击网站最常用的手段。如果你的站点没有使用严格的用户输入检验，那么常容易遭到SQL注入攻击。SQL注入攻击通常通过给站点数据库提交不良的数据或查询语句来实现，很可能使数据库中的纪录遭到暴露，更改或被删除。

为了防止SQL注入攻击，PHP自带一个功能可以对输入的字符串进行处理，可以在较底层对输入进行安全上的初步处理，也即Magic Quotes。(php.ini magic_quotes_gpc)。如果magic_quotes_gpc选项启用，那么输入的字符串中的单引号，双引号和其它一些字符前将会被自动加 上反斜杠\。

但Magic Quotes并不是一个很通用的解决方案，没能屏蔽所有有潜在危险的字符，并且在许多服务器上Magic Quotes并没有被启用。所以，我们还需要使用其它多种方法来防止SQL注入。

许多数据库本身就提供这种输入数据处理功能。例如PHP的MySQL操作函数中有addslashes()、 mysql_real_escape_string()、mysql_escape_string()等函数，可将特殊字符和可能引起数据库操作出错的字 符转义。那么这三个功能函数之间有什么却别呢？下面我们就来详细讲述下。

虽然国内很多PHP程序员仍在依靠addslashes防止SQL注入，还是建议大家加强中文防止SQL注入的检查。addslashes的问题在 于黑客 可以用0xbf27来代替单引号，而addslashes只是将0xbf27修改为0xbf5c27，成为一个有效的多字节字符，其中的0xbf5c仍会 被看作是单引号，所以addslashes无法成功拦截。

当然addslashes也不是毫无用处，它是用于单字节字符串的处理，多字节字符还是用mysql_real_escape_string吧。

另外对于php手册中get_magic_quotes_gpc的举例：
if (!get_magic_quotes_gpc()) {
$lastname = addslashes($_POST[‘lastname’]);
} else {
$lastname = $_POST[‘lastname’];
}
最好对magic_quotes_gpc已经开放的情况下，还是对$_POST[’lastname’]进行检查一下。

再说下mysql_real_escape_string和mysql_escape_string这2个函数的区别：
mysql_real_escape_string 必须在(PHP 4 >= 4.3.0, PHP 5)的情况下才能使用。否则只能用 mysql_escape_string ，两者的区别是：mysql_real_escape_string 考虑到连接的当前字符集，而mysql_escape_string 不考虑。

总结一下：

* addslashes() 是强行加\；
* mysql_real_escape_string()  会判断字符集，但是对PHP版本有要求；
* mysql_escape_string不考虑连接的当前字符集。