Chinaunix

标题: 如何使用InnoDB存储引擎？《MySQL 技术内幕：InnoDB存储引擎》有奖试读名单公布！ [打印本页]

作者: linux1689 时间: 2010-11-25 17:09
这个活动必须支持一下，这本书也要支持！

晕倒，我居然坐到沙发了，泪奔！

作者: to407 时间: 2010-11-25 23:24
板凳咩。。。

我觉得MySQL很优秀的一点，是他的生命力，包括这一两年仍然持续的强势，并没有因为外部的影响而让MySQL发展放慢。
国内多出这样的书很好，因为MySQL开源有一个优势，那就是学习者可以把源代码拿过来，有改进的空间。
看到样章里有接触到了源代码的分析，蛮好的。这对于推广国内MySQL学习和使用环境都有好处，哈哈。

加油，goodluck

作者: renxiao2003 时间: 2010-11-26 09:49
支持一下。虽然上次MYSQL的提问的活动还没有开奖。呵呵。

作者: expert1 时间: 2010-11-26 09:50
牛人真多啊

作者: surpass_li 时间: 2010-11-26 10:50
本帖最后由 surpass_li 于 2010-11-26 10:51 编辑

InnoDB 被设计成适用于高并发读写的情况 .使用MVCC(Multi-Version Concurrency Control)以及行级锁来提供遵从ACID的事务支持。InnoDB支持外键参照完整性，具备故障恢复能力。另外 InnoDB的性能其实还是不错的，特别是在处理大数据量的情况下,用官方的话说就是： InnoDB的CPU效率是其他基于磁盘的关系数据库存储引擎所不能比的。

不过InnoDB的备份恢复要麻烦一点，除非你使用了4.1以后版本提供的 Mulit-tablespace支持，因为InnoDB和MyISAM不同，他的数据文件并不是独立对应于每张表的。
而是使用的共享表空间，简单的拷贝覆盖方法对他不适用，必须在停掉MYSQL 后对进行数据恢复。使用Per-Table Tablespacesd，使其每张表对应一个独立的表空间文件，则情况要简单很多。

一般来说，如果需要事务支持，并且有较高的并发读写频率，InnoDB是不错的选择。

作者: ecjtubaowp 时间: 2010-11-26 11:55
对mysql目前只限于使用，没有深入，哎。

作者: 小-菜鸟 时间: 2010-11-26 12:11
书给我把，我正在学mysql

作者: linuxsir1987 时间: 2010-11-26 14:59

太高兴了！已经在pub-china里面订购～哈哈

作者: yahoon 时间: 2010-11-26 17:31
个人感觉InnoDB的性能好但是维护成本较大
由于默认采用是将所有数据(所有InnoDB表)都放到一个文件ibdata里面

如果文件损坏,会直接导致所有数据破坏,甚至连mysql服务都无法启动

对于myisam引擎有myisamchk 可以对表进行修复
一定程度上方便了数据的恢复操作

InnoDB有类似的工具不..

小弟对mysql研究不深,见笑..

作者: starzhestarzhe 时间: 2010-11-26 17:47
对于innodb,我们目前的项目并没有用,但是前一个公司都用的innodb,怎么说呢,性能要求并不是特别高,全用innodb+外键保存数据完整性,程序上省了很多事.
个人觉得采用myisam与innodb结合的方式会带来一定的副面影响,因为外键有时候起不了什么作用,但是对于数据操作频率比较频繁的表,用innodb的优势是比较明显的

作者: rubylc_unix 时间: 2010-11-27 10:57
支持{:3_189:}

作者: starzhestarzhe 时间: 2010-11-27 12:35
刚查到一个东西,

InnoDB表的行锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如update table set num=1 where name like “%aaa%”

作者: 拿钱发帖死全家 时间: 2010-11-27 14:31
没用过MYSQL的飘过~

作者: yahoon 时间: 2010-11-27 14:33
本帖最后由 yahoon 于 2010-11-27 14:35 编辑

刚读第一节就不懂了
关于库和实例的定义
书上写的对二者的定义是作者自己定义的吗?还是从哪里引用的?

在mysql的相关文档中
实例是被定义为一个独立的mysql server进程吧....
而数据库的定义,很宽泛吧,不同的context下,意义不同.可以是server,process,file,某个特定名称的库,甚至整个系统,都被称之为数据库

作者: dooros 时间: 2010-11-27 14:42
支持

作者: G65535 时间: 2010-11-27 19:39
这个太专业了，目前自学还处在基本功能部分。。。。

