在云服务器安装MySQL时如何选择存储引擎？

MySQL 8.0 默认且推荐使用 InnoDB 引擎，MyISAM 仅适用于极少数只读+全文检索场景，Memory 引擎非持久化、不可用于主从复制；云环境需调优 innodb_buffer_pool_size 等参数以发挥性能。

MySQL 8.0 默认用的是 InnoDB，别乱切引擎

除非你明确知道要什么，否则直接用默认的 InnoDB。MySQL 5.5 之后就已把 InnoDB 设为默认存储引擎，8.0 更是彻底移除了 MyISAM 的系统表支持（比如 mysql.help_topic 这类内部表现在全用 InnoDB）。强行在建表时指定 ENGINE=MyISAM 虽然语法不报错，但会失去事务、行锁、外键等关键能力，且备份恢复、主从一致性都更难兜住。

常见错误现象：mysqldump 备份后还原出数据不一致；主库执行 INSERT ... SELECT，从库复制中断报错 Table definition has changed；并发写入时出现“幻读”或锁表卡死——这些很多根源就是误用了 MyISAM 或混用引擎。

MyISAM 只适合极少数只读+全文检索场景

如果你真有需求，比如：静态词典表、日志归档表（不再更新）、或需要 FULLTEXT 索引且不关心事务（MySQL 5.6+ 的 InnoDB 其实也支持 FULLTEXT，只是分词逻辑略有差异），才考虑 MyISAM。但注意：

• MyISAM 表级锁，哪怕只是插入一行，整张表都不可写
• 崩溃后无法自动恢复，REPAIR TABLE 命令不一定能救回数据
• mysqldump 备份时加 --single-transaction 对 MyISAM 无效，必须加 --lock-tables，导致备份期间写阻塞
• 云服务器上磁盘 I/O 通常走网络存储（如 AWS EBS、阿里云云盘），MyISAM 的频繁表扫描会放大延迟，不如 InnoDB 的缓冲池友好

想用 Memory 引擎？先看清它根本不是持久化方案

Memory 引擎常被误当作“高性能缓存”，但它只存在内存里，实例重启、OOM、或 MySQL 崩溃，数据全丢。它没有 WAL、不写磁盘、也不参与 binlog 记录——所以不能用于主从复制，也不能用 mysqlbinlog 恢复。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

真正适合它的场景极少：SELECT ... INTO TEMPORARY TABLE 的中间结果集；短生命周期的去重临时表（配合 CREATE TEMPORARY TABLE）；或者某些 OLAP 查询中做快速聚合的“计算暂存”。但一旦涉及任何可靠性要求，比如订单状态缓存、用户会话映射，就绝对不该用 Memory。

云环境特别要注意 InnoDB 的配置调优点

云服务器的内存和磁盘资源弹性高，但默认配置往往偏保守。装完 MySQL 后务必检查这几项：

• innodb_buffer_pool_size：建议设为物理内存的 50%–75%，云主机若内存 ≥4GB，别低于 2GB
• innodb_log_file_size：默认 48MB 太小，写密集场景建议调到 256–1024MB（需停机修改，且修改前清空 ib_logfile*）
• innodb_flush_log_at_trx_commit：云盘延迟波动大，设为 2 可显著提升吞吐（牺牲最多 1 秒数据），设为 1 才是真正的 ACID，按业务容忍度选
• innodb_io_capacity 和 innodb_io_capacity_max：AWS io2、阿里云 ESSD 等高 IOPS 盘，要对应调高（比如设为 1000/2000），否则 I/O 调度压不住

这些参数不改，InnoDB 在云上跑得再快，也只发挥出本地 SSD 的一半性能。而很多人装完就跑应用，等到慢查询报警才回头翻配置，已经晚了。