MySQL 8.0 容器化部署避坑指南
直接用
docker run拉官方镜像跑 MySQL 8.0，大概率遇到日志系统连不上、字符集报错或时区混乱——根本原因是默认配置没适配日志分析场景。必须显式覆盖关键参数。
MYSQL_ROOT_PASSWORD必须设，否则容器启动后无法初始化 加
-e MYSQL_COLLATION_SERVER=utf8mb4_unicode_ci -e MYSQL_CHARACTER_SET_SERVER=utf8mb4，否则中文日志入库乱码或
LIKE查询失效 挂载
/etc/localtime并加
-e TZ=Asia/Shanghai，避免日志时间戳与采集端不一致 数据目录务必用
-v /host/mysql-data:/var/lib/mysql绑定宿主机路径，否则容器重启后日志表全丢
日志表建表时必须加的 3 个索引策略
日志数据写多读少，但查询常按时间范围 + 状态码 + 模块名组合过滤。裸建表查一个月的
access_log，哪怕只有千万级，
SELECT也会卡住。 主键别用
AUTO_INCREMENT，改用
(log_time, id)联合主键，让物理存储按时间局部性排列 强制加
INDEX idx_time_status (log_time, status_code)，覆盖最常见的时间+状态筛选 对高频检索字段如
service_name或
request_path，用前缀索引：
INDEX idx_path (request_path(128))，避免长文本索引膨胀
慢查询日志开启后反而查不动？检查这 2 个配置项
开
slow_query_log = ON本意是定位慢 SQL，但若没调优配套参数，日志表自身会成性能瓶颈，甚至拖垮整个 MySQL 实例。
long_query_time = 0.5（别设 0！）—— 设为 0 会导致所有语句写入慢日志表，IO 直接打满
log_output = TABLE时，必须把
mysql.slow_log表引擎改成
CSV或定期归档：
ALTER TABLE mysql.slow_log ENGINE = CSV，否则 InnoDB 的 MVCC 开销会让查询更慢
日志类查询优化：别依赖 EXPLAIN
，先看 Handler_read_*
日志分析查询常走全表扫描，
EXPLAIN显示
type: ALL是常态。真正要盯的是存储引擎层的读取行为，它暴露了索引是否真被用上。 执行查询后立刻查：
SHOW STATUS LIKE 'Handler_read%';如果
Handler_read_next远大于
Handler_read_key，说明索引没生效，可能因隐式类型转换（比如
status_code字段是
VARCHAR却用数字查） 如果
Handler_read_rnd_next高，代表排序用了临时文件，需加
ORDER BY log_time DESC LIMIT 100类查询的复合索引 实际部署中，最容易被跳过的其实是日志表的分区策略——按天或按周对
log_time分区，能直接砍掉 90% 以上冷数据扫描，但 MySQL 8.0 默认不启用分区插件，得手动确认
have_partitioning状态。