作者: motorocke6 时间: 2010-11-28 13:24
个人认为InnoDB只是花心的MySQL现阶段青睐的一个存储引擎，之所以成为目前MySQL所发行新版的标准，较之于其它的存储引擎它的优点就是其支持兼容ACID的事务,以及参数完整性即对外键的支持。
innodb的灾难恢复比之前的mysiam优秀很多，且mysiam不支持事务，这点是致命的。
不过google等大公司都使用了innodb作为解决方案之一，我想用innodb做存储引擎应该是经过深思熟虑做出的决定。
InnoDB在技术上是一套放在MySQL后台的完整数据库系统，它在主内存中建立其专用的缓冲池用于高速缓冲数据和索引，从而可以很有效的使用大量的内存。
但InnoDB也有硬伤,比如它的磁盘性能就很令人担心，MySQL缺乏良好的tablespace真是天大的缺陷！如果你测试InnoDB下的Insert/Update/Remove性能绝对让你抓狂，Cache只能解决小数据量的问题，大数据量是不够的，没经历过导入几百万条InnoDB数据到最后看着文件尺寸100KB 100KB的增长，是没法体会痛苦的。
百万行记录插入之后，插入速度下降到了之前的1/30，从开始的1600行/秒衰退到50行/秒，同样的测试环境下，MyISAM没有这样的问题，InnoDB的Roadmap对此问题的时间表是“Long Term”。
MySQL InnoDB只有在满足以下条件下：不需要经常修改表结构，没有经常性的bulk insert和载入数据需求，在没有blob/text字段的前提下，index设置合理比如经常插入就减少 index, 经常查询就增加index，千万级别的插入速度和性能才能稳定。
在主流服务器上插入速度可以达到500 ~ 1000 行每秒，这个是本人实践过后得到的经验，如果你有这方面的需求，那就可以大胆的用MySQL InnoDB，真的很爽！！
如果大家对千万级别记录的表有经常的alter index, alter table, load data, bulk insert的需求，那最好可以选择其他存储引擎，当然也可以考虑使用其他数据库。

作者: 蓝色虫 时间: 2010-11-29 20:15
做MySQL 8、9年了

刚才自己算算时间没想到自己也有这么长的毅力

inno存储格式要跟oracle比还有很长的路走虚心向oracle学习吧

不过我觉得MySQL最擅长事务型存储，数据库在windows、linux、bsd、solaris系统很稳定、速度快，一点不夸张的说，我觉得oracle数据库根本无法达到MySQL这样的性能

另外，oracle有自己的client端，配置相关功能很直观；而MySQL客户端软件多数是第三方软件公司开发，性能差距很大，有的只是支持欧洲字码格式，导致很多用户的inno格式存储的内容呈现乱码，这些天我就在为一个深圳客户调试vtigercrm项目，遇到此类现象。

不管怎么说，innoDB存储引擎还算稳定，如果买了官方技术支持，解决一些中小企业的数据库需求还是足够了

作者: renxiao2003 时间: 2010-11-30 09:05
其实MYSQL在SUN被ORACLE收购之前，对开源数据库社区的贡献还是很大的。特别是在中国，很多不愿意花钱的网站都在使用MYSQL。MYSQL安装简单，操作方便，支持快速查询，在大量访问的网站上显得更是优秀。
MYSQL发展也是很快。我记得在被收购之前MYSQL好像已经出了6.0BETA版本。但是自从MYSQL被ORACLE收购后，感觉MYSQL的发展就停滞不前了啊。现在在官网上不仅被加上了ORACLE的LOG，而且版本也更新得及其的慢，现在还只是5.X版本，原来的6.0版本已经取消了。不知道MYSQL的明天会如何，相反的是另一个开源的PG却发展得信息论愉了。

作者: starzhestarzhe 时间: 2010-11-30 10:28
mysql 99%应该还是用在b/s应用程序上

作者: yahoon 时间: 2010-11-30 15:16
mysql客户端字符集确实是一个很大的问题
感觉定义起来几个变量的值比较含糊,容易搞混

尤其是客户端软件的标准不一致导致乱码问题常常出现

这当然不是InnoDB的问题

Mysql现在的开发进度确实已经不如往昔了,未来很悬

作者: starzhestarzhe 时间: 2010-11-30 15:28
客户端软件,开发的时候一直用phpmyadmin,感觉其他的速度都太慢

作者: renxiao2003 时间: 2010-11-30 16:00
我想，InnoDB相对于MYSQL的重要性。最主要的是体现在“InnoDB给MySQL提供了具有提交，回滚和崩溃恢复能力的事务安全（ACID兼容）存储引擎。”
下面是官方的描述：
InnoDB给MySQL提供了具有提交，回滚和崩溃恢复能力的事务安全（ACID兼容）存储引擎。InnoDB锁定在行级并且也在SELECT语句提供一个Oracle风格一致的非锁定读。这些特色增加了多用户部署和性能。没有在InnoDB中扩大锁定的需要，因为在InnoDB中行级锁定适合非常小的空间。InnoDB也支持FOREIGN KEY强制。在SQL查询中，你可以自由地将InnoDB类型的表与其它MySQL的表的类型混合起来，甚至在同一个查询中也可以混合。

InnoDB是为处理巨大数据量时的最大性能设计。它的CPU效率可能是任何其它基于磁盘的关系数据库引擎所不能匹敌的。

InnoDB存储引擎被完全与MySQL服务器整合，InnoDB存储引擎为在主内存中缓存数据和索引而维持它自己的缓冲池。InnoDB存储它的表＆索引在一个表空间中，表空间可以包含数个文件（或原始磁盘分区）。这与MyISAM表不同，比如在MyISAM表中每个表被存在分离的文件中。InnoDB 表可以是任何尺寸，即使在文件尺寸被限制为2GB的操作系统上。

InnoDB默认地被包含在MySQL二进制分发中。Windows Essentials installer使InnoDB成为Windows上MySQL的默认表。

InnoDB被用来在众多需要高性能的大型数据库站点上产生。著名的Internet新闻站点Slashdot.org运行在InnoDB上。Mytrix, Inc.在InnoDB上存储超过1TB的数据，还有一些其它站点在InnoDB上处理平均每秒800次插入/更新的负荷。

