迁库最磨人的不是搬数据，是方言怎么转换

迁库最磨人的不是搬数据，是方言怎么转换信创、降本、换 PG，数据库迁移已经不稀奇了。数据搬过去往往有现成工具；真正耗人的是 SQL / DDL 文本层——类型、自增、函数名、标识符引号，每种库写法都不一样。几百张表靠手改，改完还不敢保证目标库能跑：验证成本常常比改写还高。jkit-sql 做的是把这

对外接口自动裁掉 敏感字段：聊聊列级权限与脱敏

对外接口自动裁掉敏感字段：聊聊列级权限与脱敏数据合规（个保法、GDPR）时代，"谁能看哪些列"是硬需求。但脱敏代码往往散落在每个接口里：if (role == ADMIN) ... else mask(...)。这一篇讲怎么用 AST 改写，在不改业务 SQL、不污染原句的前提下

1200 条复杂 SQL，4 大数据库通吃：一套能直接跑的业务分析语料库

1200 条复杂 SQL，4 大数据库通吃：一套能直接跑的业务分析语料库电商 / 金融 / 人力，50 张真实表 + 约 8 万行数据，导入即跑，拿走不谢。做数据分析、写 SQL 的同学，多少都经历过这个瞬间——收藏夹里躺着一堆「SQL 面试题」「窗口函数大全」「100 个必会查询」，真到了业务里要

14 个业务场景，一个 SQL 解析器全干完

14 个业务场景，一个 SQL 解析器全干完标题里写「网关」，是因为审计、路由、Wall、租户改写最常落在这一层；但同一套能力也覆盖迁移、分页、实体建表、格式化、遗留模板——凡是要读懂、改写、校验 SQL 文本的地方都用得上。真正卡住的往往不是「能不能执行 SQL」，而是「能不能处理别人给过来的 S

SQL 不是字符串：一个零依赖解析器能替你干的六件事

SQL 不是字符串：一个零依赖解析器能替你干的六件事SQL 不是字符串：一个零依赖解析器能替你干的六件事一、五分钟写出来的代码需求很朴素：发布前扫一遍订单模块的所有 SQL，列出它们碰了哪些表，评估改动影响面。第一版实现长这样：Pattern p = Pattern.compile("(?

正则抠 SQL 翻车之后：聊聊解析器这件事

正则抠 SQL 翻车之后：聊聊解析器这件事做过 SQL 审计或上线影响面评估的，大概都试过一招：正则抠 FROM / JOIN。Pattern p = Pattern.compile("(?i)(?:from|join)\\s+([a-zA-Z0-9_`.]+)");Matche

内容数据库调优100例：从报警到修复

这篇文章，不讲玄学、不讲空话。 100 个真实可复用的数据库调优案例，带你从 报警 → 定位 → 修复 → 复盘，建立一套真正能救命的数据库调优方法论。文章结构为了方便查阅,我把100个案例分成了10大类:第一章:索引优化(案例1-15)最常见也最容易被忽视的问题,80%的慢查询都能通过优化索引解决

JSqlParser 深度解析：Java SQL 解析的利器与最佳实践

JSqlParser：SQL 解析利器的使用与最佳实践在日常开发中，我们或多或少都遇到过这样的场景：动态审计：需要记录所有 UPDATE 或 DELETE 操作影响了哪些表、哪些字段。数据脱敏：在查询特定敏感字段时，自动在 SQL 中套上脱敏函数，如 SELECT DES_PHONE(phone)