只要innodb_flush_log_at_trx_commit=1（默认值）且磁盘写缓存未被禁用，事务提交后断电数据仍在，因redo log已强制落盘，崩溃重启后自动重放恢复；设为0或2或底层存储关闭write-through模式则可能丢数据。
因为线上业务不能容忍事务中断、并发阻塞或断电丢数据——InnoDB 是唯一能同时扛住这三件事的引擎。
事务提交后断电，数据还在吗？
只要 innodb_flush_log_at_trx_commit=1（默认值），且磁盘写缓存未被禁用，已 COMMIT 的事务就一定落盘。InnoDB 依赖 redo log 持久化，崩溃重启后自动重放日志恢复。但若误设为 0 或 2，或底层存储（如某些云盘）关闭了 write-through 模式，COMMIT 后秒断电仍可能丢事务。
- 检查命令：
SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit'; - 云数据库要确认厂商是否强制覆盖该参数（部分托管实例为性能默认改
2） - 不要盲目调高
innodb_log_file_size：过大导致 recovery 时间变长，反而影响 RTO
UPDATE WHERE name='xxx' 却锁全表？
这不是 InnoDB 不行，是你没让索引生效。行锁只在通过索引查找时触发；WHERE 条件走不了索引，就升级为表锁。
- 用
EXPLAIN看type字段：要是ALL，说明全表扫描，必然表锁 -
name字段类型是VARCHAR，但查询写成WHERE name=123（隐式转换），索引失效 - 联合索引
(a,b)，只查WHERE b='x'也用不上，照样全表扫 - 主键或唯一索引最稳；普通查询字段务必单独建索引，别指望“以后再加”
count(*) 为什么比 MyISAM 慢？
不是慢，是语义不同。InnoDB 的 COUNT(*) 返回的是当前事务隔离级别下“可见的行数”，必须遍历聚簇索引计算；MyISAM 存的是元数据快照，不保证一致性。
- 高频总数需求别硬查
COUNT(*)：用计数表 +INSERT ON DUPLICATE KEY UPDATE维护 - 分页场景避免
LIMIT 10000,20：偏移量大时等效于扫 10020 行，改用游标（WHERE id > last_id LIMIT 20） -
INFORMATION_SCHEMA.TABLES中的TABLE_ROWS是估算值，MySQL 8.0+ 仍不可信，别用于校验逻辑
崩溃后自动恢复失败，常见原因
自动恢复不是魔法，它依赖 redo log 完整 + doublewrite 未被关闭 + ibdata1 未损坏。手动删 ib_logfile* 或强行 kill -9 mysqld，极易破坏 recovery 链路。
- 检查关键开关：
SHOW VARIABLES LIKE 'innodb_doublewrite';（云托管实例常默认关） - 别碰
innodb_fast_shutdown：设为0会强制 purge，停机慢；设为2（默认1）可能残留脏页 - 报错
InnoDB: Database page corruption通常意味着 doublewrite buffer 损坏或磁盘静默错误，不是重启能解决的
真正决定 InnoDB 是否可靠，从来不是“它支不支持事务”，而是你有没有盯住 redo log 刷盘策略、索引设计是否匹配查询路径、以及 doublewrite 这类机制在真实负载下是否持续有效——这些细节，比选引擎本身更值得花时间验证。
