mysql 8.0容器化部署需显式配置字符集、时区、数据挂载及日志表索引策略，启用分区并调优慢查询日志参数，否则易出现乱码、时区错乱、数据丢失与查询卡顿。
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 状态。 
