技术博客
别急着改配置，先连上 MySQL 看一眼现状：
mysql -u root -p → 输入密码后执行：
SHOW VARIABLES LIKE ‘general_log%’;
SHOW VARIABLES LIKE ‘slow_query_log%’;
SHOW VARIABLES LIKE ‘log_error’;
SHOW VARIABLES LIKE ‘log_bin’;
这些命令能分别告诉你通用日志、慢查询日志、错误日志、binlog 是否启用，以及它们的路径。如果值是 OFF 或空，说明没开；ON 且路径存在，才算真正生效。
不能直接混搭做主从，尤其是 5.7 作为主库、8.0 作为从库时，大概率会报错 ER_SLAVE_INCIDENT 或复制中断在 GTID_PURGED 初始化阶段。根本原因是 8.0 默认启用 enforce_gtid_consistency=ON 且要求所有事务带 GTID，而 5.7 的部分语句（如非事务性 DML、CREATE TEMPORARY TABLE）在未显式开启 gtid_mode=ON 时无法生成合法 GTID，导致从库拒绝执行。
mysqldumpslow、pt-query-digest、mysqlsla 是当前最实用的三款 MySQL 慢日志分析工具，其中 pt-query-digest 在生产环境里事实成为首选——它解析准、聚合稳、支持多日志源（slow log / tcpdump / processlist），且输出结构清晰，可直接用于性能归因。
WHERE 条件写错位置，查不到数据是常态，不是你手误——而是逻辑没理清。很多人写 LEFT JOIN 时，把本该过滤右表的条件（比如 status_riwayat = ‘keluar’）硬塞进 ON 子句，结果发现只返回一条记录，或者 masuk 数据直接消失。这不是 bug，是 SQL 执行顺序决定的：ON 先匹配，WHERE 后过滤。
避免全表扫描是MySQL查询优化的关键一步，核心在于让查询能有效利用索引，减少不必要的数据读取。
MySQL 的 mysqldump –all-databases 不会导出 mysql.user 表的权限数据（尤其在 8.0+ 默认启用 caching_sha2_password 认证插件后，直接拷贝表可能失效），也不能还原 GRANT 语句中的动态主机名或角色依赖。真正可靠的方式是用 mysqlpump 或手动从 information_schema 和 mysql 系统库生成可执行的 GRANT 语句。
直接说结论：**不安全，且极易误授权限**。MySQL在解析数据库名时，会把未转义的_当作“单字符通配符”，和LIKE语句里的行为一致——这不是bug，是设计如此，但绝大多数人不知道。
这个值决定 InnoDB 能缓存多少数据和索引，设得太小会导致频繁磁盘读，太大则可能挤占系统内存引发 swap。关键不是看“推荐 70%~80%”，而是看实际工作集大小。
开发环境不是沙盒，但必须当作沙盒用。很多团队误以为“本地连的是测试库就随便操作”，结果 mysql -u dev -p -h test-db 登进去随手 DROP TABLE user_log_2023，第二天发现日志归档脚本崩了——因为表结构被删了，而下游服务没做兜底。
MySQL 不接受双引号作为字符串字面量的定界符（除非 SQL_MODE 启用了 ANSI_QUOTES），否则会报错 ERROR 1054 (42S22): Unknown column ‘xxx’ in ‘field list’。这是因为 MySQL 默认把双引号当成标识符（如列名、表名）处理，而非字符串。