FULL-STACK PERFORMANCE RESEARCH · 2022—2026

MySQL 数据库性能提升的新技术与未来方向

从操作系统、芯片、服务器到数据库内核的全栈优化：系统梳理 2022–2026 年间 MySQL / MariaDB / Percona 生态的性能技术进展，区分「已落地生产」与「学术实验阶段」，并给出 DBA 与架构师的行动建议。

报告日期：2026-07-26 覆盖版本：MySQL 8.0 / 8.4 LTS / 9.0–9.7、MariaDB 10.5+、Percona Server 8.4 学术来源：VLDB / SIGMOD / CIDR / ASPLOS / FAST / ICDE 所有结论均标注原始出处

§0执行摘要

全文使用以下状态标记： 已落地生产已进入官方发行版或大规模生产实践 实验/分支阶段社区分支、云厂商内核或实验特性 学术原型论文/原型阶段，未进入主线 存在争议社区观点不一致或证据不足

过去四年，MySQL 性能优化的主战场正在发生结构性转移：单机内核参数调优的边际收益在递减，而「内核默认值现代化 + 新硬件接口（io_uring / CXL / RDMA / NVMe）+ 软硬件协同」的边际收益在快速上升。三条主线值得特别关注：

  • MySQL 8.4 LTS（2024-04）完成了一轮「默认值革命」：innodb_io_capacity 从 200 提升到 10000、innodb_flush_method 默认 O_DIRECT、AHI 与 change buffer 默认关闭、innodb_numa_interleave 默认开启——官方首次承认「默认配置应当面向 NVMe SSD 与多路 NUMA 服务器而非十年前的机械盘」（Percona 8.4 调优文档、Oracle 官方 Release Notes）。
  • io_uring 成为开源分支的分水岭：MariaDB 10.6+ 已支持 io_uring 作为 InnoDB 异步 I/O 后端 已落地生产，而 MySQL 上游与 Percona Server 至今未集成，Percona 社区明确将其归因于「重写 InnoDB 底层 I/O 的高成本 + io_uring 的安全与稳定性顾虑」存在争议。
  • CXL 正在取代 Optane PMem 成为学术界的新焦点：VLDB 2024 的《CXL and the Return of Scale-Up Database Engines》、CIDR 2024 的《Database Kernels》、SIGMOD 2025 的《Unlocking the Potential of CXL for Disaggregated Memory in Cloud-Native Databases》构成了一条清晰的「内存分层/解耦」研究脉络 学术原型，而 Meta 的 TPP 已合入 Linux 主线内核（5.18+），是 CXL 技术中少数已生产的部分。
  • 网络与 I/O 接口的「软硬结合」正在补位：网络侧，openEuler Gazelle 用户态协议栈对 MySQL 有官方 18–20% 提速（§1.5）；存储侧，io_uring_cmd NVMe 直通（内核 5.19+）在 VLDB 2026 的系统级研究中与 registered buffer、IOPoll 叠加带来 3.4–3.5 倍吞吐提升，逼近 SPDK 性能却保留全部内核运维能力，是新一代存储引擎的确定性方向（§1.6）。

关于用户提供的“状态速览”中一条数据的核实说明：「MySQL 9.1 引入并行 redo log 写入，吞吐量提升 7.25%」——经检索，该数字仅见于一篇权威性较低的第三方对比文章（tech-insider.org，2026-06），Oracle 官方 9.1 Release Notes 中并无对应条目；官方可查证的相关事实是 9.2 改进了模拟 AIO 处理器在高并发下的性能（Bug #37366607、#37359213）。本报告对该说法标注为 证据不足，不作为采信结论（详见 §4.2）。

§0.5技术全景速览

维度核心技术状态本报告核实结论
OS 层io_uring、eBPF、DPDK/Gazelle、HugePages、NUMA、tcmalloc/jemalloc、io_uring_cmd部分落地io_uring 在 MariaDB 10.6+ 支持属实；MySQL 上游未原生支持属实；eBPF 已在可观测性产品中商用；Gazelle 用户态协议栈对 MySQL 有官方 18–20% 提速数据；io_uring_cmd 已入内核主线并在 VLDB 2026 获数据库系统级验证；io_uring 安全性存在公开争议
芯片/硬件CXL memory、RDMA、NVMe、PMem、Optane学术活跃CXL + 数据库为 VLDB/SIGMOD 2024–2026 明确热点；Optane PMem 已停产，相关研究转向 CXL；RDMA 已在 PolarDB 等云数据库量产
服务器BIOS tuning、SMMU、CPU Prefetching、RAID-10、Node Interleaving已落地openEuler/鲲鹏社区有完整调优指南属实；SMMU「虚拟化开、物理机关」、Prefetch 在部分负载关闭有官方依据
MySQL 内核并行 redo log、doublewrite、buffer pool、并行 DDL持续演进并行 DDL（8.0.27+）属实且有官方数据；doublewrite 简化（8.4）属实；「9.1 并行 redo +7.25%」证据不足
学术前沿Near-Data Processing、Disaggregated Memory、Learned Index、AI 调参学术原型CXL/解耦内存是顶会热点属实；Learned Index 仍未进入 MySQL 系主线，工业落地集中在索引结构与自动调参云服务

§1操作系统层优化

1.1 io_uring：Linux 异步 I/O 的新范式与数据库适配

技术概述

io_uring（Linux 5.1+ 引入）通过共享内存环形队列提交/收割 I/O 请求，避免了传统 libaio 的拷贝与系统调用开销，支持轮询模式（IOPOLL）与注册缓冲区（fixed buffer），在高并发 NVMe 场景下可显著降低每次 I/O 的 CPU 开销。对 InnoDB 这种「多线程 + 大量随机小 I/O」的引擎，理论上是最匹配的接口。

当前进展

发行版io_uring 状态状态出处
MariaDB 10.6+InnoDB 异步 I/O 支持 libaio 与 io_uring 两种后端，由专用线程处理完成通知，纳入 InnoDB 后台线程池（tpool）框架已落地生产MariaDB 官方文档：InnoDB Asynchronous I/O
MySQL 上游（含 9.x）截至 9.7 LTS（2026-04 GA）未提供 io_uring 选项；InnoDB 仍深度绑定 libaio/模拟 AIO；9.2 仅优化了模拟 AIO 在高并发下的处理性能（Bug #37366607、#37359213）未支持MySQL 9.2.0 Release Notes
Percona Server 8.0/8.4未集成。社区官方回应：MySQL 源码中 libaio「深度集成」，重写 InnoDB 最底层 I/O 代码成本高、需内核 5.1+，且 MariaDB 的 io_uring 相关 bug 报告不少，「此类改动需要来自上游」未支持 官方解释Percona Community Forum, 2025-05

争议分析：性能收益 vs 安全成本

io_uring 的安全攻击面是真实存在的顾虑：Google 安全团队 2023 年 6 月披露，其内核漏洞奖励计划中 2022 年 60% 的漏洞利用提交针对 io_uring，Google 为此在 Android 第三方应用与 ChromeOS 中禁用 io_uring，并在自有生产服务器上限制使用；代表性 CVE 包括 CVE-2021-41073（本地提权）、CVE-2023-2598（越界访问）、CVE-2023-21400（5.10 内核 double-free）。此外，基于系统调用拦截的 EDR/审计工具对纯 io_uring 数据路径「不可见」，strace 完全失效。生产缓解手段包括 kernel.io_uring_disabled 开关、seccomp 策略与 eBPF tracepoint 监控。（综合 Google Security Blog 披露的技术综述）

