千万级日志表禁用myisam，应绕开count(*)：用元数据表维护精确计数、redis实现近似实时统计、索引优化覆盖扫描，或改用游标分页规避总数计算。
千万级日志表不能用 MyISAM，替代方案不是“换引擎”，而是绕开 COUNT(*) 本身。
为什么不能切到 MyISAM
MyISAM 的 COUNT(*) 快，是因为它把总行数固化在磁盘元数据里——但这建立在不支持事务、无 MVCC、全表锁的基础上。日志类表通常要满足：INSERT 高频写入、可能需按时间范围 DELETE 或 UPDATE 状态、要求崩溃后数据不丢。MyISAM 在这些点上全部不达标，线上已基本淘汰。
强行切换会导致：
- 写入并发下降（表锁阻塞）
- 事务中混用 InnoDB/MyISAM 引发隐式提交，破坏一致性
- 主从复制因引擎差异出现不一致风险
用元数据表做精确计数（适合强一致场景）
核心思路：把“统计结果”当成业务状态来维护，而不是每次查时再算。
建表语句示例：
CREATE TABLE log_count ( name VARCHAR(64) PRIMARY KEY, cnt BIGINT NOT NULL DEFAULT 0, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );
关键操作要点：
- 所有写入日志的入口（
INSERT INTO log_table）必须配套执行：INSERT INTO log_count VALUES ('log_total', 1) ON DUPLICATE KEY UPDATE cnt = cnt + 1 - 批量导入时，先算出增量 Δ，再单条
UPDATE log_count SET cnt = cnt + ? WHERE name = 'log_total'，别循环 N 次 - 软删除（如
status = 'deleted'）需同步DECRBY 1；硬删除则应在DELETE后触发更新 - 避免直接
UPDATE ... SET cnt = cnt + 1，高并发下易引发行锁争用；ON DUPLICATE KEY UPDATE利用唯一索引冲突机制，锁粒度更细
用 Redis 做近似实时计数（适合读多写少、容忍秒级误差）
适用典型日志场景：「今日新增日志量」「最近一小时错误日志数」。
必须守住的底线：
- 增减操作必须和 MySQL 写操作顺序执行、失败可补偿：先成功
INSERT日志，再INCRBY log:today 1；若 Redis 调用失败，记录日志并由后台任务重试 - 绝对不用
GET + SET模拟原子操作，会丢数据；必须用INCRBY/DECRBY - 每天凌晨用
SELECT COUNT(*) FROM log_table WHERE DATE(create_time) = CURDATE()全量校准一次，写入SET log:today:backup {value}作为兜底 - 如果业务有按时间分区（如
log_202609），Redis key 要带分区标识，避免跨月统计错乱
WHERE 条件无法绕开？那就靠索引+覆盖扫描
如果必须统计带条件的日志数（例如 COUNT(*) FROM log_table WHERE level = 'ERROR' AND create_time > '2026-09-28'），上述两种方案都失效，只能回归数据库本身优化：
- 确保
level和create_time上有联合索引，且顺序符合查询条件（如INDEX(level, create_time)） - 避免在
WHERE中对字段做函数操作（如DATE(create_time)），否则索引失效 - 如果该条件查询频率极高，且误差可接受，可用
SHOW TABLE STATUS LIKE 'log_table'查Rows字段——但注意这是采样估算值，官方说明误差可达 40%~50% - 对超大范围条件（如统计近 7 天），考虑提前物化汇总表：
CREATE TABLE log_daily_summary (day DATE PRIMARY KEY, error_cnt INT, warn_cnt INT)，每日定时聚合
最常被忽略的一点：日志表的 count 往往不是独立需求，而是分页接口的一部分。与其死磕总数，不如改用游标分页或限制最大可查页数（如只允许查前 1000 页），从根本上规避 COUNT(*) 调用。
