Presto 驱动升级引发的生产事故：超长 SQL 400 报错排查记
问题现象 普通 SQL 正常，stg 环境没发现异常。但生产环境用户反馈：超长 SQL（超过 1MB）会触发 400 报错。 恰好生产环境的用户有很多那种业务逻辑复杂、拼接出来的超长 SQL。 排查过程 第一步是对比。把报错的 SQL 和不报错的 SQL 摆在一起看，唯一的共同点就是——长。 短 SQL 跑得好好的，长到一定长度就 400。这不是 SQL 语法问题，是传输层的问题。 根因 查到最后，原因是这样的： 安全合规要求，把普通的 Statement 升级为 PreparedStatement。因为普通 Statement 有 SQL 注入风险，安全团队要求整改。 Presto 驱动版本太低，低版本的 Presto JDBC 驱动对 PreparedStatement 的支持不完善，特别是对超长 SQL 的处理有 bug。 服务端 Presto 没有同步升级。原因很简单——影响太大，涉及的下游服务和业务太多，不敢动。 所以就出现了一个尴尬的局面：客户端驱动升级了（为了安全），服务端没升级（为了稳定），两边版本不一致，超长 SQL 直接 400。 解决方案 还原升级。 把客户端驱动退回到兼容当前服务端的版本。安全问题用其他方式规避（比如在应用层做参数化查询、输入校验等）。 这不是最优解，但在"安全"和"可用"之间，先保可用。 避坑建议 1. 灰度环境重点覆盖验证 stg 环境为什么没发现？因为测试用的 SQL 都是短的。灰度环境应该重点覆盖边界场景： 超长 SQL（1MB+） 特殊字符 高并发场景 2. 客户端和服务端版本要对齐 升级驱动前，先确认服务端版本兼容性。不要客户端升了、服务端没升，两边版本不一致是定时炸弹。 3. 安全整改要评估影响面 ...