综合判断：MySQL 上游不跟进 io_uring 并非单纯「保守」——InnoDB 的模拟 AIO 经过多年优化后，在多数负载下 io_uring 的边际收益（约个位数百分比）不足以覆盖重写底层 I/O 子系统的工程与安全风险；MariaDB 则选择了「提供选项、默认谨慎」的路线。对 DBA 而言：用 MariaDB 可以在高 IOPS NVMe 负载下试 io_uring 并对比 libaio；用 MySQL 则不必等待此特性，把精力放在 8.4 默认值与 io_capacity 调优上回报更高。

1.2 eBPF：数据库可观测性的新基础设施

技术概述与进展

eBPF 允许在内核中安全运行沙箱程序，无需修改 mysqld 源码即可捕获网络报文（解析 MySQL 协议）、系统调用、块 I/O 延迟与 off-CPU 火焰图。2024–2026 年间，eBPF 已从「内核黑客工具」演变为数据库可观测性的主流底座：

  • Coroot：零插桩捕获 SQL 查询、Redis 命令、HTTP/gRPC，自动生成服务地图与 80+ 项预置巡检（含数据库连接池耗尽检测），开源且支持自托管 已落地生产。（Coroot 官方/GreptimeDB 集成文档，2025-08）
  • Pixie（CNCF）：面向 Kubernetes 的实时调试，自动解析 MySQL 协议层请求。已落地生产
  • Grafana Beyla / OpenTelemetry eBPF Instrumentation：厂商中立的 eBPF 遥测导出，补齐 OTel 在编译型/第三方服务上的盲区。（2026 年 eBPF 观测工具横评，Metoro）

实践价值：eBPF 路线与 MySQL Performance Schema 互补——前者从「外部」看延迟分布与跨服务依赖（无侵入、适合故障定位），后者从「内部」看等待事件与锁（语义丰富）。2026 年的生产标配是两者并用，eBPF 侧重点关注 块设备 I/O 延迟直方图与 io_uring tracepoint（弥补 syscall 审计盲区）。

1.3 内核参数、I/O 调度器与文件系统

以下为 2022–2026 年间经社区验证、仍然有效的数据库服务器内核基线（以 openEuler / RHEL 系为例）：

项目推荐值/做法理由与出处
vm.swappiness1–10避免 buffer pool 被换出；openEuler 数据库调优实践（CSDN/openEuler 实战，2026-02）
透明大页 THPmadvise（而非 always）；InnoDB 大页用显式 HugePagesTHP always 模式下的整理（compaction）会造成数据库延迟毛刺（openEuler 实战）
NVMe I/O 调度器noneNVMe 多队列硬件自带调度，内核调度器只增加开销（openEuler 实战）
脏页回写vm.dirty_ratio=20 / dirty_background_ratio=5与 InnoDB checkpoint 错峰，避免内核集中回写造成 I/O 风暴（openEuler 实战）
文件系统XFS（noatime,allocsize,inode64）为主流选择；ZFS 记录大小需对齐 16KXFS 在大文件顺序写与并发元数据操作上对 InnoDB 最友好（openEuler 实战）
NUMA8.4 起 innodb_numa_interleave=ON 为默认；或用 numactl --interleave=all多路服务器跨 Socket 访问延迟高，交错分配换取稳定带宽（Percona 8.4 文档）

1.4 内存分配器：tcmalloc / jemalloc

glibc ptmalloc 在多线程高并发下的 arena 锁争用与碎片问题长期存在。jemalloc（强调低碎片、per-thread arena、后台回收线程）与 tcmalloc（线程缓存强、延迟敏感场景常见）是两种主流替代品 已落地生产。MySQL 系中 Percona Server 历史上与 jemalloc 绑定最深（打包内置支持）。实际收益高度依赖负载：连接数大、临时表/排序频繁的场景收益明显（RSS 增长更平缓、尾延迟更低），buffer pool 主导的负载差异很小。建议以 MALLOC_ARENA_MAX、jemalloc 的 background_thread 等参数配合压测验证，而非盲目替换。（malloc 机制与替代分配器对比综述，2025-10）

1.5 操作系统网络栈优化：MySQL 的五个提升方向

MySQL 是典型的「高连接数 + 小报文 + 请求-响应」负载：短连接风暴考验连接队列与协议栈开销，OLTP 小包考验每包处理成本与延迟确定性。Linux 网络侧的提升方向可按「侵入性从低到高」分为五层：

方向一：TCP/IP 参数与连接队列调优（零侵入，立竿见影）

参数/选项数据库场景建议理由与出处
net.core.somaxconn / net.ipv4.tcp_max_syn_backlog高并发短连接场景调到 4096–65535（两者联动，后者取前者 2–3 倍）默认全连接/半连接队列过浅会导致短连接风暴下 accept 丢包、连接失败；MySQL 的 back_log 也受 somaxconn 上限截断（OneUptime TCP Backlog 指南，2026-03；火山引擎内核解析，2026-05）
TCP_NODELAY / net.ipv4.tcp_low_latency确认应用侧已禁用 Nagle（MySQL 客户端/代理通常默认开启 TCP_NODELAY）；Java/Python 自研客户端需核查Nagle 算法与延迟 ACK 叠加可造成 40ms 级请求卡顿，对 OLTP 小包是典型尾延迟来源
net.core.rmem_max / wmem_max、tcp_rmem / tcp_wmem跨机房复制、大结果集传输时放大至 16–64MBBDP（带宽时延积）大于默认窗口时，吞吐被窗口而非带宽限制（Continuent Tungsten 数据库网络调优清单）
net.core.netdev_max_backlog万兆及以上网卡调至 65536网卡收包快于内核处理时的输入侧队列深度（Continuent Tungsten 调优清单）
TIME_WAIT 治理（tcp_tw_reuse、ip_local_port_range）客户端侧（应用服务器）开启；服务端重点是连接池化，避免依赖 TW 参数短连接下 TIME_WAIT 堆积耗尽端口是 MySQL 前端最常见网络故障之一

方向二：中断与收包路径优化（NAPI / GRO / 中断聚合 / RSS）

收包路径为「硬中断 → softirq（ksoftirqd）→ NAPI poll → GRO 合并 → 协议栈」。数据库小报文负载的优化要点：（Linux Network Performance Ultimate Guide，2023；RHEL 8 网络调优文档）

  • RSS / 多队列与 IRQ 亲和性：将网卡多队列中断绑定到与 mysqld 同 NUMA 节点的 CPU，避免跨 Socket 处理；配合 RPS/XPS 做软件层分流。已落地
  • 中断聚合（interrupt coalescing）：ethtool -C 调整 rx-usecs。RHEL 官方建议：追求亚 50µs 延迟时关闭 Adaptive-RX 并使用小聚合值；追求吞吐时开启自适应或设 100–250µs——OLTP 属于前者。（RHEL 8 Tuning the network performance）
  • GRO/LRO：对小包为主的 OLTP 收益有限，对大结果集/备份传输有益；个别 NIC 的 LRO 与桥接/NAT 不兼容需关闭。
  • NAPI budget（net.core.netdev_budget）：高 PPS 场景调大可降低 softirq 轮次开销。

方向三：busy polling 与低延迟 socket 选项

SO_BUSY_POLL + net.core.busy_poll / busy_read：应用线程在 recv 前主动轮询网卡队列，跳过中断唤醒路径，可降低尾部延迟——但会独占 CPU，适合「专属数据库服务器 + 延迟敏感」场景，需逐连接启用并实测。特定场景有效

方向四：XDP / eBPF 网络可编程性（旁路加速与安全）

