技术博客
直接看 EXPLAIN 输出里有没有明显瓶颈项：如果 type 是 ALL（全表扫描）、key 是 NULL（没走索引）、rows 数量远超实际匹配行数，基本说明没优化好。重点盯 Extra 字段——出现 Using filesort 或 Using temporary 就得警惕，尤其是二者同时出现时，大概率是排序+分组逻辑触发了磁盘临时表。
MySQL 8.0 已彻底移除查询缓存（query_cache_type、query_cache_size 等所有相关参数），启用会报错或静默忽略；连接层也没有“连接缓存”这个内置机制——所谓“连接缓存”通常指应用层复用连接（如连接池），或内核级的 TCP 连接复用（keepalive），而非 MySQL Server 自身配置项。
备份与恢复冲突在 MySQL 运维中常见，本质是数据状态不一致或操作时序错乱导致的。核心在于避免“用旧备份覆盖新数据”或“在恢复过程中写入新数据”，同时确保 binlog、GTID、时间点等关键元信息同步准确。
MySQL 的 UPDATE 如果 WHERE 条件列没有索引，会触发全表扫描，尤其在大表上，不仅慢，还会锁住大量行（甚至整表），阻塞其他写操作。常见现象是 SHOW PROCESSLIST 里看到状态为 Updating 且 Time 持续增长。
MySQL 在执行 UPDATE 或 DELETE 时，如果多张表里存着同一份数据（比如用户姓名在 orders 表和 customers 表里都重复保存），就必须同步更新/删除多处——这不仅增加 SQL 编写负担，更关键的是：每次操作都可能触发更多行锁、更多索引维护、更多磁盘 I/O。实际压测中，冗余字段每多一个，单条 UPDATE 的平均耗时可能上升 30%～200%，尤其在高并发写入场景下，容易卡住事务链。
MySQL 临时表（CREATE TEMPORARY TABLE）只对当前会话可见，连接断开后自动释放，这点常被误认为“完全无害”。实际并非如此：临时表仍占用内存或磁盘空间，且在高并发下可能触发 tmp_table_size 或 max_heap_table_size 限制，导致隐式落盘到磁盘临时表（MyISAM 或 InnoDB），显著拖慢查询。
不加审核状态字段，后续无法区分待审、已通过、已拒绝的评论。直接在评论表里加 status，类型用 TINYINT(1) 或 ENUM(‘pending’,’approved’,’rejected’) 都可以，但推荐前者——整数比字符串索引效率高，且方便后期扩展（比如加“待人工复核”状态）。status 默认值设为 0（对应 pending），避免插入时漏填导致脏数据。
PostgreSQL 默认不带 pgstattuple，调用 pgstattuple() 或 pgstatindex() 会提示 function does not exist。必须先在目标数据库中启用扩展。
直接用 mysqldump 导出 SQL 文件是 MySQL 最主流的逻辑备份方式，适合中小规模、对一致性要求不高的场景。它本质是执行 SELECT 把数据转成 INSERT 语句，所以备份过程会加读锁（除非用 –single-transaction）。
MySQL 的 IF 是函数，不是控制语句，它必须返回一个值，所以只能出现在能接受表达式的地方。比如你写 WHERE IF(condition, a, b) = 1 是合法的，但 IF(condition, SELECT …, SELECT …) 这种分支执行逻辑会报错——MySQL 不支持过程式 IF 块（除非在存储过程里）。