不能直接删除 relay-log.index 后 start slave，因为 MySQL 启动或 START SLAVE 时严格按该索引文件逐行加载 relay log，删除后会导致 Could not read from relay log index file 等错误，无法自动重建索引或识别磁盘上真实存在的 relay log 文件。
直接删掉 relay-log.index 文件然后重启复制，大概率导致 START SLAVE 失败或 SQL 线程卡死——MySQL 不会自动重建索引，也不会猜你磁盘上有哪些 relay log 文件。
为什么不能直接删除 relay-log.index 后 start slave
MySQL 启动或 START SLAVE 时，会严格按 relay-log.index 里写的路径逐行加载 relay log 文件。如果文件被删但没重建，它会在第一条就报 Could not read from relay log index file 或 Failed to open the relay log index file；如果文件存在但索引内容为空/乱码/顺序错，SQL 线程可能读到非法偏移、解析失败、甚至跳过事务。
-
RESET SLAVE会清空索引并重置位点，但它不保证磁盘上还留着对应文件——若 relay_log_purge=ON，旧文件可能已被删光 - 仅执行
STOP SLAVE; START SLAVE;不会触发索引重建逻辑，relay_log_recovery=ON也只在 mysqld 进程启动时生效，不是START SLAVE时生效 - 手动删了
relay-log.index却没补内容，MySQL 就像拿到一张空白地图，根本不知道从哪条 relay log 开始读
安全重建 relay-log.index 的三步实操
核心是让索引内容与磁盘真实存在的 relay log 文件完全一致，且顺序正确（按生成时间升序）。
- 先停复制：
STOP SLAVE;，再确认没有Slave_IO_Running: Yes（用SHOW PROCESSLIST或ps aux | grep mysql查） - 进 relay log 所在目录：执行
SELECT @@datadir;和SELECT @@relay_log_basename;，cd 到对应路径（如/var/lib/mysql/），确保你在hostname-relay-bin.*文件所在目录 - 生成新索引：
ls -1v hostname-relay-bin.[0-9]* > relay-log.index（-v是关键，避免000010排在00002前面）；用head -n 3 relay-log.index快速核对是否为合法文件名、无空行、无重复
重建后必须立刻验证的三个信号
文件写完只是开始，MySQL 是否真正接受它，得看运行态反馈。
-
START SLAVE;后马上执行SHOW SLAVE STATUS\G，重点看：Relay_Log_File是否指向你索引里最后一行的文件名，且Relay_Log_Pos > 4（说明已定位到有效事件起始位置） - 查错误日志有没有新报
Could not find target log during relay log initialization——这代表索引写了某个文件，但磁盘上已不存在（被 purge 或误删） - 确认变量值：
SELECT @@relay_log_index;输出路径必须和你刚写的relay-log.index文件路径一致（注意相对/绝对路径是否匹配relay_log_basename配置）
最容易被忽略的是权限和路径一致性：MySQL 进程用户（如 mysql）必须对 relay-log.index 文件有读写权限，且该文件必须和所有 *-relay-bin.* 文件在同一目录下——跨目录或权限不对，重建等于白做。
