https://fxio.site/tags/%E8%B8%A9%E5%9D%91/Recent content in 踩坑 on FXIO 技术博客Hugo -- 0.157.0zh-cnWed, 10 Jun 2026 01:30:00 +0800https://fxio.site/posts/java/presto-driver-upgrade-bug/Wed, 10 Jun 2026 01:30:00 +0800https://fxio.site/posts/java/presto-driver-upgrade-bug/<h2 id="问题现象">问题现象</h2> <p>普通 SQL 正常，stg 环境没发现异常。但生产环境用户反馈：<strong>超长 SQL（超过 1MB）会触发 400 报错</strong>。</p> <p>恰好生产环境的用户有很多那种业务逻辑复杂、拼接出来的超长 SQL。</p> <h2 id="排查过程">排查过程</h2> <p>第一步是对比。把报错的 SQL 和不报错的 SQL 摆在一起看，唯一的共同点就是——<strong>长</strong>。</p> <p>短 SQL 跑得好好的，长到一定长度就 400。这不是 SQL 语法问题，是传输层的问题。</p> <h2 id="根因">根因</h2> <p>查到最后，原因是这样的：</p> <ol> <li><strong>安全合规要求</strong>，把普通的 <code>Statement</code> 升级为 <code>PreparedStatement</code>。因为普通 Statement 有 SQL 注入风险，安全团队要求整改。</li> <li><strong>Presto 驱动版本太低</strong>，低版本的 Presto JDBC 驱动对 <code>PreparedStatement</code> 的支持不完善，特别是对超长 SQL 的处理有 bug。</li> <li><strong>服务端 Presto 没有同步升级</strong>。原因很简单——影响太大，涉及的下游服务和业务太多，不敢动。</li> </ol> <p>所以就出现了一个尴尬的局面：客户端驱动升级了（为了安全），服务端没升级（为了稳定），两边版本不一致，超长 SQL 直接 400。</p> <h2 id="解决方案">解决方案</h2> <p><strong>还原升级。</strong></p> <p>把客户端驱动退回到兼容当前服务端的版本。安全问题用其他方式规避（比如在应用层做参数化查询、输入校验等）。</p> <p>这不是最优解，但在&quot;安全&quot;和&quot;可用&quot;之间，先保可用。</p> <h2 id="避坑建议">避坑建议</h2> <p><strong>1. 灰度环境重点覆盖验证</strong></p> <p>stg 环境为什么没发现？因为测试用的 SQL 都是短的。灰度环境应该<strong>重点覆盖边界场景</strong>：</p> <ul> <li>超长 SQL（1MB+）</li> <li>特殊字符</li> <li>高并发场景</li> </ul> <p><strong>2. 客户端和服务端版本要对齐</strong></p> <p>升级驱动前，先确认服务端版本兼容性。不要客户端升了、服务端没升，两边版本不一致是定时炸弹。</p> <p><strong>3. 安全整改要评估影响面</strong></p>