易栈网-膘叔

昨天晚上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不考虑连接的当前字符集。

没有了mysql我们还有什么？
其实没有了mysql还有很多数据库可用，有小型 的sqlite，有和mysql性能差不多的postgresql等

但mysql是用了最方便的。phpmyadmin使得许多不懂数据库的人也会操作了。。。

以下是原文 ：
来自于：http://www.cnbeta.com/articles/95165.htm

美国开源数据库厂商MySQL前CEO马顿·古斯塔夫·米科斯(Marten Gustaf Mickos)周四致信欧盟,要求欧盟尽快批准美国商用软件开发商甲骨文收购服务器和软件开发商Sun的交易.
2008年1月,MySQL被Sun收购,并成为后者数据库业务部门.甲骨文今年4月宣布,将以74亿美元收购Sun.此前Sun股东和美国司法部已批准该交易,但欧盟仍在对此展开反垄断调查.按照原定计划,欧盟将于明年1月19日宣布是否批准甲骨文-Sun交易.

米科斯周四在写给欧盟反垄断专员尼莉·克罗斯(Neelie Kroes)的信件中表示,欧盟对甲骨文收购Sun及其开源数据库软件是否将危害市场一事展开调查,这本身无疑是正确的决定,但甲骨文-Sun交易本身其实不会妨碍正常市场竞争.

米科斯在信中写道:“如果该交易存在不确定因素,将给Sun各项业务正常发展带来负面影响,同时使市场竞争程度有所降低.正因为如此,如果甲骨文-Sun交易被迫推迟,则其后果将同欧盟的良好愿望背道而驰.”

米科斯还在信中阐述了欧盟应尽早批准甲骨文-Sun交易的两大理由:1)与Sun当初收购MySQL后会继续保留后者业务一样,甲骨文完成同Sun交易 后,同样也会继续保留和进一步发展MySQL业务.2)退一步说,即使甲骨文今后对MySQL存在偏见(实际上不太可能),由于MySQL本身市场影响力 很大,因此甲骨文一家公司并不具备完全“扼杀”MySQL的能力.

业界人士表示,目前还不清楚米科斯提交这封信件后,是否会对欧盟的相应决定带来影响.但无论如何,作为MySQL的前CEO,米科斯对MySQL的具体业务可谓了如指掌.

此前米科斯已加盟美国风险投资机构Benchmark Capital.他近日在接受外界采访时表示,由于已经不再负责MySQL管理工作,因此甲骨文-Sun交易被批准后,自己并不会从交易中获得任何利益; 他之所以要致信欧盟,是想让Sun及MySQL部门员工受益.2008年Sun提出收购MySQL时,米科斯曾加以拒绝,但后来转变态度而答应Sun收购 请求.

甲骨文CEO拉里·埃里森(Larry Ellison)此前称,MySQL会在不同业务领域同甲骨文现有数据库产品争抢市场.他还表示,甲骨文今后不会把MySQL分拆为独立公司.