SQL数据库资源隔离的核心是通过CPU和IO配额保障多租户稳定性：CPU采用权重+硬限组合（如OLTP设高权重60%硬限），IO推荐cgroup v2设备级限速（SSD控IOPS、HDD控吞吐），需结合连接标识、用户绑定或容器隔离实现精准分组，并持续监控节流事件与等待指标动态调优。

SQL数据库的资源隔离，核心是限制单个租户、数据库或查询对CPU和IO的过度占用，避免“一个慢查询拖垮整个实例”。关键不在于完全禁止资源竞争，而是在共享环境中划清边界，保障关键业务的稳定性与可预测性。

CPU配额：按逻辑核或百分比限制计算能力

多数现代SQL数据库（如PostgreSQL 15+、SQL Server Resource Governor、TiDB、OceanBase）支持基于cgroup或内部调度器的CPU使用率控制。常见做法不是固定分配物理核，而是设置相对权重或硬性上限。

• 权重模式（如PostgreSQL的cpu_priority或cgroup v2的cpu.weight）：多个工作负载共存时，按比例分配可用CPU时间。例如，A组权重80、B组权重20，则在争抢时A获得约4/5的CPU时间。
• 硬上限模式（如SQL Server的CAP_CPU_PERCENT）：直接限制某资源池最大可用CPU百分比（如限定某个租户最多使用30%总CPU）。需注意：该限制作用于调度周期内平均值，短时突发仍可能发生，但长期超限会被节流。
• 建议：优先用权重+软限组合；对OLTP核心库设较高权重+中等硬限（如60%），对报表类任务设低权重+严格硬限（如15%），并配合查询超时（statement_timeout）防止长事务霸占CPU。

IO配额：区分读写、吞吐与IOPS，绑定到存储层

IO隔离比CPU更复杂，因涉及磁盘类型（NVMe vs SATA）、文件系统、缓冲区层级。有效IO配额需在数据库层与底层存储协同实现。

• 数据库层IO控制（如MySQL 8.0.28+的io_capacity、PostgreSQL的bgwriter_lru_maxpages间接影响）：主要调节后台进程（如checkpoint、vacuum）的IO节奏，避免突发刷脏页打满磁盘带宽。但无法精确限制单个查询的读取量。
• 操作系统级IO限速（推荐）：通过cgroup v2的io.max（指定设备+读/写+bps/iops上限）对数据库进程组做硬隔离。例如：io.max = 8:16 rbps=52428800 wbps=26214400 表示对设备sdb限制读50MB/s、写25MB/s。
• 建议：将同一租户的数据库实例统一放入一个cgroup；SSD环境优先控IOPS（如riops=2000 wiops=1000），HDD环境侧重控吞吐（bps）；定期用iostat -x 1验证实际IO分布是否符合预期。

配额生效的前提：正确识别与分组工作负载

无论CPU还是IO配额，失效的主因常是“配错了对象”。数据库本身不天然知道哪些连接属于哪个租户，需主动标记。

• 连接级标识：应用在建连时通过application_name（PostgreSQL）、client_info（Oracle）或自定义session variable传递租户ID；数据库侧用Resource Governor分类器函数或pg_stat_activity视图匹配路由。
• 用户/角色级绑定：为每个租户创建独立数据库用户，并在创建资源池时关联该用户。注意：权限隔离（如REVOKE CREATE ON SCHEMA）应同步配置，防越权。
• 容器/实例级隔离（云环境）：K8s中用LimitRange + RuntimeClass约束Pod CPU/Memory，再配合hostPath或Local PV绑定特定NVMe设备，并在该PV上部署单租户数据库实例——这是最彻底的物理隔离方式。

监控与调优：配额不是一设了之

配额设置后必须持续观测效果，否则可能误伤性能或形同虚设。

• 关键指标：CPU节流事件（cgroup v2的cpu.stat throttled_time）、IO等待时间（await in iostat）、数据库内等待事件（如PostgreSQL的IO: DataFileRead占比突增）。
• 典型误判：看到CPU使用率仅40%就认为有余量，却忽略该时段内已有大量throttling——此时实际可用算力已不足；或IO延迟升高归因为磁盘故障，实则是配额导致请求排队。
• 建议：在Prometheus中采集cgroup指标+数据库PGSS/Performance Schema数据，用Grafana看板联动分析；新配额上线前先跑72小时影子流量，对比节流率与P99响应时间变化。

不复杂但容易忽略：配额策略必须随业务增长动态调整，季度性回顾租户用量TOP3，合并低频小租户、拆分高负载租户，让资源池始终贴近真实负载分布。