在最初MYSQL没有事务处理，所有的操作默认是提交的，不可回滚。而InnoDB的引入使MYSQL具有了事务功能。从此MYSQL就具有了收费数据库的功能。为MYSQL的发展提供了重要的支持。

作者: to407 时间: 2010-11-30 19:55
我想，MySQL一直是开放的，经历了两次收购活动仍然保持着很强的生命力。

一个优秀的产品，并不会因为成为商业公司的资产而失去他的魅力，就像innodb，作为Oracle的资产，表现同样优秀。～～

如果有机会，可以关心一下互联网公司，无论是google、amazon这些，还是国内较大的互联网公司很多都有自己的MySQL应用。
如何让商业公司和开源社区更好地交流，是一个值得讨论的问题。

其实MYSQL在SUN被ORACLE收购之前，对开源数据库社区的贡献还是很大的。特别是在中国，很多不愿意花钱的网站 ...
renxiao2003 发表于 2010-11-30 09:05

作者: starzhestarzhe 时间: 2010-11-30 20:56

如何让商业公司和开源社区更好地交流，是一个值得讨论的问题
to407 发表于 2010-11-30 19:55

开源社区我不知道,但是商业公司不以利益为前提和你交流的机率很小.

作者: ruochen 时间: 2010-12-01 12:44

个人感觉InnoDB的性能好但是维护成本较大
由于默认采用是将所有数据(所有InnoDB表)都放到一个文件ibdata里 ...
yahoon 发表于 2010-11-26 17:31

可以使用per_table

感觉rhel6+mysql5.5肯定会缔造一种经典

作者: starzhestarzhe 时间: 2010-12-01 13:08

oracle是想从mysql身上挖第二桶金,或者说是减轻oracle的压力
ruochen 发表于 2010-12-01 12:48

oracle现在与其他商业数据库比较还是有一定优势的,oracle的压力不应该靠mysql来减轻,而且mysql似乎也减轻不了,但是拥有mysql之后确实完善了自己的产品线

作者: yahoon 时间: 2010-12-01 16:54

oracle现在与其他商业数据库比较还是有一定优势的,oracle的压力不应该靠mysql来减轻,而且mysql似 ...
starzhestarzhe 发表于 2010-12-01 13:08

\
看开发进度就知道咯

作者: zp25184 时间: 2010-12-01 20:15
今天是见识啦，感谢！

作者: to407 时间: 2010-12-01 23:27
交互有时候可能是双方的，甚至是商业公司、社区、开发者三方的互动，如果只是简单地归咎于商业公司的不作为，也许就很难解决好问题了

回复 26# starzhestarzhe

作者: to407 时间: 2010-12-02 11:30
回复 34# starzhestarzhe

   https://www.linuxfoundation.org/ ... /whowriteslinux.pdf
   http://www.linuxfoundation.org/about/members

可以看到商业大公司，以及公司内部个人对于Linux kernel是有很大贡献的。当然每个公司策略也不同。

而且可以预见的将来，技术的革新是不会停止的，不存在"软件够用"的概念，因为商业公司有这样的想法，就意味着他即将被淘汰。

  InnoDB的发展也不应该只是局限于oracle内部，同样会有开放的力量让他保有生命力。

作者: starzhestarzhe 时间: 2010-12-02 11:33

不存在"软件够用"的概念，因为商业公司有这样的想法，就意味着他即将被淘汰。
to407 发表于 2010-12-02 11:30

哥们是学工商管理的???
我敢说大部分商业公司不一定都是这样的想法,但是都是这样做的

作者: renxiao2003 时间: 2010-12-02 14:09
InnoDB存储引擎有优点：
1）事务支持：在MYSQL的其它引擎中是不支持事务的。
2）存储过程
3）视图
4）行级锁定：在其它引擎上基本没有锁的功能。

适合于的应用场景：
需要事务处理的应用；复杂的数据插入更新操作的WEB应用中。如果仅仅只是查询的情况下就不要使用了。

作者: renxiao2003 时间: 2010-12-02 14:10
InnoDB存储引擎当前存在的缺点有哪些
1.InnoDB不支持FULLTEXT类型的索引。
2.InnoDB 中不保存表的具体行数，也就是说，执行select count(*) from table时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count(*)语句包含 where条件时，两种表的操作是一样的。
3.对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引。
4.DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。
5.LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性（例如外键）的表不适用。

另外，InnoDB表的行锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如update table set num=1 where name like “%aaa%”

以暂对存储引擎的认识，觉得 InnoDB 支持外键，在数据量可以用“庞大”来形容时，在有良好的 INDEX 的基础上，InnoDB 的查询速度应该比 MyISAM 要快。
在 Falcon 有稳定版本前，我想 MyISAM 是一个可用的选择方案。

作者: renxiao2003 时间: 2010-12-02 14:11
随着ORACLE的强硬插手，MYSQL的路在何方。

作者: MYSQLER 时间: 2010-12-02 14:47
本帖最后由 MYSQLER 于 2010-12-02 14:49 编辑

想了解索引算法这一块，因为在实际工作中，MySQL在这方面做的不是太完善，或者说是我们应用的不是太好，同一个语句在相同的索引下，有时候会出现不同的效果，又或者说是explain不准？

