CREATE TABLE 时指定 ENGINE=InnoDB 还是 MyISAM 直接决定后续操作行为
MySQL 表的创建不是“写完语句就完事”，
ENGINE参数会锁死表的底层能力边界。比如用
ENGINE=MyISAM创建的表，不支持事务、行级锁、外键约束，但全文索引在旧版本中更易用；而
ENGINE=InnoDB默认启用事务和 MVCC，但建表时若未显式指定
ROW_FORMAT和
KEY_BLOCK_SIZE，可能在高并发写入时因页分裂引发性能抖动。
实操建议：
新项目一律用ENGINE=InnoDB，除非有明确遗留兼容需求（如某些只读报表系统依赖 MyISAM 的
INSERT DELAYED） 避免在
CREATE TABLE中省略
ENGINE，因为 MySQL 8.0+ 默认引擎虽是 InnoDB，但实例级配置
default_storage_engine可被覆盖，线上环境必须显式声明 如果表需要压缩存储，InnoDB 支持
ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8，但 MyISAM 不支持任何行格式控制
DROP TABLE 执行快慢和磁盘空间释放取决于存储引擎实现
DROP TABLE看似简单，实际行为差异极大：InnoDB 表删除会先标记数据字典、再异步清理 ibd 文件，而 MyISAM 是直接 unlink .MYD/.MYI 文件。这意味着在大表场景下，InnoDB 的
DROP TABLE可能“返回很快但磁盘没立刻释放”，尤其当
innodb_file_per_table=OFF时，删表只是回收系统表空间中的页，不会缩小
ibdata1文件。
实操建议：
确认是否启用了innodb_file_per_table=ON（5.6+ 默认开启），否则删表后空间无法归还给操作系统 不要依赖
DROP TABLE快速腾出磁盘空间——InnoDB 更稳妥的做法是
TRUNCATE TABLE+
OPTIMIZE TABLE组合，或分批
DELETE+
ALTER TABLE ... ENGINE=InnoDB触发重建 MyISAM 表删完即释放，但要注意其表锁机制会导致
DROP阻塞所有对该表的访问，高并发下容易卡住其他查询
ALTER TABLE 修改结构时，不同引擎对锁和复制的影响完全不同
InnoDB 在 5.6+ 支持多数 DDL 的 online 操作（如加索引、改列名），但前提是不触发
ALGORITHM=COPY；而 MyISAM 所有
ALTER TABLE都是全表拷贝+锁表，哪怕只是加个注释也会锁死整个表数分钟。
实操建议：
执行前用SHOW CREATE TABLE查看当前
ENGINE和
ROW_FORMAT，再判断是否支持 online DDL InnoDB 下慎用
MODIFY COLUMN改类型（如
VARCHAR(255)→
VARCHAR(500)），虽然不重写数据，但若涉及字符集变更或长度超过 768 字节，仍可能触发重建 主从复制环境下，MyISAM 表的 DDL 语句以语句形式写入 binlog，一旦从库执行失败（如磁盘满），就会中断复制；InnoDB 则更稳定，但需确保
binlog_format=ROW避免函数/临时表导致的不一致
information_schema.TABLES 中 ENGINE 字段不可信？查真实引擎得看 data dictionary
MySQL 8.0+ 使用数据字典统一管理元数据，
information_schema.TABLES中的
ENGINE值可能滞后于实际状态，尤其在崩溃恢复后或手动修改过 ibd 文件时。更可靠的方式是查
mysql.innodb_table_stats（仅 InnoDB）或直接用
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='db' AND TABLE_NAME='t'并配合
SHOW TABLE STATUS交叉验证。
实操建议：
自动化运维脚本中，不要单靠information_schema.TABLES.ENGINE做判断，应加上
SHOW TABLE STATUS LIKE 't'\G输出中的
Engine:行做比对 如果发现
SHOW CREATE TABLE显示
ENGINE=InnoDB，但
SELECT COUNT(*)报错 “Table doesn’t exist”，很可能是 ibd 文件丢失但 frm（或数据字典）残留，此时不能直接
DROP，需先
DISCARD TABLESPACE再重建 跨版本迁移表时（如 5.7 → 8.0），即使建表语句带
ENGINE=MyISAM，也可能被自动转为 InnoDB（取决于
skip_create_options和兼容模式），务必检查迁移后实际引擎 真正影响表生命周期管理的，从来不是语法本身，而是你是否清楚每个
ENGINE在磁盘上怎么存、在内存里怎么锁、在复制链路中怎么传。很多“删不掉的表”“改不动的字段”，问题不在 SQL 写错，而在建表那一刻选错了引擎。
