MySQL主从复制会同步索引结构（如CREATE INDEX），但不同步索引使用状态或统计信息；需在从库执行ANALYZE TABLE并用EXPLAIN验证索引是否实际被选用。
从库索引是否自动同步？
MySQL 主从复制只同步数据和 DDL（如 CREATE INDEX、DROP INDEX），不自动同步索引的「使用状态」或「统计信息」。但关键点在于：只要你在主库执行了建索引的 DDL，从库会原样重放，索引结构就存在；反之，如果没在主库显式建过，从库上 SHOW INDEXES FROM tbl 就看不到对应索引。
常见误解是“主库有索引，从库查询慢 = 从库索引失效”，其实更可能是：从库索引根本没建，或者建了但没被查询命中（比如查询条件触发了前述任意一种失效场景）。
- 主库执行
CREATE INDEX idx_name ON t(col)→ 从库会同步创建该索引 - 主库仅靠写入时隐式生成（如主键、唯一约束）→ 对应索引也会同步
- 主库未建索引，仅靠应用层“以为有” → 从库
SHOW INDEXES查不到，EXPLAIN的key必为NULL
如何确认从库索引真实存在且可用？
不能只看 SHOW CREATE TABLE 或表结构描述，必须验证索引是否被实际选用。最直接的方式是在从库上对目标查询执行 EXPLAIN，并比对关键字段：
-
key字段非NULL，且值为你预期的索引名（如idx_status_created） -
type不是ALL（全表扫描），优先是ref、range或eq_ref -
rows显著小于表总行数（例如表有 100 万行，rows是 2000，说明走了索引过滤） - 注意：从库的
EXPLAIN结果可能和主库不一致——因为从库的统计信息（INFORMATION_SCHEMA.STATISTICS）可能滞后，尤其在低频更新或未ANALYZE TABLE的情况下
为什么从库 EXPLAIN 显示没走索引，但主库可以？
核心原因通常是统计信息不同步或查询计划缓存差异，不是“索引失效”本身。MySQL 优化器依赖表的行数、索引基数（cardinality）、数据分布等统计信息做决策。从库若长期只读、未触发自动更新，这些统计可能陈旧，导致优化器误判“走索引不如全表扫快”，从而放弃使用。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 手动刷新统计：在从库执行
ANALYZE TABLE tbl_name，强制重新采样 - 检查统计时效：对比主从库的
SELECT table_rows, avg_row_length FROM INFORMATION_SCHEMA.TABLES WHERE table_name = 'tbl_name'，若差异大，说明统计已漂移 - 避免依赖缓存：从库默认开启
query_cache_type=OFF（5.7+ 已移除），但要注意optimizer_switch中的use_index_extensions等开关是否主从一致
从库要不要单独建索引？
可以，但必须明确目的：只为优化从库特有查询（如报表类、ETL 拉取语句），且这些查询不在主库执行。否则，额外索引会拖慢从库的复制回放速度（每个写操作都要维护更多索引树），还可能因主从 DDL 不一致引发后续问题。
- 主库已有索引满足业务写入 + 读取 → 从库无需重复建
- 从库有专属慢查询（如
WHERE date_col BETWEEN ... AND ... GROUP BY ...），而主库完全不用 → 可在从库加覆盖索引，但需记录并同步到主库迁移方案中 - 加索引前先在从库
EXPLAIN验证原查询确实没走索引，再确认该索引能覆盖WHERE + ORDER BY + SELECT列（避免Using filesort或Using temporary）
真正容易被忽略的不是“建不建”，而是建完后没跑 ANALYZE TABLE，以及没用 EXPLAIN 在从库现场验证——很多团队只在主库调优，直接把执行计划结论套用到从库，结果查半天才发现统计信息早就不准了。
