sql

精选推荐

最新动态

SQL maintenance_work_mem 的 VACUUM / CREATE INDEX 的临时内存预算调优

2026年2月17日

这两个操作不走查询计划缓存，也不受 work_mem 控制，它们靠的是独立的内存预算——maintenance_work_mem。默认值通常只有 64MB，对千万级表建索引或清理膨胀的表，根本不够用，直接退化成多轮磁盘排序+归并，I/O 拉满、时间翻倍。

SQL SQL 注入防护策略与实践

2026年2月17日

只要用户输入进了 query 字符串拼接，就大概率能被绕过。比如用单引号闭合、注释掉后面校验逻辑、或用 UNION SELECT 拖库——这些不是“高级技巧”，而是 SQL 解析器的正常行为。

SQL JSON 与关系表混合查询案例

2026年2月17日

直接查 jsonb 字段里的值却没走索引，是混合查询最常卡住的地方。PostgreSQL 不会自动为 jsonb 内部字段建索引，哪怕你写了 WHERE data->>’status’ = ‘active’。

SQL Vitess VTGate 的 query timeout 与 scatter query 限流实践

2026年2月17日

它只管单条 query 从 VTGate 发出到收到完整响应的总耗时，不区分是单分片还是 scatter query。一旦超时，VTGate 直接返回 deadline exceeded 错误，底层 vttablet 还在跑的查询不会被自动 cancel——除非你开了 enable_cancel_on_timeout（默认关）。

SQL 审计日志设计与权限追踪

2026年2月17日

只记 user_id 和 sql_text 不足以还原“谁在什么时间、用什么身份、改了哪个对象的什么权限”。权限类操作（如 GRANT、REVOKE、CREATE ROLE）必须捕获执行上下文。

SQL 乐观锁与悲观锁高级实现

2026年2月17日

乐观锁本质是“先查后验”，靠版本号或时间戳判断数据是否被改过。关键不在加锁，而在提交时校验——UPDATE 语句里必须把版本条件写进 WHERE 子句，否则等于没锁。

SQL OLAP 与 OLTP 查询策略分析

2026年2月17日

真正卡住的地方，往往不是语法写错了，而是 OLAP 的“排序键”和 OLTP 的“查询谓词”没对齐；同一张表，在两个场景下可能需要完全不同的索引策略或物化方式。

SQL 数据安全与权限管理

2026年2月17日

权限改了但用户还是连不上或报 Access denied，大概率是权限没刷进内存，或者 GRANT 时写错了主机名或数据库名。

SQL NoSQL 与 SQL 混合查询技巧

2026年2月17日

不能。SQL 的 JOIN 是关系代数操作，依赖严格 schema 和事务一致性；NoSQL（如 MongoDB、Redis、Elasticsearch）没有统一的 JOIN 语义，也不保证跨集合/索引的 ACID。强行“混合查询”必须由应用层协调，不是数据库层能力。

SQL GTID 模式下 binlog_gtid_simple_recovery 的恢复加速实践

2026年2月17日

MySQL 在实例重启时，需要重新扫描 binlog 文件来确定 gtid_executed 的最终值。默认行为（binlog_gtid_simple_recovery=OFF）会从第一个 binlog 扫到最新一个，耗时随 binlog 文件数量线性增长——几十个文件就可能卡住几秒甚至更久。