精选推荐

最新动态

SQL EXISTS 与 JOIN 优化实践

因为 EXISTS 是半连接(semi-join),找到第一条匹配就短路返回;而 IN 子查询可能被重写为全量物化,尤其当子查询结果含 NULL 时,行为还可能意外改变。

SQL 行级锁与表级锁性能差异

MySQL 的行级锁不是凭空出现的,它高度依赖索引。没有合适索引时,SELECT … FOR UPDATE 会退化为表级锁——不是因为语法写错了,而是优化器发现走不了索引,干脆锁整张表。

SQL 自动化任务调度与触发器结合

触发器只响应 DML 操作(INSERT、UPDATE、DELETE),它不感知时间,也不能主动执行。想“每天凌晨跑一次统计”,靠 CREATE TRIGGER 完全做不到——这不是功能缺陷,是设计边界。

SQL XA 分布式事务的二阶段提交与单机事务性能代价权衡

因为 XA 强制引入网络往返和全局协调开销,不是“加个开关就能用”的平滑升级。单机事务在内存里完成的 commit,XA 至少要走两次 RPC:一次问所有参与者“准备好了吗”,一次再统一发“提交”或“回滚”。中间还夹着事务管理器(TM)持久化日志、等待超时、协调失败重试等环节。

SQL 索引与表设计优化实践

常见现象是执行 EXPLAIN 看到 type 是 ALL 或 index,而不是预期的 ref/range。根本原因往往不是索引没建,而是查询写法触发了隐式类型转换或函数包裹。

Python 数值溢出风险分析

Python 的 int 类型是任意精度的,加到内存耗尽前都不会“溢出”,但这是假安全感——真正踩坑的是 float。它底层用 IEEE 754 双精度表示,超过 2**53 后就无法精确表示每个整数,后续运算开始丢位。

SQL 主键自增序列 vs UUID 主键的插入性能与索引碎片对比

MySQL 的 AUTO_INCREMENT 主键在单线程或低并发下插入极快,因为新值只是递增一个整数,B+ 树索引页分裂少、定位简单。但高并发插入时,InnoDB 会为 auto_inc_lock 加表级锁(直到 5.6 才优化为轻量互斥锁),多个事务抢同一个“下一个值”,实际变成串行化写入。常见现象是监控看到 innodb_row_lock_waits 上升,或应用日志里大量 Lock wait timeout exceeded。

SQL LIMIT 分页查询技巧与案例

因为 MySQL 实际执行时,会先扫描 offset + count 行数据,再丢弃前 offset 行——哪怕你只要 1 条,它也可能扫了 800 万行。