大表优化需结合场景综合施策：先定位瓶颈（EXPLAIN、慢日志、进程列表），再针对性建覆盖索引、历史归档、冷热分离；DDL须预演并用工具平滑变更。
大表优化不是一招鲜，关键看场景：数据量、查询模式、更新频率、硬件资源共同决定策略。盲目加索引或分库分表反而可能拖慢系统。
先搞清瓶颈在哪
别急着改表结构。用 EXPLAIN 看执行计划，确认是全表扫描、临时表、文件排序，还是锁等待；查 slow_query_log 找真实慢 SQL；用 SHOW PROCESSLIST 观察活跃连接和阻塞情况。常见假象是“数据量大=慢”，实际可能是某条没走索引的统计查询在拖垮整张表。
索引不是越多越好，而是要准
复合索引要匹配最左前缀，且字段顺序按区分度+过滤频率综合排；避免对低区分度字段（如 status、is_deleted）单独建索引；删除长期不用或重复的索引（sys.schema_unused_indexes 可辅助识别）。例如 user 表常查 WHERE city = ? AND age > ? ORDER BY created_at DESC，那就建 (city, age, created_at) 覆盖索引，而非三个单列索引。
合理拆分，别为拆而拆
水平拆分（分表/分库）只在单机扛不住时考虑，优先尝试：
- 历史归档：把 1 年前订单移到 orders_archive，主表保持 2000 万行内；
- 冷热分离：把用户资料中访问少的字段（如简历附件 URL）拆到扩展表；
- 读写分离+连接池控制：报表类查询走从库，避免拖慢主库事务。
DDL 操作必须避开业务高峰
MySQL 5.6+ 支持 ALGORITHM=INPLACE 的在线 DDL，但并非所有操作都真正“无锁”。加索引一般可在线，但修改字段类型、重命名列仍可能锁表。生产环境务必：
- 在从库预演一遍；
- 用 pt-online-schema-change 或 gh-ost 做平滑变更；
- 提前检查磁盘空间（临时表、日志、副本都会占空间）。
不复杂但容易忽略。
