MySQL 5.6 升级至 5.7 的性能提升集中在 ICP 默认启用、InnoDB 缓冲池分实例优化及多源复制等关键机制；但需主动验证配置与执行计划，否则优势无法自动生效。
MySQL 5.6 到 5.7 的性能提升不是均匀分布的，真正能带来可观收益的点集中在少数几个关键机制上，其中 ICP（Index Condition Pushdown）和 multi-source replication 是两类典型：前者直接影响单实例查询效率，后者解决的是架构级扩展瓶颈。但要注意，它们作用域完全不同，不能混为一谈来“对比性能”。
ICP 在 5.6 和 5.7 中的行为差异
ICP 是 MySQL 5.6 引入的优化特性，但默认关闭；5.7 中默认开启，且引擎层支持更彻底。
-
EXPLAIN输出中出现Using index condition才表示 ICP 实际生效，5.6 下常因optimizer_switch未启用或存储引擎不支持（如 MyISAM）而失效 - 5.7 的
InnoDB对虚拟列、函数索引等场景下 ICP 支持更稳定，比如WHERE json_extract(col, '$.name') = 'foo'在 5.7 可下推，在 5.6 多数情况会全索引扫描后过滤 - 参数
optimizer_switch='index_condition_pushdown=on'在 5.6 必须显式设置；5.7 默认为on，但若升级后从 5.6 配置文件直接复用，可能仍继承旧值导致 ICP 未启用
多源复制不是性能优化，而是高可用架构能力补全
multi-source replication 在 5.6 完全不存在，是 5.7 新增的复制拓扑能力，它不提升单条 SQL 的执行速度，但改变数据聚合与灾备逻辑。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 5.7 中一个从库可同时拉取多个主库的
binlog，需配置CHANGE MASTER TO ... FOR CHANNEL 'ch1'，每个 channel 独立维护relay_log和复制位点 - 它对写入吞吐无加成，反而因多线程解析 relay log 增加 CPU 开销；但显著降低跨业务线数据汇总延迟，例如将订单、用户、支付三个库实时归集到分析从库
- 容易踩坑：5.7 的多源复制不支持 GTID 混合使用（即不同 channel 不能同时开启
gtid_mode=ON），否则启动失败并报错ERROR 3094 (HY000): Cannot use GTID mode on slave with multiple sources
真正影响性能的其实是配套参数与默认行为变化
单独看 ICP 或多源复制，容易忽略背后更关键的默认配置迁移成本。
- 5.7 默认
sql_mode更严格（含STRICT_TRANS_TABLES），可能导致原本在 5.6 成功插入的脏数据在 5.7 报错，间接拖慢批量导入流程 -
innodb_buffer_pool_instances在 5.6 默认为 1，5.7 提升为 8（当 buffer pool > 1G），这在高并发更新下减少 mutex 争用，但若物理内存不足却硬设高值，反而引发频繁 page flush -
performance_schema在 5.7 默认启用且采集项更多，监控开销比 5.6 明显上升，压测时若未关掉，可能误判为“5.7 更慢”
ICP 是否生效、多源复制能否落地，都高度依赖具体 SQL 模式和部署拓扑。最常被忽略的是：5.7 的性能优势不会自动到来，它要求你主动检查 EXPLAIN 输出、验证 slave_status 中各 channel 的 Seconds_Behind_Master，以及确认 SHOW VARIABLES LIKE 'optimizer_switch' 的实际值——而不是只看版本号。
