innodb表查询变慢主因是配置与机制未适配：未调大innodb_buffer_pool_size（应设为物理内存70%~80%）、未执行analyze table更新统计信息、未捕获lock wait timeout exceeded错误重试、未重建fulltext索引及忽略聚簇索引与行锁差异。
为什么InnoDB表查询变慢不是引擎问题，而是默认行为差异
MyISAM转InnoDB后性能下降，90%不是InnoDB本身慢，而是你没关掉MyISAM的“惯性配置”，也没适配InnoDB的事务和索引机制。InnoDB默认走聚簇索引、行锁、MVCC，而MyISAM是堆表+表锁+无事务——直接切过去，相当于把自行车零件装进跑车底盘里跑。
常见现象包括：简单SELECT * FROM t WHERE id = ?响应从2ms涨到200ms；批量INSERT吞吐暴跌；GROUP BY语句频繁触发Using temporary; Using filesort。
- 主键缺失：MyISAM允许无主键，InnoDB会隐式创建
ROW_ID，导致二级索引体积膨胀、范围扫描失效 - 外键未显式定义：InnoDB默认启用外键检查，但MyISAM压根不支持——如果迁移时漏建外键约束，反而让优化器误判关联路径
- 统计信息未更新：
ANALYZE TABLE t必须手动执行，否则EXPLAIN显示的rows严重失真，优化器可能放弃走索引
innodb_buffer_pool_size设太小，比MyISAM还慢
这是迁移后性能掉一半的头号原因。MyISAM靠key_buffer_size缓存索引，InnoDB靠innodb_buffer_pool_size缓存数据+索引+结构体。如果沿用旧配置（比如死守128M），热数据全在磁盘上随机读，QPS直接腰斩。
查当前值：SHOW VARIABLES LIKE 'innodb_buffer_pool_size'；看命中率：SHOW ENGINE INNODB STATUS\G里找Buffer pool hit rate，低于99.5%就危险。
- 专用DB服务器上，初始值建议设为物理内存的70%~80%，例如64G内存 → 50G左右
- 该参数支持动态调整（MySQL 5.7+），但粒度是128MB整数倍，
SET GLOBAL innodb_buffer_pool_size = 53687091200会被自动对齐到50.06G - 别忘了同步调低
key_buffer_size（MyISAM已不用），否则内存被双份缓存争抢
锁等待超时没捕获，应用层直接报错
MyISAM没有锁等待概念，InnoDB默认innodb_lock_wait_timeout=50秒。一旦高并发更新同一条记录，应用收不到明确提示，只看到Lock wait timeout exceeded错误，重试逻辑没写就直接失败。
- 业务代码必须捕获该错误并实现指数退避重试，不能当普通SQL异常忽略
- 若场景允许短暂数据丢失（如日志类写入），可临时调低该值（如设为10），避免长等待拖垮连接池
- 配合
innodb_rollback_on_timeout=ON（默认开启），确保超时后自动回滚，不卡住事务链
全文索引重建失败或行为不一致
MyISAM的FULLTEXT索引和InnoDB的不是一回事。MySQL 5.6+虽支持InnoDB全文索引，但布尔模式语法受限（比如+(apple banana) -orange嵌套括号不识别），且重建耗时极长，REPAIR TABLE也不起作用。
- 迁移前先
DROP FULLTEXT INDEX，转完再用ALTER TABLE t ADD FULLTEXT(col)重建 - 验证查询：对比
MATCH(col) AGAINST('xxx' IN BOOLEAN MODE)在两种引擎下的返回结果是否一致 - 重建期间表不可写，大表务必安排在维护窗口，且确认
innodb_ft_aux_table权限已开
InnoDB不是“换引擎就完事”的黑盒，它把很多原本由应用承担的事务一致性、锁管理、缓存策略都收归自己控制——这些控制点一旦没对齐，性能反降就是必然结果。最常被跳过的动作是ANALYZE TABLE和innodb_buffer_pool_size重调，这两步不做，其他优化全白搭。