XDP 在网卡驱动层（协议栈之前）执行 eBPF 程序，典型动作 PASS/DROP/TX/REDIRECT。对 MySQL 的价值主要在周边而非数据路径本身：连接洪水/DDoS 在早期丢弃（保护 mysqld 的 accept 路径）、L4 负载均衡与连接引流（替代部分 LVS/HAProxy 场景）、微秒级流量遥测。端到端捕获到用户态延迟可低至约 12µs 可观测/安全已落地；但 XDP 不处理完整 TCP 状态，不能替代 TCP 栈承载 MySQL 协议。（eBPF/XDP Deep Dive，2026-03；PHB Crystal Ball XDP FAQ，2026-07）

方向五：内核旁路（kernel bypass）—— DPDK / 用户态协议栈

完全绕过内核协议栈，用户态直接读写网卡：零拷贝、无锁、轮询模式消除中断与上下文切换。代表性落地是 openEuler 的 Gazelle（DPDK + LwIP，POSIX 兼容、应用零修改，官方定位即「数据库网络性能加速」）：生产可用

+20%+MySQL 8.0.20 Sysbench：内核栈 54.84 万 → Gazelle 66.85 万（Gazelle 官方 README）
+18%鲲鹏 96 核 + 1822 网卡环境下 MySQL tpmC 提升（Gazelle 实测，2022-07）
+20%+Ceph 14.2.8 4K 整机场景提升（同测试体系）

适用边界：Gazelle 类用户态栈的收益来自「每包 CPU 成本」下降，因此只在网络 CPU 是瓶颈时显著（万兆+、高 PPS、短连接、代理层）；buffer pool 命中的常规 OLTP 多数时间瓶颈在磁盘/锁，收益会缩水。代价是独占网卡队列（与 SSH/监控流量需分网卡或分队列）、轮询线程的 CPU 开销、以及运维复杂度。纯 DPDK 自研协议栈则因复杂度更高，在 MySQL 场景基本只见于云厂商网关层。（Gazelle 官方文档与 issue 讨论）

1.6 网络软中断线程化：对 MySQL 的影响分析

技术背景：收包路径的三级执行体

Linux 网络收包为「硬中断（NAPI 调度）→ 软中断 NET_RX（net_rx_action） → 协议栈/应用」。软中断有两处执行位置：① 硬中断退出时 inline 执行（抢占当前用户进程上下文，最多执行 netdev_budget（默认 300）个包或 2 个 jiffies）；② 预算耗尽后唤醒 per-CPU 内核线程 ksoftirqd/N（SCHED_NORMAL 普通优先级）兜底处理。所谓「软中断线程化」就是把执行权重从①移向②或专用线程，内核提供三条路线：

路线机制开启方式内核版本
ksoftirqd 兜底（默认即有）inline 处理超限后转 ksoftirqd，CFS 调度—远古即有
Threaded NAPI每个 NAPI 实例变成专用内核线程（默认 SCHED_FIFO 50），彻底退出 softirq 上下文，可独立设优先级与亲和性echo 1 > /sys/class/net/<dev>/threaded5.15+ 主线可用
全量线程化PREEMPT_RT 内核（6.12 起已完全并入主线）或启动参数 threadirqs：强制所有中断/软中断走线程上下文（ksoftirqd + ktimersd 拆分）CONFIG_PREEMPT_RT / threadirqsRT 补丁系 2004–2024 演进，6.12 入主线 已入主线

收益机制：它解决的不是「快」，而是「稳」

软中断 inline 执行的本质是硬中断抢占用户进程、以最高优先级在网络路径上干活。对 MySQL 这意味着两类典型伤害：

  • 应用线程被不可见地打断：mysqld 工作线程在临界区（如 InnoDB mutex 持有期）被 NET_RX 抢占，相当于凭空延长锁持有时间，放大内部争用——这是高 PPS 下 QPS 上不去、p99 毛刺的重要隐性来源。
  • ksoftirqd 调度空窗：inline 预算耗尽转 ksoftirqd 后，CFS 调度延迟可达数百微秒（极端实测 132ms），期间 ring buffer 中的包排队等待——表现为偶发尾延迟尖峰与重传。（阿里云 ksoftirqd 延迟排查文档；quant67 软中断调度分析）

线程化的收益正在于消除这两点：网络处理变成可被调度器管理的普通线程，不再偷应用的时间片；同时可以被独立设定优先级与 CPU 亲和性，实现「网络核 vs 数据库核」的确定性隔离。代价同样明确：线程化引入一次额外线程唤醒/上下文切换，单流小包路径的绝对延迟略增、空载吞吐略降——Gleixner 2011 年引入 threadirqs 时的实测吞吐基本持平（iperf 933→934–939 Mbit/s），但现代高 PPS 场景下线程化版本通常有单位数百分比的开销。

实测数据与社区证据

  • 阿里云 ECS 实测（Alinux3，g9i.8xlarge）：将网络中断处理与 Redis 工作线程隔离到不同 vCPU（IRQ 亲和 + RPS），QPS 提升 26%——这是「网络与应用争用 CPU 是真实瓶颈」的直接量化证据，官方适用场景明确包含「Redis、Kafka、Nginx、MySQL Proxy」这类 CPU 密集 + 网络 I/O 密集的服务 生产验证。（阿里云《通过 vCPU 绑定优化网络中断提升应用性能》，2025-12）
  • PREEMPT_RT 侧：6.12 主线化后，cyclictest 测得的调度延迟上限从普通内核的数百 µs 量级收敛到 ~50–200µs（调优后 <10µs）；但社区共识是 RT 以吞吐换确定性，对通用数据库服务器吞吐通常有负面影响，且 RT 的正确打开方式是「isolcpus + nohz_full + rcu_nocbs + IRQ/内存隔离」整套组合，单独开 RT 内核收益甚微。（PREEMPT_RT 6.12 主线化报道与调优指南）
  • Threaded NAPI 侧：5.15 随 threadirqs 之外的轻量路线进入主线，被 Cilium 等网络项目用于隔离收包路径；对数据库是「只线程化网卡收包、不动其余内核」的最小侵入选项。

对 MySQL 的适用性结论

分场景结论：

  • 高并发 + 高 PPS（数万连接、代理层、混合部署）：软中断线程化（优先 Threaded NAPI，或 IRQ 亲和 + RPS 隔离）是值得做的正向优化——它把网络开销从「偷 mysqld 的时间」变成「可隔离、可观测、可定优先级」的确定开销，配合阿里云实测的 26% 量级收益是可预期的。建议作为 K8s/专属机高负载 MySQL 的标准基线之一。
  • 中低 PPS、buffer pool 命中的常规 OLTP：网络软中断占比很小（<5% CPU），线程化收益甚微，反而引入上下文切换开销；此时应优先 §1.5 的连接队列/中断聚合/NUMA 绑定。
  • PREEMPT_RT 全量 RT 内核：不推荐用于通用 MySQL 生产。MySQL 是软实时（错过 deadline 只降性能、不出事故），RT 的吞吐代价大于其确定性收益；RT 的价值在工业控制/机器人等硬实时场景。唯一例外是「MySQL 与硬实时任务同机混部」的边缘场景。
  • 诊断先行：决定动手前先验证——mpstat -P ALL 看 %soft 分布是否单核打满、/proc/net/softnet_stat 第三列 time_squeeze 是否持续增长、用 bpftrace 测 NET_RX 的 raise→entry 延迟（阿里云脚本）。若这些指标正常，线程化无的放矢。

风险提示：① 提高 ksoftirqd/NAPI 线程优先级（SCHED_FIFO）须谨慎——高 PPS 下可能反过来饿死用户态（mysqld 的 recv 路径），这正是内核默认给 ksoftirqd SCHED_NORMAL 的设计权衡；② Threaded NAPI 与 irqbalance 需二选一，避免亲和性互相打架；③ threadirqs 会把块层/存储中断也线程化，对 I/O 路径影响需一并评估。

1.7 io_uring_cmd：NVMe 命令直通与数据库应用前景

