上周三下午，提交我在后台盯着一条查询卡了整整四分钟。数据页面转圈，查询数据库连接池告警，提交前端同事跑过来问是数据不是接口挂了。其实只是查询运营同学拉了一份“近90天未登录用户名单”，SQL里套了三层子查询，提交还用了LIKE '%关键词%'。数据这事不新鲜，查询但每次遇到都让人想拍桌子——提交数据查询，提交从来不是数据点一下“搜索”那么简单。

很多人以为查询就是查询告诉数据库“我要什么”。真到生产环境里，提交你写的数据每一行条件都在和索引、锁、查询内存较劲。我见过一个刚入行的开发，写了个SELECT * FROM orders WHERE DATE(create_time) = '2024-05-01'，表里两千万行，跑一次全表扫描，直接把从库拖垮。他委屈：逻辑没错啊。逻辑是没错，但数据库不认逻辑，只认执行计划。

提交查询之前，先问自己三个问题：过滤字段有没有索引？返回列是不是真的都要？排序和分页会不会让临时表爆掉？这三个问题能筛掉八成慢查询。我自己的习惯是，写WHERE的时候先看EXPLAIN，type列出现ALL就回去改。别嫌麻烦，改一次比线上出事故再回滚省事得多。

还有一种情况更隐蔽。查询本身不慢，但提交频率太高。比如前端做了个“实时刷新”，每两秒调一次接口，每次查最近五分钟的订单。数据库没挂，但连接数蹭蹭往上涨。后来我们把刷新间隔改成十秒，加了一层Redis缓存，同样的查询语句，压力降了七成。你看，问题不在SQL，在提交的节奏。

说到提交，不得不提参数化查询。有些老代码还在用字符串拼接，用户输入个单引号就能把表删了。这年头ORM框架遍地都是，PreparedStatement也不复杂，但就是有人图省事。我接手过一个项目，登录接口的查询是"SELECT * FROM users WHERE name='" + username + "'"。测试的时候没人发现，上线第二天就被扫出注入点。修起来倒快，但那种后背发凉的感觉，记到现在。

查询提交出去，返回结果怎么处理也有讲究。见过一个报表页面，一次性SELECT出十万行，后端全塞进List，再序列化成JSON发给前端。浏览器直接卡死。后来改成游标分批取，每批两千行，前端滚动加载，体验反而更好。数据不会因为你一次拿完就变少，但内存会因为你一次拿完而爆掉。

说回开头那个运营需求。我最后把SQL拆成两步：先查活跃用户ID存临时表，再LEFT JOIN排除。加了create_time的索引，查询时间从四分钟降到一点八秒。运营同学说“哦，好了啊”，然后继续拉下一份。我盯着监控面板，心想：你永远不知道一个简单的“查询”背后，有多少人在替它兜底。

提交数据查询这件事，写起来是SELECT，跑起来是资源，管起来是纪律。别把它当成一个按钮，它更像一次谈判——你和数据库之间，关于索引、内存和时间的谈判。谈崩了，页面转圈；谈成了，没人会夸你，但至少没人拍桌子。