InnoDB 使用模拟的异步(simulated asynchronous)的磁盘 I/O来构建 InnoDB：InnoDB 建立许多的 i/o 线程来处理 i/o 操作，就如同 read-ahead 一样。
从 3.23.40b 开始，InnoDB 使用一种被称为“双写 (doublewrite)” 的新颖的文件转储清除(flush)技术。这增加了在操作系统崩溃或停电后的崩溃修复的安全性，并因减少了 fsync 操作的必要次数而某些 Unix 系统中改善了性能。
InnoDB 在将页面写入一个数据文件前先将他们写入到一个相邻近的表空间中的双写(doublewrite)方法被双写缓冲(doublewrite buffer)。只有在写入与转储清除(flush)双写缓冲结束后，InnoDB 才将页面写入到数据文件的适当的位置。如果在页面写入期间操作系统崩溃了，InnoDB 将在双写缓冲中找出一个完好的副本(copy)来恢复。
从 3.23.41 开始，你也可以使用一个 raw
磁盘分区（一个 raw 器件) 作为一个数据文件。当你创建一个新的数据文件时你必须在 innodb_data_file_path
设置的数据文件尺寸后立即加上关键词 newraw 。这个分区必须 >= 你所指定的尺寸。注意在 InnoDB 中 1 MB
为 1024 x 1024 bytes，而在磁盘规约中 1 MB 通过为 1000 000 bytes。
innodb_data_home_dir= innodb_data_file_path=/dev/hdd1:3Gnewraw;/dev/hdd2:2Gnewraw
当你再次启动数据库系统时，你 必须
将关键词改为 raw。否则 InnoDB 将重写你的分区！从 3.23.44 开始，作为一个安全措施，InnoDB 将阻止用户修改任何以
newraw 指定的分区中的数据。在你增加了一个新的分区后，关闭数据库服务器，修改 my.cnf 文件，将
newraw 替换为 raw，再重起。
innodb_data_home_dir= innodb_data_file_path=/dev/hdd1:3Graw;/dev/hdd2:2Graw通过使用一个 raw disk ，在 Windows 和某些 Unixes 系统中可以实现无缓冲(non-buffered)的 i/o。
在 InnoDB 中有两个启发式的(heuristics) read-ahead heuristics ：顺序的(sequential) read-ahead 和随机的(random) read-ahead。在 sequential read-ahead 中 InnoDB 以顺序的方式访问分区中表空间一个片段。因而 InnoDB 将预先以一个批量读取数据库页面到 i/o 系统中。中 random read-ahead 中，InnoDB 将表空间中似乎在进程的有用的某些空间完全读到缓冲池(buffer pool)内。因而 InnoDB 投递剩余地读到 i/o 系统中。
在配置文件中定义的数据文件形成 InnoDB 的表空间。文件被简单地耦合起来形成表空间，在使用中不得被剥离。通常你不能得知你的表所占用的空间被指定在哪里， 除非使用下面的事实：在一个新建的表空间中 InnoDB 从文件的末端开始分配空间。
表空间由默认为 16 KB 的数据库页面组成。每 64 个连续的页面被组成一区域(extent)。表空间内的“文件(files)”在 InnoDB 中被称为段(segments)。回滚段(rollback segment)稍微会引起被误解，因为实际上它在表空间内是由许多个段组成。
InnoDB 中的每个索引都被分配两个段(segments)：一个是为了 B-tree 的无叶结点(non-leaf nodes)，另一个是为了叶结点(leaf nodes)。这是为了达到包含数据的叶结点的更好的顺序(sequentiality for the leaf nodes)。
当表空间中的一个段增长时，InnoDB 为它个别地分配最初的 32 个页面。之后 InnoDB 再分配段的整个区域(extents)。InnoDB 会以每次 4 个区域(extents)来增加一个大段以确保数据的良好顺序。
表空间中的某些页面包含其它页面的位图(bitmaps)，所以在 InnoDB 表空间内的一些区域(extents)不能以一个整体分配给段，而只能作为个体页面。
当发出一个查询 SHOW TABLE
STATUS FROM ... LIKE ... 来询问表空间的剩余空间时，InnoDB 将报告表空间中所有空闲区域(extents)中确实可用的部分。InnoDB
通常会保留一些区域用于 clean-up 和其它的内部目的；这些保留的区域并不包含在剩余可用空间中。
当从一个表中删除数据时，InnoDB 将收缩 B-tree 中相应的索引。这是依赖于释放个别的页面或区域(extents)以让其他用户使用剩余空间的删除模式。 移除(drop)一个表或删除所有记录可以保证释放空间给其他用户，但是删除记录行只有在事务回滚或 consistent read 后并不需要时才会被物理的移除。
如果在一个表的索引内有随机地插入与删除，索引将会产生碎片。
碎片的意思是索引页面在磁盘上的物理顺序并不接近于页面依字母顺序排序的记录， 或分配给索引的 64 个页面块中有太多的未使用页面。如果周期性的通过 mysqldump
将表转储到一个文件文件上，移除(drop)表，再从转储文件中重载它，这将提升索引扫描的速度。 另一个碎片整理的办法就是将表类型改变为 MyISAM
然后再改为 InnoDB 。注意 MyISAM 表在你的操作系统上必须为一个单独的文件。
如果索引中的插入总是上升的而总是从后面删除，那么 InnoDB 的文件空间管理算法可以保证索引中的碎片不会出现。