技术概述

io_uring_cmd（内核 5.19+，opcode IORING_OP_URING_CMD）允许应用通过 io_uring 环形队列向字符设备直接提交原生设备命令。最重要的落地是 NVMe 直通（NVMe passthrough）：应用经 /dev/ngXnY 字符设备直接下发 NVMe 命令到设备队列，绕过通用块层（bio 分配、I/O 调度器、合并逻辑），但仍走内核 NVMe 驱动——设备对 OS 保持可见（lsblk/smartctl/cgroups 均可用），无需像 SPDK 那样解绑设备、预占大页。

传统路径:        app → syscall → VFS → 文件系统 → 块层 → NVMe 驱动 → 设备
io_uring 路径:    app → SQ ring ──────────────→ 块层 → NVMe 驱动 → 设备
io_uring_cmd 路径: app → SQ ring ────────────────────→ NVMe 驱动 → 设备（绕过块层）

性能证据

  • 内核社区实测（Samsung，linux-nvme 邮件列表，2022）：为 io_uring_cmd 接通异步轮询（iopoll）后，512B 随机读 QD1 单核从约 8 万 IOPS 提升到 15.8 万（轮询近翻倍），QD128 批量下达 105.6 万 → 113.2 万 IOPS，「polling 是明确的最大收益来源」 已入主线。（[PATCH 0/4] iopoll support for io_uring/nvme passthrough, Kanchan Joshi/Samsung）
  • 块层路径 vs 直通路径：块 I/O 路径峰值约 290 万 IOPS，io_uring_cmd 直通可达约 390 万 IOPS（+35%）；叠加 registered buffer 与轮询后，达到 SPDK 裸性能的 84–91%，且保留文件系统与全部内核管理能力 （Samsung/WD 团队 FAST'24 会议测试数据，经 2026-04 行业综述引用）。
  • VLDB 2026 数据库系统级验证：TU Darmstadt / TUM 的《io_uring for High-Performance DBMSs: When and How to Use It》（PVLDB 19(1), 2026）在 YCSB 负载的 buffer manager 中逐项叠加优化：registered buffer +11%（23.8 万 tx/s）→ NVMe 直通再 +20%（30 万 tx/s）→ IOPoll 完成轮询再 +21%（37.6 万 tx/s，单线程）；多线程下直通 + 轮询组合带来 3.4–3.5 倍吞吐提升，分别以 18 核/6 核打满 SSD 阵列。该论文并给出 PostgreSQL 案例：应用其指南后端到端性能提升 14% 学术原型（指南级）。（arXiv:2512.04859，代码开源 github.com/mjasny/vldb26-iouring）

对 MySQL/InnoDB 的应用前景分析

有利因素

  • 直击 InnoDB 最大痛点之一：每次 I/O 的 CPU 开销。NVMe 时代块层软件开销已超过硬件延迟，绕过块层对 4K/16K 随机读写意义重大。
  • 直通支持原生 NVMe flush 命令：VLDB 2026 论文指出这是 io_uring 下唯一「真异步」的持久化路径（fsync 在 io_uring 中是阻塞操作，需 fallback 线程；O_SYNC 慢 2 倍以上）——恰好对应 redo/doublewrite 的落盘语义。
  • 不牺牲运维性：无需 SPDK 式设备解绑，pg_rewind/备份工具/监控体系不受影响。
  • 生态就绪：fio（--ioengine=io_uring_cmd --cmd_type=nvme）、xNVMe、SPDK bdev_xnvme 均已支持，验证成本低。

限制与不确定性

  • 绕过文件系统：直走路径是裸设备，InnoDB 需改为「raw device 表空间」模式或自研轻量存储层——这正是论文所指「仅限 flash 优化的数据库系统」；对依赖 ext4/XFS 的通用部署是架构级改动。
  • 继承 io_uring 全部安全攻击面（§1.1），且 /dev/ng* 访问控制模型仍在完善（SNIA 路线图：按文件权限做 I/O 访问控制、去 CAP_SYS_ADMIN 依赖）。
  • 企业级 SSD（带掉电保护）上 fsync 已是微秒级，直通的最大增量收益在消费级/中端盘与高队列深度场景。
  • 批量提交（batching）会显著放大写延迟方差：论文实测 batch=128 时延迟尖峰达 200µs——延迟敏感的 OLTP 不能盲目开大。

前景判断：3–5 年内以分支/新引擎形态落地。io_uring_cmd 不太可能直接出现在 MySQL 主线（上游连基础 io_uring 都未接入），但它是新一代 NVMe 原生存储引擎的确定性方向：LeanStore 一脉的学术引擎、TigerBeetle（作者之一即 VLDB 2026 该论文合著者）、以及云厂商自研内核（类 PolarStore 的用户态 I/O 栈正在从 SPDK/DPDK 向 io_uring_cmd 迁移以保留内核管理面）都在朝此演进。对 MySQL 生态，最现实的路径是 MariaDB/Percona 分支在 io_uring 基础上把 redo/binlog 的落盘路径迁移到直通 flush，或 InnoDB 提供 raw-device 模式对接。短期内 DBA 可用 fio 的 io_uring_cmd 引擎在采购选型时评估硬件真实下限。

§2芯片与硬件层优化

2.1 NVMe SSD 与 InnoDB 参数适配

NVMe 普及是 8.4「默认值革命」的直接动因：机械盘时代的 innodb_io_capacity=200 严重低估了现代 NVMe（单盘数十万 IOPS）。8.4 将默认 innodb_io_capacity 提至 10000、innodb_flush_method 默认 O_DIRECT（绕过页缓存）、innodb_doublewrite_pages 提至 128 已落地生产。（Percona 8.4 Defaults and Tuning；Oracle Release Notes）

200 → 10000innodb_io_capacity 默认值（8.0 → 8.4），面向 SSD/NVMe 校准
16MB → 64MBinnodb_log_buffer_size 默认值，减少大事务 redo 冲刷频率
2 个8.4 起 doublewrite 文件全局固定为 2（原按 buffer pool 实例数 ×2）

容量规划经验值：innodb_redo_log_capacity 建议取峰值 redo 写入速率的 60–90 分钟量；写入吞吐 10–50 MB/s 的中等负载建议 4–8 GB。（JusDB Redo Log Tuning 生产指南，2026-06）

2.2 持久内存（PMem）退场与 CXL 兴起

Intel Optane PMem 于 2022 年停产，「持久内存 OLTP」（如 Zen、DPTree、PLIN 等 VLDB 2020–2023 论文）作为研究方向随之降温，其设计遗产（eADR、无日志 OLTP、PM 友好索引）正迁移到 CXL 语境。CXL（Compute Express Link）基于 PCIe 物理层提供缓存一致的内存扩展/池化能力，已成为 2024–2026 年数据库学术界的头号硬件主题：

