InnoDB行锁只在走索引时生效，本质是锁索引记录而非物理行；若WHERE条件未命中索引，则退化为全表扫描并逐行加锁，效果等同表锁。
行级锁只在走索引时真正生效
InnoDB 的“行锁”本质是加在索引记录上的锁，不是物理行。如果 WHERE 条件没命中索引（比如 LIKE '%abc'、NOT IN、隐式类型转换），InnoDB 会退化为全表扫描 + 逐行加锁，效果等同于表锁。
常见错误现象：
– EXPLAIN 显示 type=ALL，但开发者误以为走了索引
– WHERE DATE(create_time) = '2026-05-11' 这类函数用法导致索引失效
– 普通字段（如 remark）上没建索引却执行 UPDATE ... WHERE remark LIKE '%test%'
实操建议：
– 主键或唯一索引等值查询（WHERE id = 100）→ 稳定触发单行 Record Lock
– 普通索引范围查询（WHERE status = 1）→ 注意 Next-Key Lock 可能锁住间隙
– 批量更新前先确认执行计划，避免无意识锁全表
MyISAM 表锁在写入时立刻卡死所有并发
MyISAM 对任何 INSERT/UPDATE/DELETE 都直接申请整张表的 WRITE LOCK，期间所有其他写请求排队，读请求也被阻塞（除非启用 concurrent_insert 且仅限尾部追加）。
使用场景中典型瓶颈：
– 两个事务分别更新 id=1 和 id=10000 → 仍互相等待
– 一个慢 SELECT 正在执行 → 所有写操作必须等它结束
– 没有事务回滚能力，写中断后表可能处于中间状态，需人工 REPAIR TABLE
性能影响明显：
– 真实压测显示：当 QPS 写入超 200 且含 UPDATE 时，MyISAM 的 iowait% 常突破 40%，而 InnoDB 稳定在 15% 以内
– MyISAM 的写锁优先级高于读锁，一个新 INSERT 可能插队阻塞多个 SELECT，造成读饥饿
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
InnoDB 并发优势依赖事务与隔离级别配合
行锁不是自动生效的开关，它需要事务开启 + 合理隔离级别 + 正确使用方式才能协同工作。
容易踩的坑：
– autocommit=1（默认）下，每个 SQL 都是独立事务 → redo 日志频繁刷盘，吞吐打折
– 高频更新同一字段（如 status）→ 即使走索引，也可能因热点行争用引发大量 Lock wait timeout exceeded
– innodb_lock_wait_timeout 默认 50 秒，线上建议调低至 5~10 秒，避免无限等待掩盖真实问题
– 批量写入未显式用 BEGIN; COMMIT 包裹，undo 日志暴涨，甚至拖垮整个实例
实操建议：
– 显式控制事务边界，单次事务 ≤ 5000 行
– 避免高频更新无索引字段或高基数二级索引列
– 监控 INFORMATION_SCHEMA.INNODB_METRICS 中的 lock_deadlocks 计数器，死锁频繁说明业务锁顺序混乱
崩溃恢复能力差异决定线上可用性底线
InnoDB 依赖 ib_logfile0（重做日志）和双写缓冲，在异常终止后重启时自动前滚已提交变更、回滚未提交事务；MyISAM 崩溃后 .MYD 或 .MYI 文件极易损坏，REPAIR TABLE 不仅可能失败，还可能静默丢数据。
关键区别：
– InnoDB 崩溃恢复时间基本恒定（秒级），与数据量无关
– MyISAM 的 REPAIR 时间随表大小线性增长，TB 级别可能耗时数小时
– MySQL 5.7+ 默认禁用 MyISAM 的 REPAIR 功能，需显式开启 myisam_recover_options，否则直接报错退出
最常被忽略的一点：innodb_flush_log_at_trx_commit 默认值为 1，批量导入时若不调优，会白白牺牲吞吐；但设为 0 或 2 时又牺牲持久性——这个平衡点必须按业务容忍度手动权衡，不能靠引擎名自动解决。
