字段超50个导致读写变慢，主因是宽表加剧存储溢出、内存浪费、复制延迟及索引低效；应按访问频率拆分低频字段，慎用JSON，优先控制查询粒度而非盲目加索引。
字段超过 50 个的表读写明显变慢，为什么？
不是字段多本身拖慢 MySQL，而是宽表放大了存储、内存、网络和索引的连锁负担。每行数据在 InnoDB 中按 ROW_FORMAT=COMPACT 存储时，字段越多，行长度越容易突破页内单行限制（约 8KB），触发“溢出页（off-page）”——TEXT/BLOB 类型字段会直接存到独立页，但普通 VARCHAR 超长后也会被挤出去，导致一次查询要读多个物理页。
更隐蔽的是内存压力：SELECT * 或未加 WHERE 条件的更新，会让 buffer pool 加载大量无用字段；复制延迟也常源于主库写入宽行后，从库解析、应用耗时陡增。
- 字段数 > 100 且含多个
VARCHAR(1024)或JSON，InnoDB 行记录很可能跨页 -
SHOW CREATE TABLE查看实际Row_format和avg_row_length，比单纯数字段更有参考价值 - MySQL 8.0+ 的隐藏字段（如
row_id、trx_id）不计入用户字段数，但占用空间
哪些字段该拆到关联表？看访问模式，不是看类型
拆表不是为了“范式正确”，而是切断低频字段对高频操作的干扰。比如用户表有 60 个字段，其中 50 个是埋点上报字段（last_app_version、push_token_expired_at 等），日常登录、鉴权只查 id、email、status —— 这些埋点字段就该挪走。
- 拆分前先用
pt-query-digest或慢日志统计：哪些字段在SELECT/UPDATE中出现频率低于 5% - 避免为“可能用到”预留字段，
extra_info_json这种兜底字段反而让优化器失效，且无法建有效索引 - 拆出的扩展表务必加
UNIQUE KEY (main_table_id)，别只依赖外键约束，否则JOIN性能不可控
JSON 字段真能省事？小心索引和事务陷阱
用 JSON 存动态字段看似减少拆表，但代价明确：无法为 JSON 内字段建常规索引（除非 MySQL 5.7+ 的虚拟列 + 函数索引），且每次更新整条 JSON 都会锁住整行，高并发下极易阻塞。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 若需按 JSON 内某 key 查询，必须搭配虚拟列：
ALTER TABLE t ADD COLUMN status_code INT AS (JSON_UNQUOTE(JSON_EXTRACT(data, '$.status'))) STORED，再在该列建索引 -
JSON_SET()、JSON_REPLACE()在事务中执行时，即使只改一个 key，InnoDB 仍会对整行加 X 锁 - 备份恢复时，
mysqldump默认把 JSON 当字符串导出，格式缩进/换行差异可能导致 diff 误报，建议加--skip-extended-insert统一风格
宽表加索引反而更慢？优先压缩而非覆盖
字段多的表上建联合索引，很容易让索引本身膨胀到比数据还大。尤其当包含 VARCHAR(500) 字段时，B+ 树节点里存不下完整值，只能存前缀（默认 767 字节），导致索引区分度暴跌，优化器干脆放弃使用。
- 用
SHOW INDEX FROM t查看Sub_part列，非 0 值说明该列用了前缀索引，需评估是否真能命中业务查询条件 - 替代方案：对长文本字段启用
innodb_large_prefix=ON（需ROW_FORMAT=DYNAMIC），或改用哈希索引（仅适用于等值查询） - 比加索引更有效的是控制查询粒度：
SELECT id, name FROM user WHERE ...比SELECT *快不止一倍，尤其在网卡带宽受限时
宽表最麻烦的从来不是设计那一刻，而是半年后新加三个“临时字段”，没人记得当初的拆分逻辑，也没人敢动老接口——留好字段变更记录比选对方案更重要。
