技术博客
MySQL 在执行 UPDATE 或 DELETE 时，如果多张表里存着同一份数据（比如用户姓名在 orders 表和 customers 表里都重复保存），就必须同步更新/删除多处——这不仅增加 SQL 编写负担，更关键的是：每次操作都可能触发更多行锁、更多索引维护、更多磁盘 I/O。实际压测中，冗余字段每多一个，单条 UPDATE 的平均耗时可能上升 30%～200%，尤其在高并发写入场景下，容易卡住事务链。
报错看起来一样，但背后触发机制不同：两者都因违反唯一性而抛出类似错误，比如 SQL Server 的 Msg 2627、MySQL 的 ERROR 1062、PostgreSQL 的 duplicate key violates unique constraint。但关键区别在于——约束是逻辑校验层，索引是物理结构层；错误虽同源，可禁用/绕过方式完全不同。
本文介绍一种通用sql技巧：在获取排序后前n条记录的同时，自动包含所有与第n名分数相同的并列记录，避免因简单 limit 导致同分者被截断。
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。必须先在目标数据库中启用扩展。
别急着启动或停止，先看它到底在不在跑。登录从库执行 SHOW SLAVE STATUSG，重点盯住两行：
直接用 mysqldump 导出 SQL 文件是 MySQL 最主流的逻辑备份方式，适合中小规模、对一致性要求不高的场景。它本质是执行 SELECT 把数据转成 INSERT 语句，所以备份过程会加读锁（除非用 –single-transaction）。
MySQL 的 IF 是函数，不是控制语句，它必须返回一个值，所以只能出现在能接受表达式的地方。比如你写 WHERE IF(condition, a, b) = 1 是合法的，但 IF(condition, SELECT …, SELECT …) 这种分支执行逻辑会报错——MySQL 不支持过程式 IF 块（除非在存储过程里）。
这个参数控制每次 INNODB_BUFFER_POOL_DUMP_NOW 或自动 dump 时，只保存缓冲池中最热的前 N% 页面。设得太低（比如 25），可能漏掉刚升温但还没进前 25% 的关键热页；设得太高（比如 100），dump 文件体积暴涨，重启加载慢，还可能把临时热点（如某次大查询扫出的冷表页）也固化进去。