MySQL大数据量处理核心是“分而治之”+“精准干预”，需结合业务场景判断增长模式、访问特征与瓶颈类型，再选择分表（水平/时间）、索引优化（联合索引顺序、覆盖索引）、读写分离、缓存策略及运维诊断等综合手段。
MySQL 大数据量处理不是单纯拼硬件或加索引，核心在于“分而治之”+“精准干预”。面试中考察的从来不是你背过多少优化口诀，而是能否结合业务场景，判断数据增长模式、访问特征和瓶颈类型，再选择合适策略。
分表：不是为了分而分，要看增长节奏和查询边界
单表超千万行后，写入变慢、ALTER TABLE卡顿、备份恢复耗时长，是典型信号。但分表前先确认：数据是否天然有业务维度隔离？比如订单按用户ID哈希、日志按时间范围归档、用户资料按地域分区。
- 水平分表：推荐用ShardingSphere或MyCat做中间层，避免业务代码硬编码路由逻辑；自研分表需统一维护分片键（如 user_id % 16）并确保查询必带该字段，否则跨分片JOIN代价极高
- 时间分表：日志类、监控类表按月/周建表（order_202401、order_202402），配合EVENT自动建下月表 + 清理过期表；查询时用UNION ALL合并，但WHERE条件必须能命中具体子表，否则全表扫描
- 别一上来就分库：单库多表分片已能扛住亿级数据；跨库事务难保证、分布式ID生成复杂、运维成本陡增，除非QPS持续超5000且读写比均衡
索引优化：警惕“伪高效”，重点看执行计划里的实际行为
EXPLAIN结果里出现type=ALL、rows远大于实际返回数、Extra含Using filesort/Using temporary，就是索引失效的明确证据。但优化不能只盯着WHERE条件加索引。
- 联合索引顺序要匹配查询模式：WHERE a=? AND b>? ORDER BY c，索引应为(a,b,c)，而非(b,a,c)；b是范围查询时，c无法走索引排序，ORDER BY c仍会触发filesort
- 覆盖索引减少回表：SELECT id,name,created_at FROM user WHERE status=1，可建(status,id,name,created_at)索引，避免查到主键后再回聚簇索引取其他字段
- 大字段不参与索引：TEXT/BLOB列不建普通索引；若需模糊搜索，改用全文索引（MATCH AGAINST）或引入Elasticsearch
读写分离与缓存：让数据库只干它最擅长的事
读多写少场景下，主库专注写入和强一致性更新，从库承担报表、列表页等非实时查询。但要注意延迟陷阱和缓存穿透风险。
- 从库延迟监控必须落地：用SHOW SLAVE STATUS中的Seconds_Behind_Master + 自定义心跳表（主库定时写时间戳，从库读取对比）双校验；用户刚提交订单就跳转详情页，必须强制读主库
- 缓存更新策略选对场景：高频读低频写用Cache-Aside（先删缓存再更新DB）；写远多于读用Write-Through（同步写缓存+DB）；避免Cache-Aside在并发更新时出现脏数据，可用分布式锁或版本号控制
- 冷热数据分离：近3个月订单放SSD主库，历史订单归档至HDD从库或对象存储；用视图或应用层路由屏蔽物理位置差异
运维与诊断：线上问题不靠猜，靠指标+日志+快照
面试常问“慢查询突然增多怎么查”，答案不是“看slow log”，而是建立完整可观测链路。
- 慢查询阈值设为0.1秒而非1秒：高并发下0.5秒的SQL每秒跑100次，已占满单核CPU；配合pt-query-digest分析TOP消耗SQL，重点关注Rows_examined/Rows_sent比例＞100的语句
- 定期采集Performance Schema快照：关注events_statements_summary_by_digest中LOCK_TIME高、SORT_MERGE_PASSES多的语句，定位锁竞争或内存不足导致磁盘排序
- 备份策略必须验证恢复：XtraBackup全量+binlog增量备份后，每月随机抽1份做恢复演练；特别检查GTID一致性，避免主从切换后复制中断