工作发表核心贡献状态
TPP: Transparent Page Placement for CXL-Enabled Tiered Memory（Meta 等）ASPLOS 2023把 CXL Type-3 设备当作「无 CPU 的 NUMA 节点」，Linux 内核透明迁移冷热页；实测可用 20–25% DRAM 替换为 CXL，端到端性能损失仅 0.5–3.5%；已上游至 Linux 5.18+内核已落地
Pond: CXL-Based Memory Pooling Systems for Cloud Platforms（Microsoft 等）ASPLOS 2023云厂商视角的 CXL 内存池化系统，评估池化对 DRAM 成本的削减工业原型
CXL and the Return of Scale-Up Database Engines（Lerner, Alonso；ETH/弗里堡大学）VLDB 2024（愿景论文）论证 CXL 使「纵向扩展（scale-up）」架构回归：单机内存带宽/容量可超越物理上限、机架变为一台大共享内存机器；被引 47+（截至 2024 末）学术愿景
Database Kernels: Seamless Integration of Database Systems and Fast Storage via CXL（Lee, Lerner, Bonnet, Cudré-Mauroux）CIDR 2024提出用 CXL 把数据库与快速存储无缝集成的「数据库内核」新形态，模糊内存与存储边界学术原型
An Examination of CXL Memory Use Cases for IMDBMS using SAP HANAVLDB 2024在真实商业内存库（SAP HANA）上系统评估 CXL 内存扩展的收益与代价学术/工业联合
Towards Buffer Management with Tiered Main MemorySIGMOD 2024面向 DRAM+CXL 分层内存的 buffer pool 管理策略——与 InnoDB buffer pool 的未来形态直接相关学术原型
CXL Memory Performance for In-Memory Data Processing（Weisgut 等）VLDB 2025实测真实 CXL 1.1 硬件的带宽/延迟特征，为数据系统给出选型依据（被引 15+）学术评测
Unlocking the Potential of CXL for Disaggregated Memory in Cloud-Native DatabasesSIGMOD 2025云原生数据库场景下 CXL 解耦内存的潜力与瓶颈分析学术原型

对 MySQL 的意义：InnoDB 的 buffer pool 是「DRAM 单一层级」假设下设计的；CXL 分层内存下，buffer pool 需要感知「本地 DRAM vs CXL 远端内存」的延迟差（典型 1.5–2.5 倍），冷热页分层放置、预取策略都要重做。短期内（3 年）MySQL 主线不会原生支持 CXL 分层；可预期的是操作系统层（TPP 式透明迁移）先吃到红利，数据库层（buffer pool 分层）仍是论文阶段。

2.3 RDMA：云数据库的复制与共享存储底座

RDMA（RoCEv2 为主流）在开源单机 MySQL 中无直接接口，但在云原生 MySQL 兼容数据库中已是量产技术：阿里云 PolarDB 采用「计算-存储分离 + RDMA 高速网络 + 分布式共享存储（PolarStore）」架构，OLTP 性能最高达开源 MySQL 的 6 倍、单实例 100 万 QPS；其 PolarStore 用户态轻量网络与 I/O 栈绕过内核，充分发挥 RDMA + NVMe 的低延迟，相关论文获 FAST'26 最佳论文提名 云厂商量产。全局一致性（强一致读）也基于 Commit Timestamp + RDMA 在内核层实现。（阿里云 PolarDB 官方文档与博客，2026）

学术侧，RDMA 单边动词（one-sided verbs）的同步原语设计（SIGMOD 2023《Design Guidelines for …One-Sided RDMA》）、RDMA 内存解耦的分布式共享内存数据库（VLDB 2023《The Case for Distributed Shared-Memory Databases with RDMA-Enabled Memory Disaggregation》）为「MySQL 主从复制走 RDMA」提供了方法论储备，但开源 MySQL 复制协议栈短期内不会原生支持 RDMA——该能力将继续作为云厂商与商业分支的差异化卖点。分支/云厂商

2.4 NUMA、节能模式与国产芯片适配

  • NUMA：跨 Socket 内存访问延迟可达本地的 1.5 倍以上。8.4 默认开启 innodb_numa_interleave 意味着官方选择了「交错分配换稳定」的路线；追求极致延迟的场景仍可采用「buffer pool 绑定单节点 + numactl --membind」的手工 NUMA 绑定。（Percona 8.4 文档）
  • 节能模式：C-States/P-States 的深度睡眠与动态调频会引入微秒级唤醒延迟。鲲鹏 BIOS 调优指南建议 Power Policy 设为 Performance（固定标称频率、关闭动态调频）（鲲鹏社区《典型场景调优指南 openEuler 22.03》，2025）。
  • ARM/鲲鹏：openEuler 社区为鲲鹏 920 提供完整 BIOS + OS + 数据库全栈调优指南；DPDK 高速网络场景另有队列数、VFIO/SMMU、大页与 NUMA 绑定的专项建议 已落地。（鲲鹏社区文档、WayCa 鲲鹏高速网络优化，2026-07）

§3服务器与系统配置层优化

3.1 BIOS/UEFI 调优

BIOS 选项数据库场景建议依据
Support Smmu虚拟化场景 Enabled；纯物理机数据库 Disable（SMMU 地址转换带来额外 I/O 开销）鲲鹏社区调优指南、openEuler 官方 SystemOptimization 文档（v23.03）
Power PolicyPerformance（锁定标称频率，避免 CPPC 动态调频的延迟抖动）鲲鹏社区调优指南（2025-11）
CPU Prefetching大数据/顺序扫描型负载可 Disabled（预取浪费内存带宽）；OLTP 点查负载影响小，建议实测openEuler 官方 big-data-tuning 文档
Node Interleaving与 OS 层 NUMA 策略二选一：BIOS 交错 vs OS 层 innodb_numa_interleave，避免双重交错综合实践
GIC Version（ARM）鲲鹏新型号建议 4.1（中断控制器性能）鲲鹏社区调优指南

3.2 RAID 与阵列卡

数据库负载的经典结论在 NVMe 时代依然适用于 SATA/SAS 场景：RAID-10 优于 RAID-5/6（无写惩罚）、阵列卡配 BBU/超级电容时开启 WriteBack 可大幅提升 redo 与 doublewrite 的落盘性能（断电由 BBU 兜底）；openEuler 官方文档建议用 LSI SAS3508 等阵列卡（2GB Cache）组 RAID 以吃满缓存收益。纯 NVMe 场景则建议直通（HBA/JBOD）或单盘 RAID0 绕过阵列卡写路径。（openEuler 官方 SystemOptimization 文档）

3.3 发行版与容器化

  • 发行版差异：对 MySQL 性能影响主要体现在内核版本（io_uring 需 5.1+、TPP 需 5.18+）与默认内核参数。openEuler 对鲲鹏有专项优化；RHEL/Ubuntu LTS 胜在生态与企业支持。2026 年的新考量：选发行版 = 选内核 LTS 线（5.15/6.x LTS 的 io_uring 安全回补最全）。
  • Kubernetes：性能要点是「确定性资源」——Guaranteed QoS（requests=limits）、独占 CPU 绑定（static CPU manager policy）、HugePages、本地 NVMe + 拓扑感知调度。MySQL Operator（Oracle 官方）、Percona Operator 均已支持这些语义；容器内务必核查 seccomp 是否放行了所需 syscall/io_uring。已落地

§4MySQL / InnoDB 内核层优化

4.1 MySQL 8.4 LTS（2024-04）：默认值革命

8.4 是新的长期支持版（支持至 2032-04），对性能最重要的不是新特性，而是一整套面向现代硬件的默认值重校准。直接沿用 8.0 时代 my.cnf 的升级会错过这些收益：（Percona Server 8.4 Defaults and Tuning，2026-06；Oracle 官方文档）

参数8.0 默认8.4 默认性能含义
innodb_io_capacity20010000适配 SSD/NVMe 的后台刷脏能力（HDD 需手工调低）
innodb_flush_methodfsyncO_DIRECT（若支持）绕过 OS 页缓存，避免双重缓冲
innodb_log_buffer_size16 MiB64 MiB大事务 redo 缓冲，减少刷日志频率
innodb_adaptive_hash_indexONOFFAHI 在高并发下成为争用源，关闭换取可预测性
innodb_change_bufferingallnoneSSD 随机写已足够快，change buffer 收益为负
innodb_doublewrite_files / _pages按实例数 ×2 / 42 / 128简化结构；更大批量提升快速存储上的 doublewrite 吞吐
innodb_numa_interleaveOFFON多路 NUMA 服务器内存分配均衡
innodb_parallel_read_threads4逻辑 CPU/8（最小 4）并行扫描按机器规模自动伸缩
temptable_max_ram1 GiB内存 3%（1–4 GiB）内存临时表上限随机器自适应
innodb_purge_threads4≤16 核为 1，否则 4小机型减少 purge 争用

