InnoDB单条INSERT慢因每条都走完整事务流程，建议批量插入、显式事务、调优参数及用LOAD DATA INFILE；MyISAM快但无事务保障；性能瓶颈常在磁盘与配置。
为什么 INSERT 一条一条写进 InnoDB 就像卡住一样
InnoDB 默认每条 INSERT 都走完整事务流程：写 redo log、更新 buffer pool、刷脏页、可能还要等 flush。单条提交相当于反复开合数据库的“门”，IO 和锁开销全堆在一条语句上。
实操建议：
- 用
INSERT INTO ... VALUES (...), (...), (...)批量插入，一次最多 1000 行左右（别硬塞 10 万——会触发长事务、内存溢出或锁升级） - 显式加
BEGIN/COMMIT包裹多条INSERT，避免自动提交（autocommit=1是默认且最慢的） - 确认
innodb_flush_log_at_trx_commit=1（安全）还是=2（快但掉电可能丢一秒日志）——开发/测试可临时设为 2，生产慎改 - 关掉唯一索引和外键检查（
SET unique_checks=0,SET foreign_key_checks=0），导入完再开；注意：这仅适用于可信数据源，否则索引会坏
MyISAM 插入快，但不是因为它“轻量”，而是它不支持事务
MyISAM 的 INSERT 直接追加到数据文件末尾，没 redo、没 MVCC、没行锁——快是真快，但代价是崩溃后数据可能半截、并发写会表锁阻塞、无法回滚。
常见错误现象：
- 并发写入时出现
Lock wait timeout exceeded或长时间等待 —— 实际是 MyISAM 表级锁在排队 - mysqld 意外退出后，
.MYD文件损坏，REPAIR TABLE都救不回来 - 执行
SELECT COUNT(*)突然变慢——MyISAM 虽然缓存了行数，但一旦有DELETE或崩溃，计数就失效，变成全表扫
使用场景仅限于：只读或极少写、数据可丢、无事务需求的报表归档表。别拿它当 InnoDB 的“加速替代品”。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
LOAD DATA INFILE 是批量导入事实上的最快路径
比拼手写 INSERT 或 ORM 批量 save 快 5–20 倍，因为跳过 SQL 解析、权限校验、单行事务开销，直接走 C API 级数据通道。
实操要点：
- 确保文件在 MySQL 服务端（不是你本地机器），路径用绝对路径，如
/var/lib/mysql-files/data.csv - 开启
secure_file_priv限制时，必须把文件放在此目录下，查它用SHOW VARIABLES LIKE 'secure_file_priv' - 字段分隔符、换行符要对齐，否则整批失败；推荐先用
LINES TERMINATED BY '\n'+FIELDS TERMINATED BY ','，避免 CSV 引号嵌套问题 - 导入前停掉唯一索引（
ALTER TABLE t DISABLE KEYS），导入后再ENABLE KEYS——MyISAM 有效，InnoDB 无效（它无视这个指令）
InnoDB 写入性能真正卡点常在磁盘和配置，不在 SQL 写法
即使你写了最优 INSERT，如果 innodb_buffer_pool_size 只有 128MB 而数据集 20GB，那大部分写都在等刷盘；或者用机械硬盘跑 innodb_io_capacity=200，参数再调也没用。
关键参数自查清单：
-
innodb_buffer_pool_size：应占物理内存 50%–75%，小于数据总大小就会频繁刷脏页 -
innodb_log_file_size：太小（如默认 48MB）导致频繁 checkpoint，增大到 1GB 左右可显著减少 IO -
innodb_io_capacity：SSD 设 2000–4000，NVMe 可设 10000+；机械盘别超 200 -
sync_binlog和innodb_flush_log_at_trx_commit要配对看——两个都 =1 最安全最慢，一个 =0 一个 =1 就可能丢数据
最容易被忽略的是：没关 innodb_doublewrite（默认开）。它能防部分页写失败，但会多一次磁盘写。压测时可关（SET GLOBAL innodb_doublewrite=OFF），但生产环境别动。
