前端做网站步骤,响应式网站是什么意思,网站负责人半身照,创意设计素描图片目录
一、插入缓冲#xff08;Change Buffer#xff09;→ 快递驿站的 “临时存放区”
二、两次写#xff08;Double Write#xff09;→ 重要文件的 “备份存档”
三、自适应哈希索引#xff08;AHI#xff09;→ 图书馆的 “热门书快捷查找区”
四、异步 IO#x…目录
一、插入缓冲Change Buffer→ 快递驿站的 “临时存放区”
二、两次写Double Write→ 重要文件的 “备份存档”
三、自适应哈希索引AHI→ 图书馆的 “热门书快捷查找区”
四、异步 IOAIO→ 餐厅的 “批量备菜”
五、刷新邻接页Flush Neighbor Page→ 打扫卫生 “顺手擦相邻桌子”
六、总结每个特性都是 “为了解决某类性能 / 可靠性痛点” 一、插入缓冲Change Buffer→ 快递驿站的 “临时存放区”
场景类比 小区门口的快递驿站每天收大量同小区的快递对应 “非聚集索引的插入 / 更新”。驿站不会每收到一个快递就立刻送到用户家对应 “直接写辅助索引页到磁盘”—— 这样太折腾效率低。
而是先把快递存在驿站仓库Insert Buffer等以下情况再批量送 业主来取其他快递时顺路把同单元的快递一起送对应 “辅助索引页被读到缓冲池时合并插入” 仓库快满了Insert Buffer Bitmap 检测到辅助索引页空间不足 每天固定时间Master Thread 定时任务批量送一批快递。
解决的问题 避免 “每次插辅助索引都要随机写磁盘”把多次 “零散写” 变成 “批量写”提升写入性能尤其是写密集场景。
限制 只有 “非唯一辅助索引” 才适用 —— 就像驿站只存 “同小区可批量送的快递”如果是 “必须直接送到家的急件唯一索引需立即校验唯一性”就不能放驿站。
二、两次写Double Write→ 重要文件的 “备份存档”
场景类比 公司要保存一份重要合同数据页16KB 大小怕保存时突然断电数据库宕机导致 “合同只写了前 4KB 就中断部分写失效”。
于是流程变成 先把合同完整复印一份存到公司的 “公共存档区”doublewrite buffer 内存 共享表空间的 2MB 磁盘区域 确认存档成功后再把合同正式存到 “部门文件夹”各个表空间文件。
如果存部门文件夹时断电重启后先从 “公共存档区” 把完整合同复制回来再用重做日志合同修改记录补全细节 —— 保证合同数据页一定是完整的。 解决的问题 防止 “数据页部分写失效” 导致的损坏是 InnoDB 数据可靠性的关键保障 redo 日志能修复 “内容错误”但治不了 “页本身损坏”两次写负责先保 “页的完整副本”。
三、自适应哈希索引AHI→ 图书馆的 “热门书快捷查找区”
场景类比 图书馆的书按分类B 树排列但《Python 编程入门》特别火热点页每天被借几百次。
图书馆管理员发现后在入口处设 “热门书快捷区”直接标注 “《Python 编程入门》→ 3 楼第 5 排第 2 架”哈希索引O (1) 查找。读者不用按 “计算机类→编程类→Python 子类” 的 B 树层级找3-4 次查询直接通过快捷区找到速度快很多。
解决的问题 对 “热点页” 自动生成哈希索引把 B 树的 “多层查询” 变成 “一次哈希定位”提升热点数据的查询性能。
智能之处 只对 “访问模式固定的热点页” 建哈希比如反复用WHERE a1查同一张表 自动监控访问频率比如某页被同模式访问 100 次以上不用 DBA 手动配置。
四、异步 IOAIO→ 餐厅的 “批量备菜”
场景类比 餐厅厨师要做三道菜都需要番茄对应三个 “读数据页” 的 IO 请求 同步 IO做第一道菜时去仓库拿番茄做第二道菜时再去拿做第三道菜时又去拿三次 IO每次等仓库回应。 异步 IO厨师一次性告诉助手 “把三道菜的番茄都拿来”合并 IO 请求助手去仓库批量取一次 IO 拿 48KB覆盖三个 16KB 的页效率更高。
解决的问题 把 “多次零散 IO” 合并成 “一次批量 IO”提升磁盘 IOPS每秒 IO 操作数尤其适合 “连续读相邻页” 的场景。
五、刷新邻接页Flush Neighbor Page→ 打扫卫生 “顺手擦相邻桌子”
场景类比 打扫办公室时发现桌子 A 脏了脏页要刷新到磁盘。同步操作是 “只擦桌子 A”而刷新邻接页是 “擦桌子 A 时发现旁边的桌子 B、C 也脏了就一起擦了”。
这样的好处 机械硬盘场景减少 “反复寻道找不同桌子位置” 的时间一次寻道擦多张桌子效率高 固态硬盘场景不需要寻道所以 MySQL 1.2 后可通过innodb_flush_neighbors0关闭固态 IOPS 足够没必要多擦。
解决的问题 传统机械硬盘下利用 “邻接页一起刷” 减少寻道次数提升批量刷脏页的效率。
六、总结每个特性都是 “为了解决某类性能 / 可靠性痛点” 插入缓冲解决 “辅助索引写入频繁导致的随机写性能差” 两次写解决 “数据页部分写失效导致的可靠性问题” 自适应哈希解决 “热点页查询慢” 异步 IO解决 “零散 IO 太多导致的效率低” 刷新邻接页解决 “机械硬盘寻道次数多导致的刷盘慢”。
这些设计让 InnoDB 在 “写性能”“数据可靠性”“读性能”“IO 效率” 上达到平衡成为 MySQL 最常用的存储引擎之一。