8.4 还引入直方图自动更新（减少过期统计信息导致的优化器误判）与 connection_memory_limit/global_connection_memory_limit/global_connection_memory_tracking（8.0.28 起引入的连接内存上限与全局追踪，8.4 继续完善），为「内存打爆型 OOM」提供了官方止血手段。（JusDB《MySQL Performance Tuning 2026》专业指南）

4.2 9.x 创新版系列与 9.7 LTS

2024-07
9.0 Innovation：VECTOR 类型（AI 向量数据）；9.0.0 因严重 bug（建 8001+ 表后无法重启）被撤回，9.0.1 替代
2024-10
9.1 Innovation：Performance Schema data_locks/data_lock_waits 重构——查询锁表不再需要全局互斥锁，按哈希桶逐分片加锁，显著降低对生产系统的观测开销
2025-01
9.2 Innovation：InnoDB 模拟 AIO 处理器在高并发下的性能改进（Bug #37366607）+ AIO page cleaner 线程管理优化（Bug #37359213）；启动时间改进
2025-04 → 2026-01
9.3 → 9.4 → 9.5 → 9.6 Innovation 按季度滚动发布
2026-04
9.7 LTS GA——第二个长期支持版（支持至约 2034），Innovation 特性沉淀后的企业级基线（Oracle MySQL HeatWave 版本支持日程，2026-07）

「9.1 并行 redo log +7.25%」核查结论：该说法仅见于 tech-insider.org 一篇 SQLite vs MySQL 对比文章（权威性低），同时声称「doublewrite 重构减少写放大 15%」。Oracle 9.1/9.2 官方 Release Notes 中不存在对应的「parallel redo log」特性条目；可核实的官方改进是 9.2 的模拟 AIO 高并发优化。InnoDB redo log 子系统真正的架构性重构发生在 8.0.30（innodb_redo_log_capacity 动态容量）与 9.0 的 notify_about_advanced_write_lsn() 通知延迟修复（Bug #114660，社区贡献）。结论：该 7.25% 数字不可作为决策依据。

4.3 并行 DDL 与并行读：官方数据最扎实的提速点

  • 8.0.14 引入 innodb_parallel_read_threads：聚簇索引并行扫描（子树粒度）。
  • 8.0.27 引入 innodb_ddl_threads + innodb_ddl_buffer_size：二级索引创建/重建的排序与加载阶段并行化（此前全程单线程）。（Oracle 官方手册 §17.12.5）
  • 8.0.31：B-tree 加载（build）阶段也多线程化——「将排序后的索引项加载进 B-tree」不再单线程。（MySQL 8.0.31 Release Notes）
  • 8.4：innodb_parallel_read_threads 默认按逻辑 CPU/8 自适应。

性能收益（官方实测）：MySQL Server Team 博客以 airportdb 大表加索引为例，默认参数 9 分 0 秒 → 调整 innodb_ddl_threads=8, parallel_read_threads=8, ddl_buffer_size=1GB 后 3 分 9 秒，提速约 2.9 倍 已落地生产。火山引擎 RDS 在 32C64G/8GiB Sysbench 上实测多并发索引创建较社区 5.7 最高提速 2.3 倍；第三方咨询报告给出大表索引创建耗时下降 40–70% 的经验区间。（dev.mysql.com 官方博客；火山引擎 RDS 文档，2026-05；JusDB 案例，2025-11）

限制：含虚拟列的索引、全文索引、空间索引不支持并行线程；并行扫描在含虚拟列/全文/空间索引的表上同样不可用。调大线程数必须同步放大 innodb_ddl_buffer_size（缓冲区被所有线程均分）。

4.4 优化器与其他

  • 直方图统计信息持续增强（8.4 自动更新）；代价模型仍是「魔法常量」体系，学术界对学习型代价模型研究活跃但 MySQL 主线尚未采纳。学术阶段
  • TempTable 引擎在 9.x 修复了 GROUP BY 至少慢 2 倍的问题（Bug #107700）。
  • 9.0 移除 ARCHIVE/BLACKHOLE/FEDERATED 等老旧引擎，内核瘦身。

§5开源社区动态

社区/项目2022–2026 性能相关动态状态
MySQL 官方（Oracle）版本节奏改革：Innovation 季度发布 + LTS（8.4、9.7）；中国厂商贡献显著（阿里巴巴团队多次出现在 9.x Release Notes 致谢中，如 9.1 Bug #36496164、9.2 Bug #36658450）；性能主线为默认值现代化 + AIO/P_S 重构主线活跃
MariaDB10.5 重构 InnoDB 后台线程池异步 I/O 框架；10.6+ 支持 io_uring 后端；ColumnStore（分析）与 Spider（分片）引擎持续演进。策略上更愿意吸收新内核接口主线活跃
Percona8.4 版本发布调优指南，强调「不要沿用 8.0 的 my.cnf」；对 io_uring 持观望态度（等待上游）；另辟蹊径支持 ZenFS（ZNS SSD 用户态文件系统）优化 SSD 写放大主线活跃
Linux 内核社区io_uring 持续迭代（同时伴随安全收敛：io_uring_disabled sysctl、5.15/6.x LTS 安全回补）；TPP 分层内存页迁移合入 5.18+；eBPF 生态（BTF、CO-RE）成熟主线活跃
中国开源社区openEuler 提供面向鲲鹏的完整数据库调优指南（BIOS/内核/文件系统）；龙蜥（OpenAnolis）亦有 MySQL 调优实践；阿里云 PolarDB 的 PolarStore 论文获 FAST'26 最佳论文提名——工业实践反哺学术生产验证

§6学术前沿（VLDB / SIGMOD / CIDR / ASPLOS / FAST，2022–2026）

6.1 研究版图：三条最活跃的脉络

① CXL 与分层/解耦内存

从 PMem 遗产出发，沿 TPP/Pond（ASPLOS'23）→ Scale-Up 愿景（VLDB'24）→ 分层 buffer pool（SIGMOD'24）→ 真实硬件评测（VLDB'25）→ 云原生解耦（SIGMOD'25）→ CXL 异构内存索引（VLDB'26 SIDLE）演进。是本报告判定「最热」的方向。

② 解耦内存上的数据结构

Sherman（SIGMOD'22 写优化 B+树）→ DEX（VLDB'24 范围索引）→ SepHash（VLDB'24）→ Outback（VLDB'25）→ DART（SIGMOD'26）。为「内存解耦的数据库」打地基，尚未触及 MySQL 形态。

③ 软硬件协同的工业实践

PolarDB PolarStore（FAST'26 最佳论文提名）、LeanStore（VLDB'24，NVMe 高性能存储引擎）、OLTP Engines on Modern Storage（SIGMOD'25 Companion）。学术界日益重视「真实生产系统」论文。

6.1.5 补充脉络：io_uring 的数据库系统级研究（新增）

2025-12 发表的 PVLDB 19(1) 论文《io_uring for High-Performance DBMSs: When and How to Use It》（Jasny, El-Hindi, Ziegler, Leis, Binnig；TU Darmstadt / TUM / TigerBeetle，代码开源）是 io_uring 方向第一篇系统的「数据库视角」实证研究，值得单列：其核心结论是「朴素地用 io_uring 替换传统 I/O 接口并不必然带来收益」，收益取决于四项工程决策——I/O 是否为瓶颈、架构是否与 io_uring 能力对齐（异步重叠、批量摊销、ring-per-thread 扩展）、执行模式的选择（DeferTR + single-issuer）、以及高级特性的逐项叠加（registered buffer +11%、NVMe 直通 +20%、IOPoll +21%）。论文同时验证了 io_uring 统一存储与网络 I/O 的价值：在分析型负载的数据 shuffle 场景中，ring-per-thread 架构使网络吞吐超越单核上限。这一工作为 §1.1 的「MariaDB 已支持 vs MySQL 观望」之争提供了中立的量化框架，也是 §1.6 io_uring_cmd 前景判断的主要学术依据。（arXiv:2512.04859；github.com/mjasny/vldb26-iouring）

