虚拟存储(VIRTUAL) vs 实际存储(STORED) — 选型界定分析1. 文档目的在表结构设计、字段落库、索引/搜索层拆分时经常需要回答三个问题这个场景算不算「读少写多」这张表算不算「大表」字段/数据应该实际存储物理列/独立表还是虚拟存储扩展 JSON / 搜索索引 / 缓存 / 异步物化本文给出可量化阈值 决策流程 项目内示例避免凭感觉选型。2. 术语定义术语含义Seller 项目典型实现实际存储数据以 MySQL物理列或独立业务表持久化作为唯一事实源Source of Truth采购单主表字段、seller_supplier_company.supplier_code半虚拟存储仍在 MySQL但以JSON/ext 扩展字段存非核心、低频查询属性采购单ext字段cloth、mpmSellerPrice 等虚拟存储派生存储从事实源衍生出来服务于读/搜/缓存允许最终一致ES 搜索索引、KV 分页配置、MQ 异步宽表计算虚拟查询时实时计算不落库列表页汇总金额、状态文案映射原则写路径永远以实际存储为准虚拟层只读或可重建不可单独作为账务/审核等强一致数据的唯一来源。3. 读写特征如何量化界定3.1 核心指标至少采集其中 2 项指标说明建议观测窗口日读写比 R:W单日 SELECT 次数 / INSERTUPDATEDELETE 次数7 日滑动平均峰值 QPS 比读 QPS / 写 QPS或反向业务高峰 1 小时读路径复杂度是否多条件筛选、排序、聚合、全文检索按 SQL/接口统计写放大系数一次业务写操作触发的 DB 行更新次数含日志、索引、ES 同步链路追踪一致性要求强一致 / 可接受秒级延迟 / 可接受分钟级业务定义3.2 读写类型分级日读写比 R:W类型日读写比 R:W峰值 QPS 特征典型场景读多写少≥ 10 : 1读 QPS ≥ 写 QPS ×5列表搜索、报表、看板、导出读写均衡3 : 1 ~ 10 : 1读写同量级主业务单据采购单、供应商主数据读少写多≤ 1 : 3即 W:R ≥ 3:1写 QPS ≥ 读 QPS ×3操作日志、状态流水、MQ 消费落库写多读少≤ 1 : 10即 W:R ≥ 10:1写远大于读读多为后台补偿埋点、审计快照、同步队列、Session「读少写多」的实用判定满足以下任意 2 条即可归类① 日 W:R ≥ 3:1② 峰值写 QPS ≥ 读 QPS × 3③ 单条业务操作平均产生 ≥ 3 次 INSERT/UPDATE写放大④ 读请求 80% 以上为按主键/唯一键点查几乎无列表检索3.3 没有监控数据时的经验默认值数据形态默认读写类型理由主单据头 明细读写均衡创建/修改与列表查询并存操作日志 / 审核记录读少写多每次操作必写极少按复杂条件查列表页 多维度筛选读多写少查询远多于单条更新导入/批量任务明细写多读少批量 INSERT几乎不读扩展属性展示用读少写多随主单写随主单更新单独检索少4. 「大表」如何清晰界定单表建议控制在 500 万行以内。以下为分级 多维判定避免只看行数。4.1 数据量级分级级别行数估算表空间运维影响特征DDL风险小表 100 万 2 GBALTER、备份快可适度加索引秒级DDL几乎无感知低中表100 万 ~500 万2 ~ 10 GB需关注索引数量与慢 SQL分钟级DDL需选低峰期中大表500 万 ~ 5000 万10 ~ 100 GB应考虑归档、分表、读写分离小时级DDL可能锁表阻塞业务高超大表 5000 万 100 GB必须分库分表或冷热分离必须走Online DDL或pt-osc/gh-ost工具极高关键阈值InnoDB 单表超过 2000万行B树深度增加随机IO性能开始下降单表超过 50GB备份、迁移、DDL 时间成本陡增索引大小超过 10GB添加索引的耗时和锁表风险显著4.2 「算大表」的判定规则满足任意 2 条#条件说明A行数 ≥500 万与项目规范一致B表空间 ≥10 GB宽表、TEXT/JSON 多时也需警惕C典型列表查询扫描行数≥ 50 万EXPLAIN rows索引未覆盖D单次 ALTER / 在线 DDL预计 30 分钟影响发版窗口E二级索引总大小 InnoDB Buffer Pool 的 30%写放大、缓存命中率差F历史数据 80%几乎不被业务访问适合归档而非继续堆在主表4.3 大表 ≠ 必须用 ES大表只说明MySQL 单表承载压力变大解法是归档 / 分表 / 冷热分离优先收窄索引、避免SELECT *、禁止深分页OFFSET 10 万读多写少且有多维检索时再考虑 ES 等虚拟读层5. 存储形态对照形态一致性写成本读成本适用读写类型MySQL 物理列强一致中索引维护低~中有索引时读写均衡需 WHERE/ORDER/JOIN 的字段MySQL JSON/ext强一致低~中整包读写高难索引、难聚合读少写多低频读取的扩展属性独立扩展表1:1强一致中中大字段、冷字段拆表ES 搜索索引最终一致高双写/MQ 同步低复杂检索读多写少 多维搜索KV 缓存可丢/可重建低极低热点配置、短期幂等、分页偏好MQ 异步物化宽表最终一致写主表低异步高读低读多写少 报表/大屏查询时计算实时无额外写每次计算简单派生、枚举映射5.1关于虚拟字段ALTERTABLEpay_listADDCOLUMNvt_treasurerVARCHAR(64)GENERATED ALWAYSAS(IFNULL(JSON_UNQUOTE(JSON_EXTRACT(payData,$.treasurer)),))VIRTUAL,ADDINDEXidx_treasurer_finish_puton(vt_treasurer,finishTime,putOnTime);添加列新增一个名为 vt_treasurer 的列类型为 VARCHAR(64)虚拟生成列VIRTUAL 表示该列不实际存储数据而是在查询时实时计算区别于 STORED后者会在写入时计算并持久化存储计算逻辑JSON_EXTRACT(payData, ‘$.treasurer’)从 payData 字段JSON格式中提取 treasurer 键的值JSON_UNQUOTE(…)去掉提取结果外层的JSON引号转为普通字符串IFNULL(…, ‘’)如果提取结果为NULL则返回空字符串目的把嵌套在JSON字段里的 treasurer 值提取成一个普通列方便直接查询和索引。5.2 缺点与风险问题具体影响VIRTUAL的读取开销每次查询涉及该列都要实时计算高并发下CPU压力大STORED的写入开销INSERT/UPDATE时同步计算可能拖慢写入速度索引维护成本对虚拟列建索引后底层实际是函数索引索引维护有额外开销表达式限制不能包含子查询、变量、非确定性函数如NOW()、RAND()DDL锁表大表添加虚拟列/索引可能锁表MySQL 8.0.12 支持INSTANT DDL但有条件限制5.3 性能影响分析结合SQL具体场景-- 虚拟列 复合索引VIRTUALINDEXidx_treasurer_finish_puton正面影响查询 WHERE vt_treasurer ‘xxx’ 时走索引从全表扫描变为索引查找复合索引覆盖 vt_treasurer, finishTime, putOnTime 的联合查询条件时效率更高负面影响写入时索引需要维护INSERT/UPDATE/DELETE 会变慢但 VIRTUAL 本身不增加写入计算开销只有索引维护开销JSON提取的CPU成本虽然 VIRTUAL 不存储但索引构建和维护时仍需计算6. 决策流程是否是否读多写少是否读写均衡是否读少写多/写多读少是否新字段/新数据集是否参与事务/审核/金额等强一致?必须实际存储: 物理列或独立表是否需要 WHERE/ORDER/JOIN/唯一约束?读写类型?是否大表或多维复杂检索?MySQL 事实源 ES/KV/宽表 虚拟读层MySQL 索引列即可字段是否稳定且会长期查询?半虚拟: ext JSON 或扩展表是否需事后审计检索?实际存储 少量必要索引ext JSON / 日志表 / 异步归档6.1 场景具体分析-- vt_treasurer 从 payData JSON 中提取 treasurerVIRTUALINDEX评估这几个问题问题如果答案是是建议调整pay_list是否 5000万行是加索引可能锁表数小时考虑用STORED 业务双写或分库分表treasurer查询是否占该表查询的 80% 以上是考虑STORED避免每次查都解析JSON写入QPS是否 3000/s是VIRTUAL本身不拖慢写入但索引维护有成本监控Innodb_buffer_pool_pages_flushedpayData字段是否很大 4KB是JSON_EXTRACT解析成本高强烈建议STORED实用的验证方法-- 1. 看表实际大小SELECTtable_name,ROUND(data_length/1024/1024/1024,2)ASdata_GB,ROUND(index_length/1024/1024/1024,2)ASindex_GB,table_rowsFROMinformation_schema.tablesWHEREtable_namepay_list;-- 2. 看索引是否真被用到加索引后观察一周SELECT*FROMsys.schema_index_statisticsWHEREtable_namepay_list;-- 3. 看查询中 JSON 提取的耗时占比SHOWPROFILES;-- 或开启 performance_schema7. 选型评分卡快速打分对候选字段或数据集逐项打分≥ 8 分倾向实际存储≤ 4 分倾向虚拟/半虚拟。维度0 分1 分2 分强一致 / 事务可丢秒级延迟可接受必须强一致查询方式几乎不查偶发点查列表筛选/排序/关联读写比写远大于读均衡读远大于写数据稳定性结构频繁变偶尔变结构稳定表规模小表中表大表/超大表检索复杂度无简单等值多条件/全文/聚合示例采购单ext.cloth布种备注强一致 2 查询 0 读写 1 稳定 1 表规模 2 检索 0 ≈6 分→半虚拟 ext JSON 合理示例供应商audit_status强一致 2 查询 2 读写 1 稳定 2 表规模 1 检索 1 ≈9 分→必须物理列 索引8. 场景对照表Seller 项目场景读写类型表规模推荐方案说明供应商主表核心字段读写均衡中表实际存储编码、审核状态、邮箱等需唯一约束与筛选供应商biz_address_json等读少写多中表半虚拟 JSON结构化地址列表不按 JSON 内字段筛操作日志change_before/after读少写多大表实际存储 归档审计必须落库按时间归档采购单ext扩展读少写多大表半虚拟 JSON随单写入详情页读取不做复杂 SQL 条件列表多条件搜索百万级读多写少大表MySQL 事实源 ESMySQL 写ES 读禁止 ES 作唯一账本分页表头用户配置读多写少小表KV 虚拟pageModel用户偏好可重建导入任务进度读写均衡小表实际存储 KV任务表持久化进度可 KV 加速附件文件读少写多—对象存储 DB 元数据DB 只存 path/url不存二进制批量导入临时错误行写多读少中表实际存储 定期清理写密集读仅导出错误文件9. 边界与反模式9.1 不要用虚拟存储的情况金额、数量、审核状态、唯一业务键需要JOIN、GROUP BY、报表 SQL 直接聚合的字段跨系统对账、法务审计要求的原始数据写路径依赖「先查 ext 再改再写回」且并发高的字段JSON 整包更新易冲突9.2 常见反模式反模式问题修正大表所有字段塞ext无法建索引列表查询全表扫高频筛选字段提升为物理列ES 当主库写丢数据、无法事务MySQL 写 MQ 同步 ES小表过早上 ES运维成本高500 万行以内优先 MySQL 索引优化日志表加过多二级索引写放大严重只保留业务键 时间复合索引缓存当事实源数据丢失KV 仅存可重建数据9.3 ext JSON 使用红线满足任一即应从 ext 升级为物理列列表页WHERE / ORDER BY依赖该字段单表行数 ≥100 万且该字段参与 20%的查询需要唯一约束或外键语义应用层关联ext 单字段体积经常 2 KB且与主行高频一起读考虑扩展表10. 落地检查清单设计评审时逐项勾选已估算 7 日 R:W 或给出经验分类依据已估算 3 年行数判断是否进入「大表」强一致字段已全部实际存储虚拟/ES 层有重建方案从 MySQL 全量/增量同步大表有归档或分表策略500 万读少写多的表索引 ≤ 3 个含主键避免写放大读多写少的检索有覆盖索引或 ES避免深分页ext 字段有JSON Schema 文档键名、类型、是否废弃11. 快速查阅一句话结论问题结论多少算「读少写多」日W:R ≥ 3:1或峰值写 QPS ≥ 读 QPS × 3且少复杂列表检索多少算「大表」行数≥ 500 万或表空间≥ 10 GB满足 2 条即按大表治理何时实际存储强一致、要筛选/排序/唯一约束、参与 JOIN/报表何时半虚拟 ext随主单读写、结构可能变、不参与 SQL 条件何时 ES/KV 等虚拟读层读多写少 复杂检索或热点读且 MySQL 仍是事实源12. 修订记录版本日期说明v1.02026-05-19初版量化阈值、决策流程、Seller 场景对照
MYSQL什么算大表？该独立字段还是JSON？虚拟存储(VIRTUAL) vs 实际存储(STORED) — 选型界定分析
虚拟存储(VIRTUAL) vs 实际存储(STORED) — 选型界定分析1. 文档目的在表结构设计、字段落库、索引/搜索层拆分时经常需要回答三个问题这个场景算不算「读少写多」这张表算不算「大表」字段/数据应该实际存储物理列/独立表还是虚拟存储扩展 JSON / 搜索索引 / 缓存 / 异步物化本文给出可量化阈值 决策流程 项目内示例避免凭感觉选型。2. 术语定义术语含义Seller 项目典型实现实际存储数据以 MySQL物理列或独立业务表持久化作为唯一事实源Source of Truth采购单主表字段、seller_supplier_company.supplier_code半虚拟存储仍在 MySQL但以JSON/ext 扩展字段存非核心、低频查询属性采购单ext字段cloth、mpmSellerPrice 等虚拟存储派生存储从事实源衍生出来服务于读/搜/缓存允许最终一致ES 搜索索引、KV 分页配置、MQ 异步宽表计算虚拟查询时实时计算不落库列表页汇总金额、状态文案映射原则写路径永远以实际存储为准虚拟层只读或可重建不可单独作为账务/审核等强一致数据的唯一来源。3. 读写特征如何量化界定3.1 核心指标至少采集其中 2 项指标说明建议观测窗口日读写比 R:W单日 SELECT 次数 / INSERTUPDATEDELETE 次数7 日滑动平均峰值 QPS 比读 QPS / 写 QPS或反向业务高峰 1 小时读路径复杂度是否多条件筛选、排序、聚合、全文检索按 SQL/接口统计写放大系数一次业务写操作触发的 DB 行更新次数含日志、索引、ES 同步链路追踪一致性要求强一致 / 可接受秒级延迟 / 可接受分钟级业务定义3.2 读写类型分级日读写比 R:W类型日读写比 R:W峰值 QPS 特征典型场景读多写少≥ 10 : 1读 QPS ≥ 写 QPS ×5列表搜索、报表、看板、导出读写均衡3 : 1 ~ 10 : 1读写同量级主业务单据采购单、供应商主数据读少写多≤ 1 : 3即 W:R ≥ 3:1写 QPS ≥ 读 QPS ×3操作日志、状态流水、MQ 消费落库写多读少≤ 1 : 10即 W:R ≥ 10:1写远大于读读多为后台补偿埋点、审计快照、同步队列、Session「读少写多」的实用判定满足以下任意 2 条即可归类① 日 W:R ≥ 3:1② 峰值写 QPS ≥ 读 QPS × 3③ 单条业务操作平均产生 ≥ 3 次 INSERT/UPDATE写放大④ 读请求 80% 以上为按主键/唯一键点查几乎无列表检索3.3 没有监控数据时的经验默认值数据形态默认读写类型理由主单据头 明细读写均衡创建/修改与列表查询并存操作日志 / 审核记录读少写多每次操作必写极少按复杂条件查列表页 多维度筛选读多写少查询远多于单条更新导入/批量任务明细写多读少批量 INSERT几乎不读扩展属性展示用读少写多随主单写随主单更新单独检索少4. 「大表」如何清晰界定单表建议控制在 500 万行以内。以下为分级 多维判定避免只看行数。4.1 数据量级分级级别行数估算表空间运维影响特征DDL风险小表 100 万 2 GBALTER、备份快可适度加索引秒级DDL几乎无感知低中表100 万 ~500 万2 ~ 10 GB需关注索引数量与慢 SQL分钟级DDL需选低峰期中大表500 万 ~ 5000 万10 ~ 100 GB应考虑归档、分表、读写分离小时级DDL可能锁表阻塞业务高超大表 5000 万 100 GB必须分库分表或冷热分离必须走Online DDL或pt-osc/gh-ost工具极高关键阈值InnoDB 单表超过 2000万行B树深度增加随机IO性能开始下降单表超过 50GB备份、迁移、DDL 时间成本陡增索引大小超过 10GB添加索引的耗时和锁表风险显著4.2 「算大表」的判定规则满足任意 2 条#条件说明A行数 ≥500 万与项目规范一致B表空间 ≥10 GB宽表、TEXT/JSON 多时也需警惕C典型列表查询扫描行数≥ 50 万EXPLAIN rows索引未覆盖D单次 ALTER / 在线 DDL预计 30 分钟影响发版窗口E二级索引总大小 InnoDB Buffer Pool 的 30%写放大、缓存命中率差F历史数据 80%几乎不被业务访问适合归档而非继续堆在主表4.3 大表 ≠ 必须用 ES大表只说明MySQL 单表承载压力变大解法是归档 / 分表 / 冷热分离优先收窄索引、避免SELECT *、禁止深分页OFFSET 10 万读多写少且有多维检索时再考虑 ES 等虚拟读层5. 存储形态对照形态一致性写成本读成本适用读写类型MySQL 物理列强一致中索引维护低~中有索引时读写均衡需 WHERE/ORDER/JOIN 的字段MySQL JSON/ext强一致低~中整包读写高难索引、难聚合读少写多低频读取的扩展属性独立扩展表1:1强一致中中大字段、冷字段拆表ES 搜索索引最终一致高双写/MQ 同步低复杂检索读多写少 多维搜索KV 缓存可丢/可重建低极低热点配置、短期幂等、分页偏好MQ 异步物化宽表最终一致写主表低异步高读低读多写少 报表/大屏查询时计算实时无额外写每次计算简单派生、枚举映射5.1关于虚拟字段ALTERTABLEpay_listADDCOLUMNvt_treasurerVARCHAR(64)GENERATED ALWAYSAS(IFNULL(JSON_UNQUOTE(JSON_EXTRACT(payData,$.treasurer)),))VIRTUAL,ADDINDEXidx_treasurer_finish_puton(vt_treasurer,finishTime,putOnTime);添加列新增一个名为 vt_treasurer 的列类型为 VARCHAR(64)虚拟生成列VIRTUAL 表示该列不实际存储数据而是在查询时实时计算区别于 STORED后者会在写入时计算并持久化存储计算逻辑JSON_EXTRACT(payData, ‘$.treasurer’)从 payData 字段JSON格式中提取 treasurer 键的值JSON_UNQUOTE(…)去掉提取结果外层的JSON引号转为普通字符串IFNULL(…, ‘’)如果提取结果为NULL则返回空字符串目的把嵌套在JSON字段里的 treasurer 值提取成一个普通列方便直接查询和索引。5.2 缺点与风险问题具体影响VIRTUAL的读取开销每次查询涉及该列都要实时计算高并发下CPU压力大STORED的写入开销INSERT/UPDATE时同步计算可能拖慢写入速度索引维护成本对虚拟列建索引后底层实际是函数索引索引维护有额外开销表达式限制不能包含子查询、变量、非确定性函数如NOW()、RAND()DDL锁表大表添加虚拟列/索引可能锁表MySQL 8.0.12 支持INSTANT DDL但有条件限制5.3 性能影响分析结合SQL具体场景-- 虚拟列 复合索引VIRTUALINDEXidx_treasurer_finish_puton正面影响查询 WHERE vt_treasurer ‘xxx’ 时走索引从全表扫描变为索引查找复合索引覆盖 vt_treasurer, finishTime, putOnTime 的联合查询条件时效率更高负面影响写入时索引需要维护INSERT/UPDATE/DELETE 会变慢但 VIRTUAL 本身不增加写入计算开销只有索引维护开销JSON提取的CPU成本虽然 VIRTUAL 不存储但索引构建和维护时仍需计算6. 决策流程是否是否读多写少是否读写均衡是否读少写多/写多读少是否新字段/新数据集是否参与事务/审核/金额等强一致?必须实际存储: 物理列或独立表是否需要 WHERE/ORDER/JOIN/唯一约束?读写类型?是否大表或多维复杂检索?MySQL 事实源 ES/KV/宽表 虚拟读层MySQL 索引列即可字段是否稳定且会长期查询?半虚拟: ext JSON 或扩展表是否需事后审计检索?实际存储 少量必要索引ext JSON / 日志表 / 异步归档6.1 场景具体分析-- vt_treasurer 从 payData JSON 中提取 treasurerVIRTUALINDEX评估这几个问题问题如果答案是是建议调整pay_list是否 5000万行是加索引可能锁表数小时考虑用STORED 业务双写或分库分表treasurer查询是否占该表查询的 80% 以上是考虑STORED避免每次查都解析JSON写入QPS是否 3000/s是VIRTUAL本身不拖慢写入但索引维护有成本监控Innodb_buffer_pool_pages_flushedpayData字段是否很大 4KB是JSON_EXTRACT解析成本高强烈建议STORED实用的验证方法-- 1. 看表实际大小SELECTtable_name,ROUND(data_length/1024/1024/1024,2)ASdata_GB,ROUND(index_length/1024/1024/1024,2)ASindex_GB,table_rowsFROMinformation_schema.tablesWHEREtable_namepay_list;-- 2. 看索引是否真被用到加索引后观察一周SELECT*FROMsys.schema_index_statisticsWHEREtable_namepay_list;-- 3. 看查询中 JSON 提取的耗时占比SHOWPROFILES;-- 或开启 performance_schema7. 选型评分卡快速打分对候选字段或数据集逐项打分≥ 8 分倾向实际存储≤ 4 分倾向虚拟/半虚拟。维度0 分1 分2 分强一致 / 事务可丢秒级延迟可接受必须强一致查询方式几乎不查偶发点查列表筛选/排序/关联读写比写远大于读均衡读远大于写数据稳定性结构频繁变偶尔变结构稳定表规模小表中表大表/超大表检索复杂度无简单等值多条件/全文/聚合示例采购单ext.cloth布种备注强一致 2 查询 0 读写 1 稳定 1 表规模 2 检索 0 ≈6 分→半虚拟 ext JSON 合理示例供应商audit_status强一致 2 查询 2 读写 1 稳定 2 表规模 1 检索 1 ≈9 分→必须物理列 索引8. 场景对照表Seller 项目场景读写类型表规模推荐方案说明供应商主表核心字段读写均衡中表实际存储编码、审核状态、邮箱等需唯一约束与筛选供应商biz_address_json等读少写多中表半虚拟 JSON结构化地址列表不按 JSON 内字段筛操作日志change_before/after读少写多大表实际存储 归档审计必须落库按时间归档采购单ext扩展读少写多大表半虚拟 JSON随单写入详情页读取不做复杂 SQL 条件列表多条件搜索百万级读多写少大表MySQL 事实源 ESMySQL 写ES 读禁止 ES 作唯一账本分页表头用户配置读多写少小表KV 虚拟pageModel用户偏好可重建导入任务进度读写均衡小表实际存储 KV任务表持久化进度可 KV 加速附件文件读少写多—对象存储 DB 元数据DB 只存 path/url不存二进制批量导入临时错误行写多读少中表实际存储 定期清理写密集读仅导出错误文件9. 边界与反模式9.1 不要用虚拟存储的情况金额、数量、审核状态、唯一业务键需要JOIN、GROUP BY、报表 SQL 直接聚合的字段跨系统对账、法务审计要求的原始数据写路径依赖「先查 ext 再改再写回」且并发高的字段JSON 整包更新易冲突9.2 常见反模式反模式问题修正大表所有字段塞ext无法建索引列表查询全表扫高频筛选字段提升为物理列ES 当主库写丢数据、无法事务MySQL 写 MQ 同步 ES小表过早上 ES运维成本高500 万行以内优先 MySQL 索引优化日志表加过多二级索引写放大严重只保留业务键 时间复合索引缓存当事实源数据丢失KV 仅存可重建数据9.3 ext JSON 使用红线满足任一即应从 ext 升级为物理列列表页WHERE / ORDER BY依赖该字段单表行数 ≥100 万且该字段参与 20%的查询需要唯一约束或外键语义应用层关联ext 单字段体积经常 2 KB且与主行高频一起读考虑扩展表10. 落地检查清单设计评审时逐项勾选已估算 7 日 R:W 或给出经验分类依据已估算 3 年行数判断是否进入「大表」强一致字段已全部实际存储虚拟/ES 层有重建方案从 MySQL 全量/增量同步大表有归档或分表策略500 万读少写多的表索引 ≤ 3 个含主键避免写放大读多写少的检索有覆盖索引或 ES避免深分页ext 字段有JSON Schema 文档键名、类型、是否废弃11. 快速查阅一句话结论问题结论多少算「读少写多」日W:R ≥ 3:1或峰值写 QPS ≥ 读 QPS × 3且少复杂列表检索多少算「大表」行数≥ 500 万或表空间≥ 10 GB满足 2 条即按大表治理何时实际存储强一致、要筛选/排序/唯一约束、参与 JOIN/报表何时半虚拟 ext随主单读写、结构可能变、不参与 SQL 条件何时 ES/KV 等虚拟读层读多写少 复杂检索或热点读且 MySQL 仍是事实源12. 修订记录版本日期说明v1.02026-05-19初版量化阈值、决策流程、Seller 场景对照
