㈠ innodb存储引擎支持全文索引吗
innodb存储引擎是不支持全文索引的，因为Mysql中的存储引擎了解情况,InnoDB存储引擎提供了具有提交、回滚和崩溃恢复能力的事务安全，但不支持全文索引。
㈡ 《MySQL技术内幕InnoDB存储引擎》epub下载在线阅读，求百度网盘云资源
《MySQL技术内幕》（姜承尧）电子书网盘下载免费在线阅读
链接：
书名：MySQL技术内幕
作者：姜承尧
豆瓣评分：8.1
出版社：机械工业出版社
出版年份：2010-11-19
页数：391
内容简介：
本书是国内目前唯一的一本关于innodb的着作，由资深mysql专家亲自执笔，中外数据库专家联袂推荐，权威性毋庸置疑。
内容深入，从源代码的角度深度解析了innodb的体系结构、实现原理、工作机制，并给出了大量最佳实践，能帮助你系统而深入地掌握innodb，更重要的是，它能为你设计和管理高性能、高可用的数据库系统提供绝佳的指导。注重实战，全书辅有大量的案例，可操作性极强。
全书首先全景式地介绍了mysql独有的插件式存储引擎，分析了mysql的各种存储引擎的优势和应用环境；接着以innodb的内部实现为切入点，逐一详细讲解了innodb存储引擎内部的各个功能模块，包括innodb存储引擎的体系结构、内存中的数据结构、基于innodb存储引擎的表和页的物理存储、索引与算法、文件、锁、事务、备份，以及innodb的性能调优等重要的知识；最后深入解析了innodb存储引擎的源代码结构，对大家阅读和理解 innodb的源代码有重要的指导意义。
本书适合所有希望构建和管理高性能、高可用性的mysql数据库系统的开发者和dba阅读。
作者简介：
姜承尧，资深MySQL数据库专家，不仅擅长于数据库的管理和维护，还擅长于数据库的开发。一直致力于MySQL数据库底层实现原理的研究和探索，对高性能数据库和数据仓库也有深刻而独到的见解。曾为MySQL编写了许多开源工具和性能扩展补丁，如广受好评的InnoDB引擎二级缓存项目。现任久游网数据库工程部经理，曾领导并参与了多个大型核心数据库的设计、实施、管理和维护，实战经验非常丰富。活跃于开源数据库和开源软件领域，是着名开源社区ChinaUnix MySQL版块的版主，热衷于与网友分享自己的心得和体会，深受社区欢迎。
㈢ mysql存储引擎简介及InnoDB和MyISAM的区别
MyISAM 和InnoDB 讲解
InnoDB和MyISAM是许多人在使用MySQL时最常用的两个表类型，这两个表类型各有优劣，视具体应用而定。基本的差别为：MyISAM类型不支持事务处理等高级处理，而InnoDB类型支持。MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，但是不提供事务支持，而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 支持事务处理与外键和行级锁。而MyISAM不支持.所以MyISAM往往就容易被人认为只适合在小项目中使用。
作为使用MySQL的用户角度出发，Innodb和MyISAM都是比较喜欢的，如果数据库平台要达到需求：99.9%的稳定性，方便的扩展性和高可用性来说的话，MyISAM绝对是首选。
原因如下：
1、平台上承载的大部分项目是读多写少的项目，而MyISAM的读性能是比Innodb强不少的。
2、MyISAM的索引和数据是分开的，并且索引是有压缩的，内存使用率就对应提高了不少。能加载更多索引，而Innodb是索引和数据是紧密捆绑的，没有使用压缩从而会造成Innodb比MyISAM体积庞大不小。
3、经常隔1，2个月就会发生应用开发人员不小心update一个表where写的范围不对，导致这个表没法正常用了，这个时候MyISAM的优越性就体现出来了，随便从当天拷贝的压缩包取出对应表的文件，随便放到一个数据库目录下，然后mp成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的。另外，可能有人会说你MyISAM无法抗太多写操作，但是可以通过架构来弥补。
㈣ 怎样阅读InnoDB存储引擎源码
1.理解MySQL内核对于DBA的重要性；
如果精通内核对于搞数据库的人来说，可以称得上专家。开源数据库的一个最大好处就是可以去读源码，根据自己的需求去进行个性化的开发，毕竟数据库根据业务最基本的也要分为OLTP,OLAP，系统类型的不同，决定了数据很多参数配置以及核心参数的调整也是不一样的。在调整这些参数前，如果不明白实现的原理，只是根据经验值去调整肯定是不行的，参数可以进行调整，比如减少事务表的长度，修改并发时程来减少锁争用等，如果不明白源码里面的实现方式，是没有办法去修改的，调整参数无法完成的个性化需求，可以通过源码去实现。
如果商业数据库比如oracle开放源码，很多的核心原理得到确认，对于深入学习数据库的人来说是个很大的财富，但是这是不可能实现的。mysql的开源化，对于学习mysql来说个很大的宝库，从源码里可以看出各个引擎的实现方式，而这些核心的原理在很多文档里是看不到的。以前pub里有个大牛说过搞开源化的数据库，如果看不懂源码的话，只能在表面上做工作，搞几年下来，基本就是靠运维，部署，高一些读写分离的架构层面的运维工作，不能称其为专家。
作为MYsql DBA，如果精通源码，对于数据库的理解会深入很多，阿里也是从源码上修改，可以支持自己的业务需求。MYSQL这几年的发展也是靠很多的人根据自己的需要写了很多分享行的代码，可见开源化对于mysql的发展起到重要作用。优秀的DBA需要去阅读一些代码，当比较极端的业务需求需要去定制化数据库的一些功能时，可以从源码级别开发设计适合自己的引擎，mysql在引擎方面预留了很多的接口，可以进行个性化开发。目前我能了解的有网易研究院搞的TNT引擎。
2.怎样阅读InnoDB存储引擎源码；
接触mysql也有几年的时间，很多时候都是阅读官方文档，没有真正的从源码去分析和阅读。以前阅读过姜承尧的innodb引擎这本书，是从一些核心原理上进行讲解，非常深入和精彩。要想InnoDB存储引擎源码需要C和C++的基础，自己能够编译一些程序，确保在修改后能够编译成功。我看过InnoDB存储引擎源码，发现里面的源码量非常大，如果要通读一遍的话，需要很长的时间，而且也非常枯燥，读一些就难以坚持下去。
经过一段时间的积累，我感觉是从一些比较常见的问题去阅读，比如读写，异步的实现，lock,latch，mutex的实现方式，还有内存管理的一些链表等去阅读，每天抽时间读一读，就当是消遣一下。对于索引，实务，缓存等内核的源码一点一点的去看，带着理论知识去理解源码，反过来用源码的实现原理来纠正和补充理论知识，在这个过程中可以快速提高自己。
3.说说读完试读章节后您的感想？
这是本非常好的书，可以对着作者以前写的innodb引擎的那本书一起结合看。试读章节主要分享了两章内容：
第一章是概括性的知识，介绍了INNODB存储引擎的历史，如果知道的同学可以直接略过，后续内容对于源码的版本，风格，编译的方式做了一些介绍，主要是给我们一个源码阅读的认识，对于作者分析的源码方法十分认可，按照层次去阅读，这样可以非常容易的去理解。对于我们这些源码分析的初学者来说可以按照作者的建议，进行按部就班的阅读。
第二章介绍了一些INNODB存储引擎的内存管理的实现，基本数据结构，对于后续做个铺垫。以前都是直接学习理论，记住了这些的内容就可以了，现在从源码角度可以去看看实现方式。这些内容如果前期学的比较深入的话，可以大体看看，如果对这些链表，内存管理方法不是很清楚的可以好好读读，毕竟这是深入学习的基础。
这是分析源码方式的卷1，后续期待作者更多精彩的内容分享。让更多的人喜欢并且可以阅读源码，为开源化数据库作出贡献。
㈤ MySQL技术内幕：InnoDB存储引擎的目录
推荐序
前言
致谢
第1章 mysql体系结构和存储引擎
1.1 定义数据库和实例
1.2.mysql体系结构
1.3 mysql表存储引擎
1.3.1 innodb存储引擎
1.3.2 mylsam存储引擎，
1.3.3 ndb存储引擎
1.3.4 memory存储引擎
1.3.5 archive存储引擎
1.3.6 federated存储引擎
1.3.7 maria存储引擎
1.3.8其他存储引擎
1.4 各种存储引擎之间的比较
1.5 连接mysql
1.5.1 tcp/ip
1.5.2命名管道和共享内存
1.5.3 unix域套接宇
.1.6 小结
第2章 innodb存储引擎
2.1.innodb存储引擎概述
2.2 innodb体系架构
2.2.1后台线程
2.2.2内存
2.3 masteithread
2.3.1 masterthread源码分析
2.3.2 masterthread的潜在问题
2.4 关键特性
2.4.1插入缓冲
2.4.2两次写
2.4.3自适应哈希索引
2.5 启动、关闭与恢复
2.6 innodbplugin：新版本的innodb存储
引擎
2.7 小结
第3章 文件
3.1 参数文件
3.1.1什么是参数
3.1.2参数类型
3.2 日志文件
3.2.1错误日志
3.2.2慢查询日志
3.2.3查询日志
3.2.4二进制日志
3.3 套接字文件
3.4 pid文件
3.5 表结构定义文件
3.6 innodb存储引擎文件
3.6.1表空间文件
3.6.2重做日志文件
3.7 小结
第4章 表
4.1 innodb存储引擎表类型
4.2 innodb逻辑存储结构
4.2.1表空间
4.2.2段
4.2.3区
4.2.4页
4.2.5行
4.3 innodb物理存储结构
4.4 innodb行记录格式
4.4.1 compact行记录格式
4.4.2 rendant行记录格式
4.4.3行溢出数据
4.4.4 compressed与dynamic行记录格式
4.4.5 char的行结构存储
4.5 innodb数据页结构
4.5.1 fileheader
4.5.2 pageheader
4.5.3 infimum和supremum记录
4.5.4 userrecords与freespace
4.5.5 pagedirectory
4.5.6 filenailei
4.5.7 innodb数据页结构示例分析
4.6 namedfileformats
4.7 约束
4.7.1数据完整性
4.7.2约束的创建和查找
4.7.3约束和索引的区别
4.7.4对于错误数据的约束
4.7.5 enum和set约束
4.7.6触发器与约束
4.7.7外键
4.8 视图
4.8.1视图的作用
4.8.2物化视图
4.9 分区表
4.9.1分区概述
4.9.2 range分区
4.9.3 list分区
4.9.4 hash分区
4.9.6 columns分区
4.9.7子分区
4.9.8分区中的null值
4.9.9分区和性能
4.10 小结
第5章 索引与算法
5.1 innodb存储引擎索引概述
5.2 二分查找法
5.3 平衡二叉树
5.4 b+树
5.4.1 b+树的插入操作
5.4.2 b+树的删除操作
5.5 b+树索引
5.5.1聚集索引
5.5.2辅助索引
5.5.3 b+树索引的管理
5.6 b+树索引的使用
5.6.1什么时候使用b+树索引
5.6.2顺序读、随机读与预读取
5.6.3辅助索引的优化使用
5.6.4联合索引
5.7 哈希算法
5.7.1哈希表
5.7.2 innodb存储引擎中的哈希算法
5.7.3自适应哈希索引
5.8 小结
第6章 锁
6.1 什么是锁
6.2 innodb存储引擎中的锁
6.2.1锁的类型
6.2.2一致性的非锁定读操作
6.2.3 selectforupdp/te&selectlockinsharemode
6.2.4自增长和锁
6.2.5外键和锁
6.3 锁的算法
6.4 锁问题
6.4.1丢失更新
6.4.2脏读
6.4.3不可重复读
6.5 阻塞
6.6 死锁
6.7 锁升级
6.8 小结
第7章 事务
7.1 事务概述
7.2 事务的实现
7.2.1 redo
7.2.2 undo
7.3 事务控制语句
7.4 隐式提交的sql语句
7.5 对于事务操作的统计
7.6 事务的隔离级别
7.7 分布式事务
7.8 不好的事务习惯
7.8.1在循环中提交
7.8.2使用自动提交
7.8.3使用自动回滚
7.9 小结
第8章 备份与恢复
第9章 性能调优
第10章 innodb存储引擎源代码的编译
㈥ innodb存储引擎的数据文件放在哪里
MySQL数据库InnoDB存储引擎使用了B策略, InnoDB存储引擎中的恢复机制有几个特点：
A. 在重做Redo Log时，并不关心事务性。 恢复时，没有BEGIN，也没有COMMIT,ROLLBACK的行为。也不关心每个日志是哪个事务的。尽管事务ID等事务相关的内容会记入Redo Log，这些内容只是被当作要操作的数据的一部分。
B. 使用B策略就必须要将Undo Log持久化，而且必须要在写Redo Log之前将对应的Undo Log写入磁盘。Undo和Redo Log的这种关联，使得持久化变得复杂起来。为了降低复杂度，InnoDB将Undo Log看作数据，因此记录Undo Log的操作也会记录到redo log中。这样undo log就可以象数据一样缓存起来，而不用在redo log之前写入磁盘了。
包含Undo Log操作的Redo Log，看起来是这样的：
记录1: <trx1, Undo log insert <undo_insert …>>
记录2: <trx1, insert …>
记录3: <trx2, Undo log insert <undo_update …>>
记录4: <trx2, update …>
记录5: <trx3, Undo log insert <undo_delete …>>
记录6: <trx3, delete …>
C. 到这里，还有一个问题没有弄清楚。既然Redo没有事务性，那岂不是会重新执行被回滚了的事务？确实是这样。同时Innodb也会将事务回滚时的操作也记录到redo log中。回滚操作本质上也是对数据进行修改，因此回滚时对数据的操作也会记录到Redo Log中。
一个回滚了的事务的Redo Log，看起来是这样的：
记录1: <trx1, Undo log insert <undo_insert …>>
记录2: <trx1, insert A…>
记录3: <trx1, Undo log insert <undo_update …>>
记录4: <trx1, update B…>
记录5: <trx1, Undo log insert <undo_delete …>>
记录6: <trx1, delete C…>
记录7: <trx1, insert C>
记录8: <trx1, update B to old value>
记录9: <trx1, delete A>
一个被回滚了的事务在恢复时的操作就是先redo再undo，因此不会破坏数据的一致性.
- InnoDB存储引擎中相关的函数
Redo: recv_recovery_from_checkpoint_start()
Undo: recv_recovery_rollback_active()
Undo Log的Redo Log: trx_undof_page_add_undo_rec_log()
㈦ MySql中有哪些存储引擎
MyISAM、InnoDB、Heap(Memory)、NDB 貌似一般都是使用 InnoDB的，mysql的存储引擎包括：MyISAM、InnoDB、BDB、MEMORY、MERGE、EXAMPLE、NDBCluster、ARCHIVE、CSV、BLACKHOLE、FEDERATED等，其中InnoDB和BDB提供事务安全表，其他存储引擎都是非事务安全表。最常使用的2种存储引擎:1.Myisam是Mysql的默认存储引擎，当create创建新表时，未指定新表的存储引擎时，默认使用Myisam。每个MyISAM在磁盘上存储成三个文件。文件名都和表名相同，扩展名分别是.frm（存储表定义）、.MYD(MYData，存储数据)、.MYI(MYIndex，存储索引)。数据文件和索引文件可以放置在不同的目录，平均分布io，获得更快的速度。2.InnoDB存储引擎提供了具有提交、回滚和崩溃恢复能力的事务安全。但是对比Myisam的存储引擎，InnoDB写的处理效率差一些并且会占用更多的磁盘空间以保留数据和索引。不知道是不是对你有帮助
㈧ innodb存储引擎有多少页
1、区别：
1） MyISAM管理非事务表。提供高速存储和检索，以及全文搜索能力。MyISAM在所有MySQL配置里被支持，是默认的存储引擎，除非配置MySQL默认使用另外一个引擎。
2）MEMORY存储引擎提供“内存中”表。MERGE存储引擎允许集合将被处理同样的MyISAM表作为一个单独的表。就像MyISAM一样，MEMORY和MERGE存储引擎处理非事务表，这两个引擎也都被默认包含在MySQL中。
注释：MEMORY存储引擎正式地被确定为HEAP引擎。
3）InnoDB和存储引擎提供事务安全表，默认被包括在所 有MySQL 5.1二进制分发版里，可以按照喜好通过配置MySQL来允许或禁止任一引擎。
2、功能点简介
1）MyISAM存储引擎
MyISAM存储引擎不支持事务，不支持行级锁，只支持并发插入的表锁，主要用于高负载的select。
myisam类型的表支持三种不同的存储结构：静态型、动态型、压缩型。
（1）静态型：就是定义的表列的大小是固定（即不含有：xblob、xtext、varchar等长度可变的数据类型），这样mysql就会自动使用静态myisam格式。
使用静态格式的表的性能比较高，因为在维护和访问的时候以预定格式存储数据时需要的开销很低。但是这高性能是有空间换来的，因为在定义的时候是固定的，所以不管列中的值有多大，都会以最大值为准，占据了整个空间。
（2）动态型：如果列（即使只有一列）定义为动态的（xblob, xtext, varchar等数据类型），这时myisam就自动使用动态型，虽然动态型的表占用了比静态型表较少的空间，但带来了性能的降低，因为如果某个字段的内容发生改变则其位置很可能需要移动，这样就会导致碎片的产生。随着数据变化的怎多，碎片就会增加，数据访问性能就会相应的降低。
（3）压缩型：如果在这个数据库中创建的是在整个生命周期内只读的表，则这种情况就是用myisam的压缩型表来减少空间的占用。
2）MEMORY存储引擎：
（1）memory存储引擎相比前面的一些存储引擎，有点不一样，其使用存储在内从中的数据来创建表，而且所有的数据也都存储在内存中。
（2）每个基于memory存储引擎的表实际对应一个磁盘文件，该文件的文件名和表名是相同的，类型为.frm。该文件只存储表的结构，而其数据文件，都是存储在内存中，这样有利于对数据的快速处理，提高整个表的处理能力。
（3）memory存储引擎默认使用哈希（HASH）索引，其速度比使用B-+Tree型要快，如果读者希望使用B树型，则在创建的时候可以引用。
（4）memory存储引擎文件数据都存储在内存中，如果mysqld进程发生异常，重启或关闭机器这些数据都会消失。所以memory存储引擎中的表的生命周期很短，一般只使用一次。
3）innoDB存储引擎：
（1） innodb存储引擎该mysql表提供了事务，回滚以及系统崩溃修复能力和多版本迸发控制的事务的安全。
（2）innodb支持自增长列（auto_increment）,自增长列的值不能为空，如果在使用的时候为空的话怎会进行自动存现有的值开始增值，如果有但是比现在的还大，则就保存这个值。
（3）innodb存储引擎支持外键（foreign key） ,外键所在的表称为子表而所依赖的表称为父表。
（4）innodb存储引擎最重要的是支持事务，以及事务相关联功能。
（5）innodb存储引擎支持mvcc的行级锁。
㈨ MySQL技术内幕：InnoDB存储引擎的介绍
《MySQL技术内幕:InnoDB存储引擎》是国内目前唯一的一本关于InnoDB的着作，由资深MySQL专家亲自执笔，中外数据库专家联袂推荐，权威性毋庸置疑。内容深入，从源代码的角度深度解析了InnoDB的体系结构、实现原理、工作机制，并给出了大量最佳实践，能帮助你系统而深入地掌握InnoDB，更重要的是，它能为你设计和管理高性能、高可用的数据库系统提供绝佳的指导。