6.2 Learned Index 与 AI 调参：热但落地慢

Learned Index（用学习模型替代 B+树内部结构）在 2022–2026 持续产出（PLIN 持久化学习索引 VLDB'23、FILM 大于内存场景 VLDB'23、自适应混合索引 SIGMOD'22），但无一进入 MySQL/MariaDB/Percona 主线——B+树与 InnoDB 并发控制、redo、缓冲体系耦合太深，替换代价远高于收益。工业界更现实的吸收方式是云厂商在旁路索引/只读分析引擎中试验。学术原型

ML/LLM 自动调参（OtterTune 一脉、DB-BERT、LLM 驱动的 knob tuning）在 SIGMOD/VLDB 演示论文与云厂商「自治数据库」产品中落地更快——云 RDS 的参数模板与自动巡检已广泛商用；但「self-driving database」全自治仍未达成。部分商用

6.3 代表性论文清单

  • Lerner & Alonso, CXL and the Return of Scale-Up Database Engines, PVLDB 17(10):2568–2575, 2024（被引 47+）。
  • Lee, Lerner, Bonnet & Cudré-Mauroux, Database Kernels: Seamless Integration of Database Systems and Fast Storage via CXL, CIDR 2024。
  • Weisgut 等, CXL Memory Performance for In-Memory Data Processing, PVLDB 18, 2025。
  • Li 等, Pond: CXL-Based Memory Pooling Systems for Cloud Platforms, ASPLOS 2023。
  • Al Maruf 等（Meta）, TPP: Transparent Page Placement for CXL-Enabled Tiered Memory, ASPLOS 2023（已入 Linux 主线）。
  • Leis, LeanStore: A High-Performance Storage Engine for NVMe SSDs, PVLDB 17(12), 2024。
  • Wang 等, Sherman: A Write-Optimized Distributed B+Tree Index on Disaggregated Memory, SIGMOD 2022（该方向被引最高的奠基工作之一）。
  • Unlocking the Potential of CXL for Disaggregated Memory in Cloud-Native Databases, SIGMOD 2025。
  • Korolija 等, Farview: Disaggregated Memory with Operator Off-loading for Database Engines, CIDR 2022（近数据计算/算子卸载到内存侧的代表）。
  • Lee 等, OLTP Engines on Modern Storage Architectures, SIGMOD 2025 Companion（教程/综述，系统梳理现代存储上的 OLTP 引擎设计空间）。
  • Jasny, El-Hindi, Ziegler, Leis & Binnig, io_uring for High-Performance DBMSs: When and How to Use It, PVLDB 19(1), 2026（io_uring 数据库实证指南；NVMe 直通/轮询叠加 3.4–3.5×，PostgreSQL 案例 +14%）。

§7未来趋势与行动建议（2026–2030 展望）

7.1 成熟度判断

技术未来 3–5 年进入 MySQL 主线的可能性判断依据
默认值现代化、并行 DDL 扩展极高（已发生）8.4/9.7 LTS 路线明确，剩余工作是把并行化推广到更多 DDL 类型与查询执行
内核级内存分层（CXL Type-3 + TPP）高（经 OS 透明受益）TPP 已在 Linux 主线；CXL 2.0 硬件 2025–2026 起量，MySQL 无需改动即可受益
buffer pool 感知 CXL 分层中学术已有方案（SIGMOD'24）；上游可能在分支（Percona/云厂商）先行
io_uring 原生支持中低上游无迹象；若 6.x LTS 安全性沉淀 + MariaDB 数据成熟，可能以插件形式出现；VLDB 2026 已给出收益量化框架（14%–3.5×，取决于架构对齐程度）
io_uring_cmd NVMe 直通中（分支/新引擎先行）已入内核主线（5.19+），VLDB 2026 系统级验证收益明确；但绕过文件系统限制其只能以 raw-device/新存储引擎形态落地，学术引擎与云厂商内核先行
用户态网络栈（DPDK/Gazelle）维持分支/特定场景Gazelle 对 MySQL 有 18–20% 官方提速且 POSIX 零修改，但仅在网络 CPU 为瓶颈时成立；内核栈持续优化（GRO/多队列）在压缩其收益空间
网络软中断线程化（Threaded NAPI / PREEMPT_RT）已主线化，选择性采用Threaded NAPI（5.15+）与 PREEMPT_RT（6.12 入主线）均已就绪；对高 PPS 混部/代理层是正向优化（阿里云实测核间隔离 +26%），通用 OLTP 收益小，全量 RT 内核不推荐
XDP/eBPF 网络可编程高（周边场景）DDoS 防护、L4 负载均衡、流量遥测已量产；不承担 MySQL 协议数据路径本身
RDMA 复制/共享存储不进主线，分支强化云厂商（PolarDB 模式）继续领先；开源单机 MySQL 无动机
Learned Index / 全自治调参低与 InnoDB 耦合成本过高；AI 调参以「云服务形态」而非「内核形态」落地
近数据处理（NDP）/ 存算一体低（5 年以上）CXL NDP 论文起步（Farview 一脉），硬件生态未成熟

7.2 给 DBA 与架构师的建议

立刻可做（零风险高收益）

  • 升级到 8.4 LTS / 9.7 LTS，重做而非沿用 my.cnf——重点核对 io_capacity、flush_method、AHI、change buffering、numa_interleave 十项默认值。
  • 大表维护窗口：innodb_ddl_threads + innodb_ddl_buffer_size 按比例放大，索引重建可提速 2–3 倍。
  • 内核基线：NVMe 调度器 none、THP=madvise、swappiness≤10、XFS。
  • 网络基线：短连接高并发场景放大 somaxconn/tcp_max_syn_backlog（4096+），核查客户端 TCP_NODELAY，RSS 中断绑到 mysqld 同 NUMA 节点。

试点验证（按负载取舍）

  • MariaDB 用户在高 IOPS NVMe 写密集负载上对比 io_uring vs libaio。
  • 引入 eBPF 观测（Coroot/Pixie/Beyla）补齐跨服务延迟与 I/O 路径画像。
  • 评估连接内存限制（connection_memory_limit）防止内存型 OOM。
  • 网络 CPU 占比高的代理层/网关场景可试点 Gazelle 类用户态协议栈（先确认瓶颈确实在网络）。
  • 高 PPS 混合部署/代理层：开启 Threaded NAPI（/sys/class/net/<dev>/threaded）或做 IRQ 亲和 + RPS 核间隔离，先以 mpstat/softnet_stat 验证 %soft 是否真是瓶颈。

跟踪观察（1–3 年）

  • CXL 2.0/3.x 服务器采购时预留内存扩展插槽，验证 TPP 式透明分层对 buffer pool 外部内存压力的缓解。
  • 9.7 LTS 的 InnoDB AIO 后续改进；Percona/MariaDB 的 io_uring 成熟度。
  • io_uring_cmd 生态（xNVMe、fio、内核 /dev/ng* 访问控制模型完善度）；学术引擎（LeanStore/TigerBeetle 一脉）向生产外溢的信号。