作者: MYSQLER 时间: 2010-12-02 14:57
以前现在的服务器硬件只要少有规模的数据量一般都用Innodb了吧，毕竟对于并发插入来说，性能比MyISAM好很多，当然如果很少写入只读MyISAM的性能仍然强悍啊，Innodb在count方面的性能太弱了，许多时候由于需求要在不同表加条件来查count某一数量，速度可想而知，也许你要说设计有问题，呵呵，我的意思是Innodb如果在这一方面能和myisam相比就好了

作者: to407 时间: 2010-12-02 16:32

InnoDB存储引擎有优点：
1）事务支持：在MYSQL的其它引擎中是不支持事务的。
2）存储过程
3）视图
4）行 ...
renxiao2003 发表于 2010-12-02 14:09

恩，innodb和其他存储引擎相比，优势就在于高可用性和大数据量的写操作。在oltp上还是有优势个哈哈～
如果查询性的表多的话。。。就不推荐了

作者: to407 时间: 2010-12-02 16:51
回复 36# starzhestarzhe

Q1，不是。。。

Q2，
   对于非行业软件企业，或者说终端用户，只要他们在短期内可以应付业务需求和发展需要，从成本考虑确实没必要做大跨度升级。

   但在行业内部，即使如google这样快速变革的企业，当google选择了python，python借势繁荣，google选择限制python，python也一定会有自己的出路。

   当然大企业会讲求总体的稳定，因为产品的快速变革会让客户有不安全感，而产品线的停滞会让客户失去忠诚度，做商业产品不是写latex，多少年如一日的稳定，
是要养活一群人的，今年卖一个产品，明年还得继续升级继续卖。
   至于开发工具、脚本，框架或者说一些看上去不是跟终端客户关系很大的软件，我觉得更新的幅度也不会变慢。IBM对DOS的失误养活了MS，
而IBM对于RDBMS的轻视则造就了ORCL，一定会有人去寻找别人没有关注的领域去得到发展，这也会推动整个行业的发展哈哈
   从cvs到git，也是在变新啊，就像mysql会选择innodb或者bdb myisam做engine，也是更新嘛～以前痛苦地看着rh9的gnome界面，后来不也有了compiz也有很多更新选择了哈哈
～～有信心O

作者: Coolriver 时间: 2010-12-02 17:37
支持楼主，qlks　v5.

作者: loverajoe 时间: 2010-12-02 18:21
Innodb引擎在数据的安全性支持上无疑是比myisam更良好的。包括它的外键，引用，事务，等等。

作者: ruochen 时间: 2010-12-02 19:28

InnoDB存储引擎当前存在的缺点有哪些
1.InnoDB不支持FULLTEXT类型的索引。
2.InnoDB 中不保存表的具体行数 ...
renxiao2003 发表于 2010-12-02 14:10

我关注online ddl和多线程ms的复制上面的的改进多谢，还有partition

作者: jhui66 时间: 2010-12-02 20:57
恩，活动很好，正好用学习这方面的知识

作者: yahoon 时间: 2010-12-03 10:05
如果我主从复制环境主库用InnoDB,从库用myisam 那是不是个好的选择呢?

作者: renxiao2003 时间: 2010-12-03 14:29
InnoDB是事务性的。如果在应用中需求有回滚等操作，必须使用这个。
但问题是：如果要进行事务处理，为什么不选用免费的PG，或者收费的ORACLE，SQL Server等。
不知道其它的数据库是不是也有N多引擎。

