myisam并发插入仅在concurrent_insert=2且尾部追加时有效，需重启生效；insert delayed已废弃，应改用批量插入；表级锁使select会阻塞写入，日志表须剥离读操作并精简字段与索引。
MyISAM 的并发插入能力依赖 concurrent_insert 配置，但必须配合表结构、写入模式和引擎限制一起用，否则无效甚至拖慢性能。
concurrent_insert=2 是唯一推荐值，但仅对尾部追加有效
MyISAM 默认只在数据文件末尾追加新行时才支持并发插入，concurrent_insert=2 强制开启该行为，即使表中有删除空洞也允许并发写入。但注意：concurrent_insert=0 或 1 在日志类场景下基本无用——日志表极少删除，也不需要从中间空洞复用空间。
- 必须在
my.cnf中显式设置：concurrent_insert = 2 - 修改后需重启 MySQL（
/etc/init.d/mysqld restart），动态 SET 不生效 - 该配置仅影响 INSERT，不影响 REPLACE、DELETE 或 UPDATE；一旦执行了这些操作，MyISAM 可能重建数据文件，导致后续并发插入暂时失效
INSERT DELAYED 已彻底不可用，别再试
MySQL 5.6 起已完全移除 INSERT DELAYED 语法，任何尝试都会触发 ERROR 1064 (42000)。它过去只适用于 MyISAM，且延迟不可控、数据丢失风险高，现在连语法解析都失败。不要查旧文档，也不要试图降级 MySQL 来兼容。
- 替代方案只有批量插入：
INSERT INTO log_table VALUES (...), (...), (...) - 每批控制在 100–500 行，避免单语句超
max_allowed_packet - 若应用层无法合并，考虑用消息队列（如 Kafka）先缓冲，再由消费者批量刷入
MyISAM 日志表的真正瓶颈不在并发配置，而在锁粒度
即使 concurrent_insert=2 开启，MyISAM 仍是表级锁：任意一个 SELECT 查询都会阻塞所有写入，哪怕只是 SELECT COUNT(*)。日志表若混杂查询，吞吐会断崖下跌。
- 如果业务中存在定时统计、监控拉取等读操作，必须剥离——改用单独汇总表或外部存储（如 Elasticsearch）
- 字段类型务必最小化：
TINYINT代替INT，VARCHAR(32)代替TEXT，减少 I/O 和内存占用 - 禁用所有非必要索引；日志表通常按时间范围查询，可只建一个
created_at时间索引，且设为UNIQUE会额外加重写入开销
真正决定 MyISAM 日志表写入上限的，不是 concurrent_insert 值，而是「有没有 SELECT 干扰」和「单次写入的数据包大小」。这两个点比调参更容易被忽略，也更直接影响结果。
