技术博客
因为 MySQL 客户端默认走 Unix socket 连接（而非 TCP），而 mysql.sock 就是这个通信的“门口钥匙”。它不在预期路径，mysql -u root 就会报错：Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ —— 注意错误里那个路径，就是关键线索。
直接说结论：用 mysqldump 做逻辑备份，适合中小规模数据库（单库 ≤ 50GB）、需要跨版本/跨平台迁移、或要审计 SQL 内容的场景；但它不是万能方案，大库会锁表、慢、且无法做到秒级恢复。
直接用外键约束，别图省事手写字符串存分类名。MySQL 8.0+ 默认启用严格模式，NO_ZERO_DATE 和 STRICT_TRANS_TABLES 开着时，如果分类字段设成 VARCHAR 又没加约束，后期关联查询容易返回空或隐式转换错误。
MySQL 的 LIKE 不是“模糊匹配”字面意思的智能搜索，而是基于**单字符通配符 _ 和多字符通配符 %** 的字符串模式匹配。它不支持正则语法（除非用 REGEXP），也不做分词或相似度计算。
这是最典型的“复制断裂”场景：主库清理了过期 binlog，但从库还卡在某个已删除的文件位置上，SQL 线程直接停止。此时 SHOW SLAVE STATUSG 中 Last_IO_Error 会明确提示找不到日志文件。
MySQL升级失败，八成不是“装错了”，而是新旧版本在字符集、权限表、配置项或启动流程上悄悄对不上号——直接重装或反复启停只会让问题更难定位。
MySQL 的 EXPLAIN 不是告诉你“查到了什么”，而是告诉你“打算怎么查”。关键字段包括 id、type、key、rows、Extra。其中 type 值从好到差通常是：system ≈ const > eq_ref > ref > range > index > ALL；出现 ALL 意味着全表扫描，要优先排查。
MySQL 主从复制的前提是主库必须开启二进制日志（binlog），否则从库根本没东西可拉。默认很多安装包（比如某些 Docker 镜像或一键脚本）会关掉 binlog，或者压根没配 server-id —— 这会导致从库启动时报错 ERROR 1236 (HY000): Could not find first log file name in binary log index file 或直接拒绝连接。
不支持直接集成。MySQL 官方版本（包括 8.0 和 8.1）**不内置 LDAP 客户端逻辑**，也没有 auth_ldap_simple 或类似插件。所谓“LDAP 认证”，实际依赖操作系统层的 PAM（Pluggable Authentication Modules）中转——MySQL 通过 authentication_pam 插件调用系统 PAM 配置，再由 PAM 模块（如 pam_ldap.so 或 pam_sss.so）连接 LDAP 服务器。
MySQL 对 VARCHAR、TEXT 等长字符串字段建索引时，不能直接对整列加索引（尤其在 innodb_large_prefix=OFF 的老版本中）。否则会报错：Specified key was too long; max key length is 767 bytes。