技术博客
直接看 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 在执行 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），避免插入时漏填导致脏数据。
Go 闭包捕获的是外围作用域中变量的内存地址，不是值副本。这意味着多个闭包共享同一变量实例，修改其中一个闭包内通过该变量名所做的变更，会反映在其他闭包里。
本文详解如何在 keycloak 集成系统中，于用户会话因空闲超时（如20分钟）自动失效后，主动调用 admin api 注销其服务端会话，避免残留登录状态，确保安全合规。
这个参数控制每次 INNODB_BUFFER_POOL_DUMP_NOW 或自动 dump 时，只保存缓冲池中最热的前 N% 页面。设得太低（比如 25），可能漏掉刚升温但还没进前 25% 的关键热页；设得太高（比如 100），dump 文件体积暴涨，重启加载慢，还可能把临时热点（如某次大查询扫出的冷表页）也固化进去。
很多人以为把 content 字段更新成旧值就完成了回滚，结果发现图片链接失效、元数据错乱、搜索索引没同步。Golang Wiki 系统里，一次编辑可能同时影响 pages 表、revisions 表、page_attachments 关联表，甚至外部对象存储里的文件引用。回滚不是“还原内容”，而是“还原整个页面状态”。
只要 EXPLAIN 结果中出现 Using filesort，就说明 MySQL 没法用索引直接完成排序，得把数据捞出来再内存或磁盘排序——这是性能瓶颈的明确信号。