mysql崩溃后无法靠ib_logfile和ibdata1恢复未提交事务，因innodb在重启时自动回滚未写入ibdata1的活跃事务（通过undo log），该过程无需人工干预。
MySQL 崩溃后如何靠 ib_logfile 和 ibdata1 恢复未提交事务？
MySQL 崩溃时，未写入磁盘的事务不会凭空消失——它们可能还留在 InnoDB 的重做日志（ib_logfile0、ib_logfile1）里。但恢复行为取决于 innodb_flush_log_at_trx_commit 设置和崩溃发生时机。
默认值为 1 时，每次事务提交都强制刷日志到磁盘，崩溃后可完整恢复已提交事务；若设为 0 或 2，则可能丢失最近 1 秒内的提交数据。注意：ib_logfile 不存储未提交事务的最终状态，只记录物理页变更；崩溃重启时，InnoDB 会回滚所有未写入 ibdata1 的活跃事务（通过 undo log），这个过程自动完成，无需人工干预。
-
ib_logfile大小由innodb_log_file_size控制，过小会导致频繁 checkpoint，影响写性能；过大则崩溃恢复时间变长 - 修改
innodb_log_file_size必须先停库、删除旧ib_logfile*、再启动，否则 MySQL 拒绝启动 - 不要手动删除或清空
ib_logfile*，否则可能造成数据字典与日志不一致，启动失败并报错InnoDB: The log sequence number in ibdata files does not match...
误删表后能否用 mysqlbinlog 回滚到某个时间点？
可以，但前提是开启了 binlog（log_bin=ON）且格式为 ROW 或 MIXED。STATEMENT 格式在非确定性函数（如 NOW()、UUID()）下无法精确重放。
关键操作是定位误操作位置：用 mysqlbinlog --base64-output=DECODE-ROWS -v 解析 binlog，搜索 DROP TABLE 或 DELETE FROM 语句附近的 GTID 或 at position 值。然后用 --stop-position 或 --until-datetime 截断恢复。
- 恢复前务必先停止应用写入，避免新数据污染 binlog 流
-
mysqlbinlog输出含# at 12345行，该数字即 position，用于--start-position/--stop-position - 如果启用了 GTID，优先用
--exclude-gtids跳过指定事务，比 position 更可靠 - 切勿直接将
mysqlbinlog输出管道给mysql执行——除非你确认其中不含DROP或CREATE等 DDL，否则可能二次破坏结构
FLUSH LOGS 和 RESET MASTER 对恢复能力的影响
FLUSH LOGS 会关闭当前 binlog 文件并新建一个，不影响已有日志内容，对恢复无风险；而 RESET MASTER 会彻底清空所有 binlog 文件，并重置 mysql-bin.000001 计数器——这意味着此前所有基于 binlog 的时间点恢复能力立即失效。
ECTouch是上海商创网络科技有限公司推出的一套基于 PHP 和 MySQL 数据库构建的开源且易于使用的移动商城网店系统！应用于各种服务器平台的高效、快速和易于管理的网店解决方案，采用稳定的MVC框架开发，完美对接ecshop系统与模板堂众多模板，为中小企业提供最佳的移动电商解决方案。ECTouch程序源代码完全无加密。安装时只需将已集成的文件夹放进指定位置，通过浏览器访问一键安装，无需对已有
生产环境禁止执行 RESET MASTER，除非你明确知道：① 已完成全量备份 + 最新 binlog 归档；② 所有从库已同步到最新位点；③ 后续只依赖新 binlog 做恢复。
-
PURGE BINARY LOGS TO 'mysql-bin.000010'是安全替代方案，只删指定序号之前的日志 -
PURGE BINARY LOGS BEFORE '2024-06-01 00:00:00'更常用，但需确保系统时间与 binlog 时间戳一致（受log_timestamps=SYSTEM影响） - 定期归档 binlog 到远程存储（如 S3/NAS），而非仅依赖本地
PURGE，避免磁盘满导致 binlog 写入失败进而阻塞事务
为什么 innodb_force_recovery > 0 启动后不能执行 INSERT/UPDATE/DELETE？
因为 innodb_force_recovery 是只读抢救模式：它跳过崩溃恢复中可能出错的步骤（如 undo log 回滚、insert buffer 合并），让 MySQL 能“勉强”启动并导出数据，但此时引擎处于不一致状态，任何写操作都可能导致内存结构损坏或后续无法退出。
正确做法是：设置 innodb_force_recovery=1~6（从小尝试），启动后立刻用 mysqldump 导出还能访问的表，然后重建实例导入。导出时加 --single-transaction 避免锁表，但要注意该参数在 force_recovery > 0 时可能失效，此时改用 --lock-tables=false 并接受部分表不可导出。
- 值为
4及以上时，InnoDB 会禁用 insert buffer，可能显著拖慢 dump 速度 - 一旦设置过
innodb_force_recovery，必须在成功导出后彻底删除ib_logfile*和ibdata1，否则下次启动仍会尝试 recovery - 不要在 force_recovery 模式下执行
ALTER TABLE或DROP TABLE，即使命令看似成功，元数据也可能损坏
真正棘手的不是日志文件本身，而是日志与数据文件之间的时间差——它藏在 innodb_log_buffer_size、innodb_flush_log_at_trx_commit、binlog sync 策略这些参数的组合里。每次调参前，先用真实负载压测恢复耗时，而不是只看文档写的“理论上可恢复”。
