行锁更适合电商业务，因其能实现订单、库存等核心表的真正并发更新；而表锁会导致整表阻塞，qps随并发上升断崖下跌，且myisam无事务保障数据一致性。
电商业务写操作天然分散，行锁才能真正并发
电商核心表（如orders、inventory）的更新集中在不同主键或业务单号上：用户A改自己订单状态，用户B同时减库存，用户C退自己的货——这些操作本不该互相阻塞。InnoDB的行级锁在命中索引时，只锁id=123、sku_id='S001'这类具体行；MyISAM不管改哪一行，都得先抢整张orders表的写锁，后面所有写请求排队等，QPS随并发数上升反而断崖下跌。
常见错误现象：UPDATE inventory SET stock = stock - 1 WHERE sku_id = 'S001'执行慢、其他sku_id更新也被卡住，大概率是sku_id没建索引，导致InnoDB退化为全表扫描+锁表，效果和MyISAM一样。
- 验证方式：用
EXPLAIN看type是否为const或ref，key列是否显示用了索引 - 主键、唯一索引最稳；普通索引要避免
WHERE UPPER(name) = 'ABC'这类函数包裹 - MyISAM根本没法“优化”锁粒度——它压根不支持行锁，加索引也无济于事
InnoDB事务保障订单与库存的一致性，MyISAM做不到
下单涉及扣库存+生成订单+创建支付单三个动作，必须原子执行。InnoDB用BEGIN→多条UPDATE/INSERT→COMMIT包成一个事务，中间出错自动回滚；MyISAM没有事务，万一扣了库存但订单写失败，数据就永久不一致，只能靠应用层补单或人工对账。
容易踩的坑：autocommit=1时每条SQL自动提交，看似简单，但跨表操作（如订单+库存）无法保证原子性。电商系统必须显式开事务，并设合理隔离级别（REPEATABLE READ是InnoDB默认，防幻读关键）。
- 死锁不是故障而是信号：
Lock wait timeout exceeded报错频繁，说明多个服务更新同一张表时锁顺序不统一（比如服务A先锁order再锁inventory，服务B反过来） - MyISAM不会死锁，但会卡死：
SHOW PROCESSLIST里能看到一堆Locked状态，超时时间由lock_wait_timeout控制，默认长达一年
高并发下InnoDB的锁开销可控，MyISAM的阻塞不可控
行锁确实比表锁内存占用高（每行锁对象约1KB）、加锁稍慢，但现代服务器几十GB内存足够撑住千万级行锁。真正致命的是MyISAM的阻塞链：一个慢查询（如UPDATE orders SET status=5 WHERE create_time 没走索引）锁表10秒，后面几百个下单请求全在排队，用户体验直接崩坏。
性能影响差异明显：SELECT ... FOR UPDATE在InnoDB中能精准锁住待更新行；MyISAM根本不认这个语法，直接报错ERROR 1031 (HY000): Table storage engine for the table doesn't support lock with SELECT。
- 批量更新别一把梭：
UPDATE inventory SET stock = stock - 1 WHERE sku_id IN (...)带500个ID，不如拆成每次50个的小事务，减少单次锁持有时间 - 间隙锁（Gap Lock）在
REPEATABLE READ下默认启用，会锁住sku_id BETWEEN 'S001' AND 'S010'之间的空隙，防止幻读——但也可能意外阻塞新SKU插入，需结合业务权衡
别只看ENGINE=InnoDB就以为万事大吉
很多电商项目把表引擎改成InnoDB后仍卡顿，问题不在引擎本身，而在SQL是否真触发了行锁。最常被忽略的是：锁行为取决于执行计划，不是表定义。哪怕表是InnoDB，WHERE remark LIKE '%refund%'这种无索引模糊查询，照样全表扫描+锁表。
真实场景中，inventory表加了sku_id索引，但应用代码传参时把sku_id当字符串传入，而字段定义是BIGINT，触发隐式类型转换，索引失效——这时行锁就悄悄退化了。
- 查锁状态用
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX，看TRX_STATE和TRX_ROWS_LOCKED - 死锁日志在
SHOW ENGINE INNODB STATUS\G里，重点看LATEST DETECTED DEADLOCK段 - MyISAM的
concurrent_insert只对尾部INSERT有效，一旦涉及UPDATE/DELETE，表就彻底锁死，别指望它救高并发