作者: renxiao2003 时间: 2010-12-03 14:38
从官方文档可看出InnoDB存储引擎的不足之处有：
一个表不能包含超过1000列。
·
内部最大键长度是3500字节，但MySQL自己限制这个到1024字节。
·
除了VARCHAR, BLOB和TEXT列，最大行长度稍微小于数据库页的一半。即，最大行长度大约8000字节。LONGBLOB和LONGTEXT列必须小于4GB, 总的行长度，页包括BLOB和TEXT列，必须小于4GB。InnoDB在行中存储VARCHAR，BLOB或TEXT列的前768字节，余下的存储的分散的页面中。
·
虽然InnoDB内部地支持行尺寸大于65535，你不能定义一个包含VARCHAR列的，合并尺寸大于65535的行。 ·
mysql> CREATE TABLE t (a VARCHAR(8000), b VARCHAR(10000),·

-> c VARCHAR(10000), d VARCHAR(10000), e VARCHAR(10000),·

-> f VARCHAR(10000), g VARCHAR(10000));·
ERROR 1118 (42000): Row size too large. The maximum row size for the·
used table type, not counting BLOBs, is 65535. You have to change some·
columns to TEXT or BLOBs
·
在一些更老的操作系统上，数据文件必须小于2GB。
·
InnoDB日志文件的合并尺寸必须小于4GB。
·
最小的表空间尺寸是10MB。最大的表空间尺寸是4,000,000,000个数据库页（64TB）。这也是一个表的最大尺寸。
·
InnoDB表不支持FULLTEXT索引。
·
ANALYZE TABLE 通过对每个索引树做八次随机深入并相应地更新索引集估值，这样来计数集。注意，因为这是仅有的估值，反复运行ANALYZE TABLE会产生不同数。这使得 ANALYZE TABLE 在 InnoDB 表上很快，不是百分百准确，因为它没有考虑所有的行。
MySQL 不仅在汇合优化中使用索引集估值。如果一些汇合没有以正确的方式优化，你可以试一下 ANALYZE TABLE 。很少有情况，ANALYZE TABLE 没有产生对你特定的表足够好的值，你可以使用 FORCE INDEX 在你查询中来强制使用特定索引，或者设置 max_seeks_for_key 来确保MySQL在表扫描之上运行索引查找。请参阅5.3.3节，“服务器系统变量”。请参阅A.6节，“优化器相关的问题”。
·
在Windows上，InnoDB总是内部地用小写字母存储数据库和表名字。要把数据库以二进制形式从Unix 移到Windows，或者从Windows移到Unix，你应该让所有数据库和表的名字都是小写。
·
警告: 不要在MySQL数据库内的把MySQL系统表从MyISAM转为InnoDB表！这是一个不被支持的操作。如果你这么做了，MySQL直到你从备份恢复旧系统表，或用mysql_install_db脚本重建系统表才重启动。
·
InnoDB在表内不保留行的内部计数。（因为多版本化，这可能确实有些复杂）。要处理一个SELECT COUNT(*) FROM t语句，InnoDB必须扫描表的一个索引，如果这个索引不在缓冲池中，扫描需要花一些时间。要获得快速计数，你不得不使用一个自己创建的计数器表，并让你的应用按照它做的插入和删除来更新它。如果你的表格不经常改变，使用MySQL查询缓存时一个好的解决方案。如果大致的行数就足够了，则SHOW TABLE STATUS也可被使用。请参阅15.2.11节，“InnoDB性能调节提示”。
·
对于AUTO_INCREMENT列，你必须总是为表定义一个索引，并且索引必须包含AUTO_INCREMENT列。在MyISAM表中，AUTO_INCREMENT列可能时多列索引的一部分。
·
当你重启MySQL服务器之时，InnoDB可能为一个AUTO_INCREMENT列重使用一个旧值（即，一个被赋给一个老的已回滚的事务的值）。
·
当一个AUTO_INCREMENT列用完值，InnoDB限制一个BIGINT到－9223372036854775808以及BIGINT UNSIGNED到1。尽管如此，BIGINT值有由64位，所以注意到，如果你要一秒输入100万个行，在BIGINT到达它上限之前，可能还需要将近30万年。用所有其它整数类型列，产生一个重复键错误。这类似于MyISAM如何工作的，因为它主要是一般MySQL行为，并不特别关于任何存储引擎。
·
DELETE FROM tbl_name不重新生成表，但取而代之地删除所有行，一个接一个地删除。
·
TRUNCATE tbl_name为InnoDB而被映射到DELETE FROM tbl_name 并且不重置AUTO_INCREMENT计数器。
·
SHOW TABLE STATUS不能给出关于InnoDB表准确的统计数据，除了被表保留的物理尺寸。行计数仅是在SQL优化中粗略的估计。
·
在MySQL 5.1中，如果innodb_table_locks=1(1是默认值） MySQL LOCK TABLES操作在每一个表上获取两个锁定。除了在MySQL层的表锁定，它也获得一个InnoDB表锁定。旧版的MySQL不获取InnoDB表锁定，旧行为可以通过设置innodb_table_locks=0 来选择。如果没有InnoDB表锁定被获得，即使表的一些记录被其它事务锁定，LOCK TABLES完成。
·
所有被一个事务持有的InnoDB锁定在该事务被提交或中止之时被释放。因此在AUTOCOMMIT=1模式，在InnoDB表上调用是没有太多意义的，因为被需求的InnoDB表锁定可能会被立即释放。
·
有时，在事务的过程中锁定更多的表可能是有用的。不幸地，MySQL中的LOCK TABLES执行一个暗地的COMMIT和UNLOCK TABLES。LOCK TABLES的一个InnoDB变量已经被计划，该计划在事务的中间被执行。
·
为建立复制从服务器的LOAD TABLE FROM MASTER语句对InnoDB表不起作用。一个工作区在主服务器上更换表为MyISAM的，然后做负载，之后更换主服务器表回到InnoDB中。
·
在InnoDB中默认数据库页的大小是16KB。通过编译代码，你可以在8KB到64KB之间来设置这个值。你不得不更新在univ.i源文件中的UNIV_PAGE_SIZE和UNIV_PAGE_SIZE_SHIFT的值。
·
在MySQL 5.1中，触发器不被级联的外键行为激活。

作者: tkchks 时间: 2010-12-03 19:38
本帖最后由 tkchks 于 2010-12-09 20:51 编辑

围观各路神仙

作者: renxiao2003 时间: 2010-12-06 08:54
再看了一下，好像支持事务的引擎还有一个NDB，但这个东西好像只能在特定的OS下使用。

作者: qlks 时间: 2010-12-06 17:01
我还看到有人说select count(1)这类的操作慢

是的，InnoDB比MyISAM是慢，但是对于SQL Server，Oracle，DB2这些数据库，select count(1)的操作同样是慢的，因为必须需要全表扫。

但是还是可以通过一些手段来加速这些操作

作者: qlks 时间: 2010-12-06 17:04
为什么不使用PG

Yep，PG很好很强大，但是这不能简单地就拍拍屁股说我们用PG吧，因为他没被Oracle收购，他是免费的

我想PG应用相对较少，因此对于他目前存在的问题讨论的比较少。就我所知，PG的replication和MySQL是一样的机制，并且也是单线程的。这对于我来说是不能接受的，因为为什么他不能像Oracle一样通过redo机制来做replication呢？MySQL是因为有不同的存储引擎的关系

另外，PG对于多核CPU的支持也不见得比InnoDB好，InnoDB 1.1已经对多核进行了不少的优化，可是相关PG方面的资料还很少看到。

作者: MYSQLER 时间: 2010-12-07 13:17

我还看到有人说select count(1)这类的操作慢

是的，InnoDB比MyISAM是慢，但是对于SQL Server，Oracle，D ...
qlks 发表于 2010-12-06 17:01

嗯，很对，我上面提到过count会慢，只是说未来有没有可能做到在这方面和MyISAM相媲美，试用在要count的表里添加一个无用的字段，默认全为0，以这个字段建索引，count的时候force用这个索引，速度还是很可观，不知道这样做有什么缺点没有

作者: qlks 时间: 2010-12-07 15:41

嗯，很对，我上面提到过count会慢，只是说未来有没有可能做到在这方面和MyISAM相媲美，试用在要c ...
MYSQLER 发表于 2010-12-07 13:17

缺点是这个索引除了在count的时候有用外，别的时候都没有用
并且这样的会每次进行DML会多一个额外的索引的操作，DML操作的性能会有下降

此外，如果是InnoDB的话，默认select count（1）出来的结果都是不精确的，因为默认innodb读是不上锁的，因此可能在你做统计的这段时间内又有记录插入或者删除了
既然是不精确的，你还一定需要用这种统计语句来实现吗？

我还想知道，为什么就纠结于count操作？这种操作本来就多出现于OLAP的操作中，而InnoDB是面向OLTP的

作者: MYSQLER 时间: 2010-12-07 15:50

缺点是这个索引除了在count的时候有用外，别的时候都没有用
并且这样的会每次进行DML会多一个额外的索 ...
qlks 发表于 2010-12-07 15:41

感谢qlks回复

因为我们的系统中有很多这样那样实时的统计，在这方面很是费资源，经常会很慢，有时候一个表还无法实现一个count语句的查询，可能还是初始设计不合理吧

作者: renxiao2003 时间: 2010-12-07 21:35
收到PHP大赛的书《MYSQL核心技术手册》，开始查找相关引擎的异同。

作者: MYSQLER 时间: 2010-12-08 16:32

缺点是这个索引除了在count的时候有用外，别的时候都没有用
并且这样的会每次进行DML会多一个额外的索 ...
qlks 发表于 2010-12-07 15:41

再请教一下，如果统计记数的很多，数据量又不是太小，一天大致有2G的增长，这种统计又在几个表间实现，有什么具体的方法没有

作者: ruochen 时间: 2010-12-08 20:30

收到PHP大赛的书《MYSQL核心技术手册》，开始查找相关引擎的异同。
renxiao2003 发表于 2010-12-07 21:35

不错

作者: ruochen 时间: 2010-12-08 20:33

感谢qlks回复

因为我们的系统中有很多这样那样实时的统计，在这方面很是费资源，经常会很慢， ...
MYSQLER 发表于 2010-12-07 15:50

有的问题自己去和开发商量，看逻辑有更改的余地么

作者: renxiao2003 时间: 2010-12-08 22:31
回复 63# ruochen

学习。。。

作者: qlks 时间: 2010-12-09 14:00

再请教一下，如果统计记数的很多，数据量又不是太小，一天大致有2G的增长，这种统计又在几个表间实现 ...
MYSQLER 发表于 2010-12-08 16:32

因为不知道你们具体的应用，所以真的不能给出什么好的解决方案。我只是觉得一天2G的增长并不算很大的量。

作者: MYSQLER 时间: 2010-12-09 16:09
谢谢qlks

作者: qlks 时间: 2010-12-10 14:18

谢谢qlks
MYSQLER 发表于 2010-12-09 16:09

作者: qlks 时间: 2010-12-14 11:35
《MySQL 技术内幕：InnoDB存储引擎》已在各大书店有售，希望大家多多支持

作者: qlks 时间: 2010-12-14 11:36
《MySQL 技术内幕：InnoDB存储引擎》已在各大书店有售，希望大家多多支持

作者: renxiao2003 时间: 2010-12-15 14:37
目前MYSQL支持事务的引擎有三个。但除了InnoDB之外，其它两个好像必须在特定的操作系统下才能支持。

作者: qlks 时间: 2010-12-15 16:16
MySQL支持事务的引擎有很多，InnoDB，MariaDB，PrimeTX，SolidDB，NDB Cluster
大多数引擎都支持Unix平台，有些不支持Windows平台

作者: starzhestarzhe 时间: 2010-12-16 14:57

为什么不使用PG

Yep，PG很好很强大，但是这不能简单地就拍拍屁股说我们用PG吧，因为他没被Oracle收购，他 ...
qlks 发表于 2010-12-06 17:04

是因为真正熟悉PG的太少

作者: renxiao2003 时间: 2010-12-16 19:44
回复 74# starzhestarzhe

兄弟，上次那本MYSQL核心技术手册也不怎么的啊。全是讲SQL语法的啊。感觉不像核心啊。呵呵。

作者: starzhestarzhe 时间: 2010-12-17 10:04

兄弟，上次那本MYSQL核心技术手册也不怎么的啊。全是讲SQL语法的啊。感觉不 ...
renxiao2003 发表于 2010-12-16 19:44

是啊,我也悔得肠子都青了,不过冒似其他的书也都不是我想要的

作者: renxiao2003 时间: 2010-12-17 10:10
回复 76# starzhestarzhe

有总比没有好。呵呵。行了。那个课件不知道怎么样。不知道有没有兄弟要那个哈。呵呵。

作者: starzhestarzhe 时间: 2010-12-17 10:13
回复 77# renxiao2003

你可以到处问问

作者: renxiao2003 时间: 2010-12-17 10:18
回复 78# starzhestarzhe

问他干啥。肯定不会给换了。呵呵。

作者: renxiao2003 时间: 2010-12-17 10:18
回复 78# starzhestarzhe

再说那个回执卡都由回北京准备换小礼品了啊。呵呵。

作者: starzhestarzhe 时间: 2010-12-17 10:26
回复 80# renxiao2003

这个周末php版有活动,你来吧,估计看你的面子,cu得送你点什么,说不定我们还能沾点光

作者: renxiao2003 时间: 2010-12-17 10:30
回复 81# starzhestarzhe

兄弟，你报销车费我就去。呵呵。

作者: starzhestarzhe 时间: 2010-12-17 10:33
回复 82# renxiao2003

嘿嘿,这个你还是找cu吧,不过在北京坐地铁,坐公交的钱我可以包了,打车费自理

作者: renxiao2003 时间: 2010-12-17 10:36
回复 83# starzhestarzhe

难哈。呵呵。

作者: wangc0727 时间: 2010-12-17 16:38
InnoDB概述
InnoDB给MySQL提供了具有提交，回滚和崩溃恢复能力的事务安全（ACID兼容）存储引擎。InnoDB锁定在行级并且也在SELECT语句提供一个Oracle风格一致的非锁定读。这些特色增加了多用户部署和性能。没有在InnoDB中扩大锁定的需要，因为在InnoDB中行级锁定适合非常小的空间。InnoDB也支持FOREIGN KEY强制。在SQL查询中，你可以自由地将InnoDB类型的表与其它MySQL的表的类型混合起来，甚至在同一个查询中也可以混合。

InnoDB是为处理巨大数据量时的最大性能设计。它的CPU效率可能是任何其它基于磁盘的关系数据库引擎所不能匹敌的。

InnoDB存储引擎被完全与MySQL服务器整合，InnoDB存储引擎为在主内存中缓存数据和索引而维持它自己的缓冲池。InnoDB存储它的表＆索引在一个表空间中，表空间可以包含数个文件（或原始磁盘分区）。这与MyISAM表不同，比如在MyISAM表中每个表被存在分离的文件中。InnoDB 表可以是任何尺寸，即使在文件尺寸被限制为2GB的操作系统上。

InnoDB默认地被包含在MySQL二进制分发中。Windows Essentials installer使InnoDB成为Windows上MySQL的默认表。

InnoDB被用来在众多需要高性能的大型数据库站点上产生。著名的Internet新闻站点Slashdot.org运行在InnoDB上。Mytrix, Inc.在InnoDB上存储超过1TB的数据，还有一些其它站点在InnoDB上处理平均每秒800次插入/更新的负荷。

作者: starzhestarzhe 时间: 2010-12-17 18:12
今天开会，我们一小队搞技术知识共享，一哥们说innodb尽量别用count统计，而myisam则没问题，因为表存储了相关信息(这个不敢苟同)，而我记得的是myisam的表信息只存储了总记录数，而innodb没有，所以针对有where条件过滤的count其实innodb和myisam是一样的,求大牛详解

作者: qlks 时间: 2010-12-20 08:59

今天开会，我们一小队搞技术知识共享，一哥们说innodb尽量别用count统计，而myisam则没问题，因为表存储了相 ...
starzhestarzhe 发表于 2010-12-17 18:12

还在讨论count的问题？
之前我已经回答过这个问题了

作者: ruochen 时间: 2010-12-20 10:29
尽量别用count统计--------对这个还有疑问的，就想想MVCC和count的时候，db还在不停的insert/delete场景

作者: starzhestarzhe 时间: 2010-12-20 12:46

还在讨论count的问题？
之前我已经回答过这个问题了
qlks 发表于 2010-12-20 08:59

尽量别用count统计--------对这个还有疑问的，就想想MVCC和count的时候，db还在不停的insert/delete场景
ruochen 发表于 2010-12-20 10:29

论点不一样,我想知道的是count在myisam与innodb在where条件下其实是一样的,看了相关文章冒似是这么回事.

Sander,

>I'm thinking of switching to InnoDB, however - my application does a few
>COUNT(*) .... WHERE .... queries on large tables (somewhere between 50K
>and 2M rows)
>
>I've read up on InnoDB and its issues with COUNT(*) on entire tables,
>but is there a reason to assume that InnoDB is also slower when there is a
WHERE
>clause present?

no, in the case of COUNT(*) of an entire table MyISAM
is very fast because it keeps a table row count internally.

In the case of COUNT(*) ... WHERE ...
both MyISAM and InnoDB have to really count the matching
rows. Then the speed depends mainly on the amount of disk
i/o needed to access the rows.

Actually, the reason I did not originally put a row count to
InnoDB tables was that I thought most real applications
would ask queries like COUNT(*) ... WHERE. Only later
I have learnt that a plain COUNT(*) is quite common .

http://lists.mysql.com/mysql/85798

作者: qlks 时间: 2010-12-20 14:26
从逻辑角度上看，在oltp中count出来的结果都是不准确的，不管是InnoDB还是MyISAM

所以还有必要将这些操作放在数据库层来做吗？

另外，InnoDB count(*)慢，但是Oracle，SQL Server也同样慢
MyISAM快是因为它是表锁的，读取内部视图即可

关于count操作的讨论可以结束了吗？

如果要讨论，为什么我们不讨论Oracle和SQL Server的count操作也很慢呢？难道我们都要去用MyISAM？

作者: starzhestarzhe 时间: 2010-12-20 17:18
本帖最后由 qlks 于 2010-12-23 10:37 编辑

从逻辑角度上看，在oltp中count出来的结果都是不准确的，不管是InnoDB还是MyISAM

所以还有必要将这些操作 ...
qlks 发表于 2010-12-20 14:26

首先,我没有一味地说innodb的count(*)慢
现在讨论的情景是带where条件的count统计innodb和myisam的差异,myisam也不是任何操作都锁表吧

在 MySQL 3.23.7（在Windows上是3.23.25）以后，在 MyISAM 表中只要没有冲突的 Insert 操作，就可以无需使用锁表自由地并行执行 Insert 和 Select 语句。也就是说，可以在其它客户端正在读取 MyISAM 表记录的同时时插入新记录。如果数据文件的中间没有空余的磁盘块的话，就不会发生冲突了，因为这种情况下所有的新记录都会写在数据文件的末尾（当在表的中间做删除或者更新操作时，就可能导致空洞）。

而且对于这种count我并不需要它十分准确,比如innodb执行count操作并有where条件,那么innodb的锁机制会锁符合where条件的行,那么在count的过程中,对于新加的符合where条件的行,会计算进来还是不计算进来,
如果计算进来,确实会慢,如果不计算进来,应该还好啊.
所以我不赞成那种类似"innodb里尽量不要用count(*)"这种结论.

作者: ruochen 时间: 2010-12-21 19:49
那么在count的过程中,对于新加的符合where条件的行,会计算进来还是不计算进来-------不计算进来

作者: starzhestarzhe 时间: 2010-12-22 11:08

那么在count的过程中,对于新加的符合where条件的行,会计算进来还是不计算进来-------不计算进来
ruochen 发表于 2010-12-21 19:49

明白

作者: jackbillow 时间: 2010-12-22 19:40
支持

作者: qlks 时间: 2010-12-23 10:37

首先,我没有一味地说innodb的count(*)慢
现在讨论的情景是带where条件的count统计innodb和myi ...
starzhestarzhe 发表于 2010-12-20 17:18

InnoDB是MVCC的机制，当然不会对新加的记录统计进来，他只是统计发出SQL命令时的数据记录

另外，我搞不懂，为什么InnoDB加了where之后，count就会慢了？你有实际的例子吗？

比如，表多少大，count出来的结果多少，走的是什么类型的索引？explain的结果是什么？

作者: starzhestarzhe 时间: 2010-12-23 11:07

InnoDB是MVCC的机制，当然不会对新加的记录统计进来，他只是统计发出SQL命令时的数据记录

另外，我搞 ...
qlks 发表于 2010-12-23 10:37

InnoDB加了where之后，count就会慢了

天地良心,我什么时候说过这话了,
我是说加了where条件,对innodb和myisam引擎来说,统计的过程都是一样的

作者: renxiao2003 时间: 2010-12-23 17:10
回复 96# starzhestarzhe

上次提问给书那个活动因为参加的人太少取消了。呵呵。还想得本书呢。

作者: starzhestarzhe 时间: 2010-12-23 17:22
回复 97# renxiao2003

不会吧{:3_189:}
太要不得了

作者: renxiao2003 时间: 2010-12-23 17:26
回复 98# starzhestarzhe

确实参加的人好少。从8月提出到现在，你看，总共回复不到三页。我都回了好几帖啊。

作者: starzhestarzhe 时间: 2010-12-23 17:26
回复 99# renxiao2003

这一回不少了吧,都到十页了

作者: renxiao2003 时间: 2010-12-23 17:27
回复 100# starzhestarzhe

这个是不少了。呵呵。但是上次那个。真的太少。我一个人回了有一页。呵呵。

作者: starzhestarzhe 时间: 2010-12-23 17:30
回复 101# renxiao2003

那你不是很郁闷,眼睁睁地看着书要飞到自己手里了,结果飞得不够远,砸厕所里了

作者: renxiao2003 时间: 2010-12-23 20:40
回复 102# starzhestarzhe

是吖有什么办法啊。

作者: tirecoed 时间: 2010-12-25 13:50
现在MySQL发展确实缓慢，6.0见不到了，Falcon好像是Interbase的创始者主持的，而他也离开了，其它的引擎也很难看到进展，可惜啊。需要事务，现在Innodb应该是很好的选择了。

作者: renxiao2003 时间: 2010-12-27 10:16
一个月期限？应该快开奖了吧。

作者: ruochen 时间: 2010-12-27 23:47

现在MySQL发展确实缓慢，6.0见不到了，Falcon好像是Interbase的创始者主持的，而他也离开了，其它的引擎也很 ...
tirecoed 发表于 2010-12-25 13:50

6.0 5.4的很多都集成在5.5里面了

作者: renxiao2003 时间: 2010-12-29 10:27
呵呵。书一本。不错。

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)