如何使用InnoDB存储引擎？《MySQL 技术内幕：InnoDB存储引擎》有奖试读名单公布！

to407

回复 34# starzhestarzhe

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

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

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

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

starzhestarzhe

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

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

renxiao2003

InnoDB存储引擎有优点：
1）事务支持：在MYSQL的其它引擎中是不支持事务的。
2）存储过程
3）视图
4）行级锁定：在其它引擎上基本没有锁的功能。

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

renxiao2003

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

随着ORACLE的强硬插手，MYSQL的路在何方。

MYSQLER

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

MYSQLER

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

to407

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

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

to407

回复 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

支持楼主，qlks　v5.