谨慎对待（避免踩坑）

  • 不要轻信无官方出处的性能数字（如「并行 redo +7.25%」）——以 Release Notes 与可复现 benchmark 为准。
  • io_uring 在多租户/容器平台注意 io_uring_disabled 与 seccomp 攻击面管理。
  • BIOS 层 SMMU/Prefetch 改动需在目标负载上 A/B 验证，不可照搬大数据负载的结论到 OLTP。
  • 不要为通用 MySQL 服务器上 PREEMPT_RT 全量实时内核——吞吐代价大于确定性收益；软中断线程化优先用 Threaded NAPI 这条最小侵入路线，且慎提 ksoftirqd 优先级（防饿死用户态）。

§A附录：参考文献

官方文档与 Release Notes

  1. Percona. Defaults and tuning guidance for Percona Server for MySQL 8.4. docs.percona.com（访问于 2026-07）
  2. Oracle. Changes in MySQL 9.2.0 (2025-01-21) — InnoDB simulated AIO 高并发改进（Bug #37366607, #37359213）。dev.mysql.com
  3. Oracle. Changes in MySQL 9.1.0 (2024-10-15) — P_S data_locks 重构（Bug #36302624）。docs.oracle.com
  4. Oracle. Changes in MySQL 9.0.0 (2024-07-01) — redo 通知修复（Bug #114660）。dev.mysql.com
  5. Oracle. MySQL 8.0 Reference Manual §17.12.5 Configuring Parallel Threads for Online DDL Operations.dev.mysql.com
  6. MySQL Server Team. MySQL 8.0 – InnoDB Parallel Threads for Online DDL Operations（airportdb 实测 9min→3min9s）。dev.mysql.com blog
  7. MariaDB. InnoDB Asynchronous I/O（libaio/io_uring 后端说明）。mariadb.com/docs
  8. Oracle. MySQL Server Versions / Support Schedule（9.0–9.7 LTS 发布日程）.docs.oracle.com（2026-07）

社区与工程实践

  1. Percona Community Forum. Why no io_uring support?（2025-05，官方解释 libaio 耦合与上游策略）。forums.percona.com
  2. 华为鲲鹏社区. 典型场景调优指南（openEuler 22.03）— BIOS 配置调优（SMMU / Power Policy / GIC）。hikunpeng.com（2025-11）
  3. openEuler. System Optimization — Big Data Tuning（SMMU/Prefetch/RAID 建议）, v23.03。docs.openeuler.org
  4. WayCa/openEuler. 鲲鹏高速网络性能优化：DPDK 驱动配置与调优。CSDN 转载（2026-07）
  5. 阿里云. What are the benefits of PolarDB（RDMA + 共享存储，OLTP 6×、100 万 QPS）。alibabacloud.com/help（2026-06）
  6. 阿里云. PolarDB PolarStore Receives Best Paper Award Nomination at FAST'26。alibabacloud.com/blog
  7. Metoro. Top eBPF Observability Tools in 2026（Coroot/Pixie/Beyla 横评）。metoro.io（2026-04）
  8. JusDB. MySQL InnoDB Redo Log Tuning: Sizing for Production Write Throughput。jusdb.com（2026-06）
  9. 火山引擎. Parallel DDL — RDS for MySQL（2.3× 实测提速）。volcengine.com/docs（2026-05）
  10. Ke Yu（阿里云）. An Introduction to MySQL Parallel Query and DDL（8.0.37 源码级解析）。alibabacloud.com/blog（2025-01）
  11. tech-insider.org. SQLite vs MySQL 2026（「9.1 并行 redo +7.25%」唯一出处，权威性 C，本报告不采信）。tech-insider.org（2026-06）
  12. openEuler. Gazelle: A high performance user-mode stack powered by DPDK and LwIP（MySQL 8.0.20 +20%、鲲鹏 96 核 +18% 官方数据）。github.com/openeuler-mirror/gazelle
  13. Red Hat. RHEL 8: Tuning the network performance — 中断聚合建议（亚 50µs 延迟关闭 Adaptive-RX）。docs.redhat.com
  14. OneUptime. How to Configure net.core.somaxconn and TCP Backlog for High-Connection Servers。oneuptime.com（2026-03）
  15. Kanchan Joshi (Samsung). [PATCH 0/4] iopoll support for io_uring/nvme passthrough, linux-nvme 邮件列表（轮询使 512B 随机读近翻倍的原始数据）。lists.infradead.org（2022-08）
  16. Simon A. F. Lund (Samsung). xNVMe and io_uring NVMe passthrough: What does it mean for the SPDK NVMe driver? SNIA SDC 2023。snia.org
  17. Murat Karslioglu. io_uring, SPDK, and the Kernel Bypass Wars（io_uring_cmd vs SPDK 对比综述；引用 Samsung/WD 在 FAST'24 的 390 万 IOPS 实测）。muratkarslioglu.com（2026-04，权威性 NA，数据以其引用的会议来源为准）
  18. 阿里云. 通过 vCPU 绑定优化网络中断处理提升应用性能（IRQ 亲和+RPS 隔离，Redis QPS +26%，适用场景含 MySQL Proxy）。help.aliyun.com（2025-12）
  19. 阿里云. ksoftirqd 线程任务调度延迟排查说明（NET_RX raise→entry 延迟 bpftrace 诊断法；实测 132ms 级异常案例）。help.aliyun.com（2024-10）
  20. Thomas Gleixner. genirq: Provide forced interrupt threading（threadirqs 原始 commit，含 iperf 吞吐实测）。lkml.org（2011-02）
  21. KernelNewbies. Linux 6.12 — Real Time support（PREEMPT_RT 主线化官方说明）。kernelnewbies.org（2024-12）

学术论文

  1. Alberto Lerner, Gustavo Alonso. CXL and the Return of Scale-Up Database Engines. PVLDB 17(10): 2568–2575, 2024. doi:10.14778/3675034.3675047。vldb.org
  2. Sangjin Lee, Alberto Lerner, Philippe Bonnet, Philippe Cudré-Mauroux. Database Kernels: Seamless Integration of Database Systems and Fast Storage via CXL. CIDR 2024。
  3. Marcel Weisgut et al. CXL Memory Performance for In-Memory Data Processing. PVLDB 18, 2025。vldb.org
  4. Huaicheng Li et al. Pond: CXL-Based Memory Pooling Systems for Cloud Platforms. ASPLOS 2023. doi:10.1145/3575693.3578835。
  5. Hasan Al Maruf et al. (Meta). TPP: Transparent Page Placement for CXL-Enabled Tiered Memory. ASPLOS 2023. doi:10.1145/3582016.3582063。
  6. Qing Wang et al. Sherman: A Write-Optimized Distributed B+Tree Index on Disaggregated Memory. SIGMOD 2022。
  7. Viktor Leis. LeanStore: A High-Performance Storage Engine for NVMe SSDs. PVLDB 17(12): 4536–4545, 2024。
  8. Unlocking the Potential of CXL for Disaggregated Memory in Cloud-Native Databases. SIGMOD 2025。
  9. Towards Buffer Management with Tiered Main Memory. SIGMOD 2024。
  10. An Examination of CXL Memory Use Cases for In-Memory Database Management Systems using SAP HANA. VLDB 2024。
  11. Dario Korolija et al. Farview: Disaggregated Memory with Operator Off-loading for Database Engines. CIDR 2022。
  12. Sangjin Lee et al. OLTP Engines on Modern Storage Architectures. SIGMOD 2025 Companion. doi:10.1145/3722212.3725633。
  13. Matthias Jasny, Muhammad El-Hindi, Tobias Ziegler, Viktor Leis, Carsten Binnig. io_uring for High-Performance DBMSs: When and How to Use It. PVLDB 19(1), 2026. arXiv:2512.04859。arxiv.org；artifact: github.com/mjasny/vldb26-iouring