上周帮同事排查一个线上问题页面少了几十条数据表里数据明明都在。他把 SQL 发给我的时候我一眼就看到了问题应该放在 WHERE 里的过滤条件被他写进了 HAVING 后面。语法没报错结果就是不对。这种问题我在这些年里见过太多次。数据库查询这件事看起来门槛极低SELECT * FROM 谁都会写可一旦涉及多表关联、聚合统计、海量数据写法的差异会直接导致结果错误和性能雪崩。这篇文章我想把查询这条链路完整讲透——从 SQL 执行的底层逻辑到日常写法的取舍再到不同数据库、不同开发框架里的查询差异最后落到性能排查的实操链路。适合刚入门的数据分析师、初中级后端开发也适合被慢查询折磨过几轮的同学参考。你会发现很多报错好奇怪的问题根源只有一个查询不是捞数据而是用严谨的语言去描述你想要的结果集。1. 先别急着写 SQL查询的本质是描述结果形态1.1 关系模型下的一行查询到底在做什么我一直跟组里的新人说写 SQL 之前先在脑子里把关系模型这四个字过一遍。数据库查询本质上是在关系模型上做集合运算。SELECT 是投影WHERE 是筛选JOIN 是连接GROUP BY 是折叠ORDER BY 是排序每一类操作都有自己固定的时机。你把时机搞错语法怎么优化都白搭。举个生活化的例子。你去菜市场买菜第一步是决定买哪几样菜SELECT 选择列然后走到菜摊前只挑新鲜的WHERE 过滤行再把肉摊和蔬菜摊的清单拼在一起看JOIN 连接表最后把所有东西按类汇总算花了多少钱GROUP BY 聚合。如果你倒过来先把所有菜混在一起按类汇总再想挑出坏掉的那就晚了——汇总之后你根本不知道哪棵菜是坏的。典型的错误写法就藏在这里。很多人要查每个分类下销量前 10 的商品上来就这么写SELECT category_id, product_id, SUM(sales_amount) FROM sales GROUP BY category_id, product_id ORDER BY SUM(sales_amount) DESC LIMIT 10;这个查询的结果不是每个分类的前 10而是全表按分类聚合后再排序取前 10。为什么因为 GROUP BY 先把数据折叠了LIMIT 是对折叠后的结果集做截断。正确的思路是先让每个分类内部排序再取前 10最后合并。这类错误在 MySQL 低版本里甚至不会报错看起来结果也跑出来了但语义完全错位。1.2 最容易被忽视的 SQL 执行顺序很多人写 SQL 报错第一反应是语法错了其实大量看起来莫名其妙的报错本质是没搞懂 SQL 的执行顺序。你在编辑器里写的顺序是SELECT - FROM - WHERE - GROUP BY - HAVING - ORDER BY - LIMIT。但数据库真正执行时逻辑顺序是这样的执行顺序操作说明1FROM / JOIN确定数据来源生成中间结果集2WHERE对原始行做过滤3GROUP BY按条件分组4HAVING对分组后的结果做过滤5SELECT投影列计算别名和聚合表达式6ORDER BY排序这里可以使用 SELECT 生成的别名7LIMIT / OFFSET截断返回行数理解这个顺序很多困惑迎刃而解。比如 WHERE 里不能使用 SELECT 中的别名。你写SELECT name, COUNT(*) AS cnt FROM orders WHERE cnt 5 GROUP BY name;会直接报错Unknown column cnt in where clause。不是数据库不聪明而是执行 WHERE 的时候cnt 这个别名的表达式还没计算出来它根本不存在。你以为是语法问题其实是时机问题。HAVING 则相反它发生在 GROUP BY 之后所以你可以写HAVING COUNT(*) 5因为 COUNT(*) 在分组时已经算好了。甚至很多数据库允许 HAVING 引用 SELECT 里的别名比如HAVING cnt 5MySQL、PostgreSQL 都支持但在 Apache Hive、某些严格模式的数据库里会被拒绝。为了让查询更可移植我习惯在 HAVING 里直接写完整表达式而不是依赖别名。有一个更好的记忆方法把 SQL 的执行顺序想象成一条流水线。FROM 是原料入库WHERE 是质检淘汰GROUP BY 是装箱HAVING 是拆箱抽查SELECT 是贴标签ORDER BY 是码放LIMIT 是最终只运走前几箱。任何想在流水线前段使用后段产物的人都会碰壁。2. 从需求到 SQL把业务翻译成集合运算的完整链路2.1 拿到需求先问三个问题我处理过很多查询结果不对的工单最后发现大部分问题根本不在 SQL 本身而是需求一开始就是模糊的。所以在写任何查询之前先逼自己回答三个问题。第一个问题结果集长什么样你要哪些字段、多少行、要不要去重。很多业务方说查一下这个月的订单翻译过来是这个月所有订单的所有字段吗还是这个月每个用户的订单总额字段清单没列出来之前你写出来的 SQL 必然靠猜。第二个问题数据的边界在哪最常见的边界就是时间范围此外还有业务状态有效/无效、权限范围只能看自己的数据、隔离级别下的可见性。边界少写一个结果就会多出一批不属于这个集合的数据。第三个问题数据的粒度是什么这是最容易被忽略的。同一张订单表按订单行看是明细粒度按用户聚合是汇总粒度按城市聚合是另一种汇总粒度。粒度没确认GROUP BY 写错了结果差之千里。拿个经典需求举例统计近 30 天每个城市下单超过 3 次的用户 ID按次数降序。三个问题问完答案分别是需要输出 user_id、city、下单次数边界是 created_at 在近 30 天内且订单状态有效粒度是用户城市一个用户在一个城市下单多次算多次。这时候 SQL 的轮廓已经很清楚剩下的是往框架里填内容。2.2 从需求到 SQL 的七个步骤我习惯把写查询拆成七个步骤每一步只解决一个问题避免一次性把所有逻辑堆进大脑。写下目标字段清单包括结果里要展示的列和后续可能要用的排序列。确定数据源。单表还是多表如果是多表关联键是什么JOIN 的方向是 inner 还是 left先写 WHERE 过滤。把所有行级过滤条件列全比如时间范围、状态值、租户 ID。这一步决定了最终结果集的边界。确定是否需要聚合。如果需要明确分组维度是什么也就是 GROUP BY 后面跟哪些列。决定返回行数和排序。分页参数、Top N、排序字段和方向。写出第一个版本先加上 LIMIT 限制避免误操作拉全表。用 EXPLAIN 或等价工具检查执行计划确认没有全表扫描和明显的 filesort。用刚才近 30 天城市下单超 3 次用户的需求走一遍流程最终 SQL 大概是这样的SELECT u.id AS user_id, u.city AS city, COUNT(*) AS order_cnt FROM orders o JOIN users u ON u.id o.user_id WHERE o.created_at NOW() - INTERVAL 30 DAY AND o.status paid GROUP BY u.id, u.city HAVING COUNT(*) 3 ORDER BY order_cnt DESC;细看 GROUP BY 这里为什么不只写GROUP BY u.id因为 SELECT 里出现了 u.city而 city 字段并不依赖于 u.id 也没被聚合包裹。在 MySQL 开启ONLY_FULL_GROUP_BY的默认模式下这种写法会直接报错提示Expression #2 of SELECT list is not in GROUP BY clause。在旧版本里不报错但返回的 city 值是不可预测的——同一个用户在不同城市下的单到底显示哪个城市完全随机。这类看起来跑通了但结果可疑的问题比报错更可怕。2.3 结果正确性自检不核对就交付等于没查很多人写完 SQL跑出几行数据就发出去这是最危险的习惯。SQL 不像代码没有单元测试执行成功了不代表结果正确。我交付任何查询之前至少做四步自检。第一步先看行数。对当前查询去掉 LIMIT跑一个SELECT COUNT(*) FROM (原查询) t判断数量级是否符合预期。比如你查这个月的异常订单数量只有个位数而业务方说每天都有几十单那一定有问题。第二步抽样看数据。在原查询加LIMIT 20把结果打印出来人工检查字段值是否合理、关联是否对得上。第三步边界测试。把时间范围往前多扩一天、往后多扩一天看数据量是否平滑。如果前一秒是 10000 条扩一天变成 30000 条说明时间边界或者时区处理出了岔子。第四步反向验证。想知道少了哪些可以用NOT EXISTS查出应该出现但没有出现的集合跟业务方确认这些是否真该被排除。比如统计活跃用户用某个条件过滤掉一批用户之后单独跑一条NOT EXISTS把所有被过滤掉的用户列出来一条条过目比对着总数怀疑人生靠谱得多。这套流程看起来很繁琐但熟练之后每步只需要几十秒。它能让你在数据质量问题上比大多数同事少踩一半的坑。3. 查询写法里的经典取舍JOIN、IN、EXISTS 和子查询3.1 IN 和 EXISTS 不是简单等价的两种写法IN 和 EXISTS 是 SQL 里最经典的一组对比也是面试高频题。关键不是背结论而是理解它们的执行方式。IN 的常规执行思路是先把子查询的结果集构造出来生成一张内存里的临时集合然后逐行判断外层数据是否在集合中。所以当子查询的结果集很小、外层表很大的时候IN 的表现通常让人满意。EXISTS 则完全不同。它的执行思路是对外层表的每一行去判断是否存在一条满足条件的子查询记录只要子查询返回了至少一条立刻停止继续找。这是一种相关子查询适合子查询结果集很大、外层稀疏的场景。简单归纳场景更推荐子查询结果集小几百几千条IN外层表小、子查询结果集大EXISTS需要处理 NULL 语义EXISTS尤其 NOT EXISTS两者都能满足的简单场景优先 IN可读性更高我实际项目里遇到最多的坑是 NOT IN 配合 NULL。比如你想找从未下过单的用户写SELECT * FROM users WHERE id NOT IN (SELECT user_id FROM orders);如果 orders.user_id 这一列里存在 NULL这个查询永远返回空集。原因在于 NOT IN 的语义是不等于子查询结果中的任何值而 NULL 参与比较时结果不是 false 而是 unknownWHERE 只保留 true 的行于是所有行都被过滤掉了。等价需求用 NOT EXISTS 写就完全不受影响SELECT * FROM users u WHERE NOT EXISTS ( SELECT 1 FROM orders o WHERE o.user_id u.id );说实话现代数据库优化器已经能把 IN 改写成半连接也能把 EXISTS 优化成反连接性能差异越来越小但 NULL 语义这个坑是实打实的任何优化器都不会替你做业务判断。我的建议是凡是取反的逻辑统一用 NOT EXISTS正向存在性判断IN 和 EXISTS 都可以看哪个更易读。3.2 JOIN 和子查询的适用场景先算集合还是先连表JOIN 做的事情是把两张表横向合并成一张更宽的表子查询做的事情是先算出一个中间集合再拿这个集合参与外层运算。两者的选择没有一个万能公式但有一条经验法则能用 JOIN 的时候优先用 JOIN因为优化器对 JOIN 的执行计划优化空间更大索引利用率更高子查询本身也是一段执行单元嵌套层级一多可读性和性能同时下降。举个例子。需求是每个分类下最新发布的一件商品。一种写法是相关子查询SELECT p.* FROM products p WHERE p.created_at ( SELECT MAX(created_at) FROM products p2 WHERE p2.category_id p.category_id );这个写法逻辑正确但一旦某个分类里有两条发布时间完全一致的商品结果就会多出来。而且相关子查询会重复执行为每一行外层数据执行一次即便优化器做了物化表达上也绕。更好的方案是用窗口函数SELECT * FROM ( SELECT p.*, ROW_NUMBER() OVER ( PARTITION BY category_id ORDER BY created_at DESC, id DESC ) AS rn FROM products p ) t WHERE rn 1;窗口函数只扫描一次表同时解决了并列排序的问题。ORDER BY 里加 id DESC 是为了给发布时间相同的记录一个稳定的先后顺序。这是我在大量实际查询里最常用的一类写法比相关子查询的掌控感强太多。这里要特别警惕一个误导很多人以为子查询返回一行所以 JOIN 会更慢子查询返回很多行JOIN 会更合适这完全是拍脑袋。你的决策依据应该是要不要在合并前后做聚合、去重、窗口计算哪个写法能让优化器更容易命中索引哪个写法的执行计划更容易被预测。真到了性能瓶颈用 EXPLAIN 说话不要靠猜。3.3 GROUP BY、HAVING 与 ONLY_FULL_GROUP_BY 的恩怨GROUP BY 是聚合查询的核心但它也是误用重灾区。最常见的错误就是把不属于分组键也未被聚合的字段写进 SELECT。SELECT name, user_id, SUM(amount) FROM orders GROUP BY user_id;如果 users.name 和 orders 表在同一个查询里name 字段既不在 GROUP BY 里也没被聚合函数包裹MySQL 5.7 以下不会报错随机取一个 user_id 对应的 name 作为结果。这不是猜对或猜错的问题而是结果根本没有确定性保证。从 MySQL 5.7 默认开启ONLY_FULL_GROUP_BY之后这种 SQL 会直接报错Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column orders.name which is not functionally dependent on columns in GROUP BY clause面对这种报错不少人的第一反应是关掉 ONLY_FULL_GROUP_BY我强烈不建议这样做。正确做法是正视语义你到底想要每个 user_id 一行还是想要每个 (user_id, name) 组合一行如果是前者name 字段必须明确如何取值——用MAX(name)、MIN(name)或者用子查询先取每个用户最近一笔订单再关联原表拿 name。实际开发中最常见的需求是每个用户最近一笔订单的金额和用户名正确写法是SELECT o.user_id, u.name, o.amount FROM orders o JOIN users u ON u.id o.user_id WHERE o.created_at ( SELECT MAX(created_at) FROM orders o2 WHERE o2.user_id o.user_id );别嫌这种写法啰嗦它胜在语义完全确定。我在团队里推行一个原则任何 SELECT 的非聚合列要么在 GROUP BY 里要么被聚合函数包裹要么你能解释清楚数据库是怎么取到的。解释不清楚的跑出来也等于没跑。4. 换个环境查询立刻变样数据库方言与编程接口4.1 分页写法差异MySQL、Oracle、达梦各不一样SQL 标准一直在统一各家方言但分页语法直到今天都没有完全统一。同一个需求从第 21 行开始取 10 行在不同数据库里写法完全不同数据库写法MySQL / PostgreSQLLIMIT 10 OFFSET 20Oracle12cOFFSET 20 ROWS FETCH NEXT 10 ROWS ONLYOracle旧版嵌套ROWNUM 30再过滤RN 20SQL ServerOFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY达梦兼容 Oracle 模式通常支持FETCH FIRST 10 ROWS ONLY视版本而定近几年达梦数据库在不少项目里出现得很频繁很多团队把原本跑在 Oracle 上的老系统迁移过去。查询语句大部分能兼容但分页和序列这两块细节最容易翻车。迁移之后我建议至少把每个核心查询都跑一遍重点检查 ROWNUM、ROW_NUMBER、SYSDATE 这类 Oracle 习惯写法的行为差异别指望一次性全量兼容。比方言差异更值得关注的是深分页的性能问题。LIMIT 100000, 20看起来只取 20 条但 MySQL 会先扫描出前 100020 行再丢弃前 100000 行翻页越深性能衰减越明显。生产环境常用键集分页替代记住上一页最后一条记录的主键或唯一键下一页用WHERE id last_max_id来定位。SELECT id, name, created_at FROM orders WHERE id 123456 ORDER BY id LIMIT 20;这种写法在数据量大、翻页频繁的场景下比 OFFSET 稳定得多。代价是需要前端配合传递上一页的最后一条 ID有些场景改造成本高但收益很直接。4.2 Python 连接 Oracle 查询占位符、游标和连接池用 Python 查 Oracle 是数据开发里非常常见的需求。旧习惯是装 cx_Oracle现在的官方库叫 python-oracledb用法基本一致还新增了纯 Python 的 thin 模式。如果只是常规查询thin 模式不需要安装 Oracle Instant Client部署成本低很多如果要走一些高级网络特性再用 thick 模式。一个最基础的查询流程是这样的import oracledb conn oracledb.connect( userscott, passwordtiger, dsn192.168.1.10:1521/ORCLPDB ) cur conn.cursor() cur.execute( SELECT id, name, city FROM users WHERE city :city AND created_at :start_time, {city: 上海, start_time: 2025-01-01} ) for row in cur.fetchmany(100): print(row[0], row[1], row[2]) cur.close() conn.close()这里最值得强调的就是占位符:city。我见过太多人把 Python 变量直接格式化进 SQL 字符串里一旦业务输入里带着引号或特殊字符轻则乱套重则出安全问题。用参数绑定既安全又让数据库可以复用执行计划。另一个实践心得是取数据要用fetchmany不要一上来就fetchall。如果查询结果有几百万行fetchall会把整个结果集塞进 Python 进程内存机器直接卡死。fetchone适合单条结果fetchmany(100)适合批量处理处理一批释放一批内存可控。连接本身也是一笔很大的开销。建立一条数据库连接需要 TCP 握手、服务端认证、分配会话资源耗时几十毫秒到几百毫秒不等。频繁地创建和销毁连接查询本身的耗时反而成了次要因素。这就引出了数据库连接池这个常被忽略的点——不要每次查询都新建连接用一个池子维护若干条空闲连接用完放回去。Java 生态里有 HikariCP、DruidPython 里可以用 SQLAlchemy 的连接池原理都是同一套池子里的连接复用连接数设上限避免把数据库的连接数打爆。还有一个细节查数据库前设置好客户端字符集和时区。Oracle 连接里 NLS 参数不对中文查出来成乱码日期字段解析错位这类问题排查起来特别费时间。与其事后处理不如在连接串里显式指定好这些参数。4.3 Django ORM 查询的惰性与 N1 查询从裸 SQL 切到 Python 的 Django很多人的第一印象是ORM 真方便。但 ORM 掩盖了查询的真实行为产生的隐性问题比裸 SQL 更难定位。Django 的 QuerySet 是惰性的。写Order.objects.filter(statuspaid)时数据库一条 SQL 都不会执行。只有当你迭代它、调用list()、len()、bool()、切片等操作时查询才真正发出去。这在写复杂过滤条件时很友好可以链式拼装条件而不用担心中间步骤查库。但惰性也带来了经典的 N1 问题。看这段代码orders Order.objects.filter(statuspaid) for order in orders: print(order.user.username)第一次执行orders的迭代时Django 发一条 SQL 查出所有订单。接着循环里访问order.user每访问一次就发一条 SQL 查用户表。如果订单有 1000 条总查询次数就是 1001 条。数据库本地的开销还没什么一旦网络往返延迟就被无限放大。解决方案是预加载orders Order.objects.filter(statuspaid).select_related(user) for order in orders: print(order.user.username)select_related会通过 SQL JOIN 把外键对应的 user 一次查出来1001 条查询变成 1 条。多对多关系或者反向关联则要用prefetch_related它会执行两条 SQL然后在 Python 侧完成关联组装。这里我要额外提醒一点Django 里执行查询-删除对象经常被连在一起说但 ORM 的delete()并不会触发 QuerySet 的缓存逻辑。如果你先把一批对象查出来存成了列表期间别人把数据改了你直接调obj.delete()删掉的可能是旧数据也可能因为并发导致对象已被删而报错。删除之前重新确认一次数据状态比盲目相信 ORM 的封装更安全。4.4 向量数据库和 JSON 字段查询的边界正在扩大聊到数据库查询不能只盯着传统的关系模型。这几年我明显感觉到查询的形态正在被两类东西改变JSON 半结构化数据和向量语义检索。先说 JSON 字段查询。MySQL 从 5.7 开始支持 JSON 类型可以直接对 JSON 内部的字段做条件过滤。比如用户表里有个 profile 字段存了一堆标签和属性想找出年龄大于 30 的用户可以写SELECT name FROM users WHERE JSON_EXTRACT(profile, $.age) 30;在 MySQL 中还有更简洁的写法-运算符等价于JSON_EXTRACT-则会把结果转成字符串SELECT name FROM users WHERE profile-$.age 30; SELECT name FROM users WHERE profile-$.name 张三;用-的场景通常是为了避免 JSON 值类型带来的隐式转换问题比如 json 里的数字在提取后可能是字符串拿来和数字比较会不稳定。这类函数式查询可以解决很多需要加字段但不想改表结构的临时需求但要注意JSON_EXTRACT这类带上函数的写法可能会让索引失效生产环境高频查询还是要落成独立字段。再说向量数据库。传统 SQL 查询是精确匹配你的条件是确定性的——id 等于多少、时间在哪个范围、状态是哪个值。向量数据库回答的却是另一个问题哪条记录和这条记录语义上最相似它把文本、图片、音频编码成向量查询时传入一个向量返回按距离排序的 Top K 条结果。比如 AI 知识库里的记忆检索、推荐系统里的相似商品用的都是这套逻辑。向量数据库的索引结构也不是 B 树而是 HNSW、IVF、PQ 这类专门为高维近似检索设计的索引。它返回的结果不是精确的而是近似的所以很多场景会用召回率来衡量查询质量这在传统数据库里完全没有对应的概念。我个人的经验是向量数据库不是 MySQL 的替代品而是补充。需要精确统计、事务性操作还是老老实实回到关系数据库的怀抱。5. 查询性能排查的实操链路从慢查询日志到执行计划5.1 一条慢查询的完整定位过程分享一个我印象很深的线上问题。某个订单列表接口原本 300ms 能返回某天突然涨到了 3 秒以上。接口后面就是一个简单的分页查询SQL 长这样SELECT id, order_no, user_id, amount, status, created_at FROM orders WHERE status paid ORDER BY created_at DESC LIMIT 20;排查链路是这样的。第一步确认慢查询日志。MySQL 可以用SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 1;这样超过 1 秒的查询都会进日志。云数据库通常也提供控制台慢日志。等了一会儿找到这条 SQL 确实在里面。第二步跑 EXPLAINEXPLAIN SELECT id, order_no, user_id, amount, status, created_at FROM orders WHERE status paid ORDER BY created_at DESC LIMIT 20;结果里两行信息触目惊心type ALL全表扫描rows 560000预估扫了 56 万行Extra Using filesort排序没走索引。一条分页查询要扫全表再排序3 秒太正常了。第三步看订单表现有的索引情况。发现只有一个主键索引status 和 created_at 都没索引。第四步加联合索引ALTER TABLE orders ADD INDEX idx_status_created (status, created_at);这个索引的设计意图是WHERE status paid 走索引最左前缀ORDER BY created_at 走索引第二列排序顺便省掉 filesort。再次跑 EXPLAINtype refrows 1200Extra里只剩一行接口恢复 200ms。这类问题的修复成本很低但排查链路必须完整。经验不足的同学经常是看到慢日志就直接加索引加完不验证结果发现自己加了索引但查询没走或者走了索引排序还是 filesort白白浪费时间。5.2 执行计划里最值得看的几个信号EXPLAIN 的输出列很多但真正值得盯住的就几个关键信号字段良好信号风险信号typeconst、eq_ref、ref、rangeALL、indexkey有实际使用的索引名NULLrows接近实际返回行数远超预期数量级ExtraUsing index覆盖索引Using filesort、Using temporarytype 按性能从好到差大致是system const eq_ref ref range index ALL。range 说明已经走索引但做范围扫描可以接受index 指扫描整棵索引树有时比 ALL 好一点但好得有限ALL 就是全表扫描数据量一大就危险。Extra 里的 Using filesort 代表排序要用临时文件完成通常意味着 ORDER BY 的字段没有命中索引。Using temporary 常出现在 GROUP BY、DISTINCT、某些 JOIN 场景意味着数据库建了临时表内存不够还会落盘。Using index 是最好的一档覆盖索引查询需要的数据全在索引页里不用回表。看到这些信号之后的反应应该是为什么而不是换个写法试试。如果 rows 比预期高十倍先想想是不是统计信息没更新再想想索引基数是不是太低。如果明明在 WHERE 里用了索引列但 type 还是 ALL优先怀疑函数包裹或隐式类型转换而不是急着加索引。5.3 典型的索引失效场景哪些写法会让索引白加索引解决了大量性能问题但也存在各种写法规避索引的情况。我把日常最常踩的几个列在这里每条后面都附带应对姿势。第一对索引列包函数。WHERE DATE(created_at) 2025-01-01会让 created_at 上的索引失效因为优化器无法从函数的输入直接推算出索引范围。改成范围条件WHERE created_at 2025-01-01 AND created_at 2025-01-02索引就能正常使用。第二隐式类型转换。表里 mobile 是 varchar 类型查询却写WHERE mobile 13800138000。数字和字符串比较时数据库会把字符串转成数字索引失效。把右侧改成字符串13800138000才能命中索引。第三LIKE 前模糊。LIKE %abc无法使用 B 树索引因为字符串匹配需要从左边开始定位。如果是LIKE abc%索引就能用。这个规则很简单但越是习惯用前模糊搜索的人越容易忽略。第四OR 连接多个条件。WHERE age 30 OR score 90即使 age 和 score 各自身上有索引优化器也可能选择全表扫描因为要合并两个索引的结果。改写思路是用 UNION ALL 拆开SELECT * FROM users WHERE age 30 UNION ALL SELECT * FROM users WHERE score 90;第五联合索引不满足最左前缀。索引 (a, b, c)查询条件只用了 b没用 a那 b 就用不上这个联合索引。这类问题在你加了很多单列索引之后特别容易出现——你以为多个单列索引能自由组合实际上优化器大多数场景只能选一个效果最好的联合索引才是处理多列过滤的正确手段。5.4 连接池、查询超时与一个朴素的安全习惯最后说几个和查询相关但经常被摆在查询之外的管理性问题。数据库连接是稀缺资源。每个连接都要占内存、占会话连接数超了新查询直接排队。连接池的真正作用不是加速单条查询而是控制并发连接总量让有限的连接被高效复用。我见过一个项目接口每次请求都新建连接高峰期直接把数据库连接数打满后来的请求全部超时。改成连接池之后总量恒定队列里的请求虽然慢一点但至少不会雪崩。查询超时要设置。在框架层面给执行语句加超时避免一条 SQL 挂住不返回长时间霸占连接。MySQL 的连接层可以设max_execution_timePython 的驱动里有 timeout 参数Java 的 JDBC 有statementTimeout。这些东西平时不会用到但一旦出现几条坏 SQL它们能保住整个应用不被拖死。上面这些都属于技术层面再补一个我已经养成的习惯写 UPDATE 和 DELETE 之前先改成同名 SELECT 确认范围和行数。数据库增删改查四个操作查是最安全的删改的风险指数高几个量级。我见过凌晨误操作把整张订单表清空的案例就是因为脚本里少了一个 WHERE。做法很简单先写SELECT COUNT(*) FROM orders WHERE 条件确认数量再改成 DELETE。宁可多跑一条查询也不要把整个表搭进去。这个习惯花不了几秒但能避免的事故是灾难级的。它和应用层写代码先写测试用例是一个道理——在危险操作外加一道安全网。6. 写在最后查询写得好不好差在思维方式6.1 每次写查询前多花半分钟想清楚数据量我见过太多人写 SQL 前从不问这张表到底有多少行反正 SELECT * 一梭子下去出了结果再说。等到生产环境数据量上来同样的写法从跑 3 秒变成跑 3 分钟才回头找索引、改分页。我个人的习惯是写任何查询前先在脑子里预估这张表的数据量级。几十万行的表和几亿行的表查询策略完全是两套。前者的全表扫描也许可以容忍后者哪怕少个索引都可能拖垮数据库。这个预估有时也来自经验比如曾经跑过的SELECT COUNT(*)、看过的执行计划里 rows 的值。时间久了你对数据规模的感知会非常敏锐。6.2 三个让我少踩坑的朴素习惯最后分享三个我坚持了很多年的小习惯不算高深但关键时刻真能救命。第一任何复杂查询跑通之后立刻用 EXPLAIN 检查一遍执行计划别等到线上慢了再回头查。查询是从一套数据里筛出另一套数据的逻辑过程语句写完了不代表数据库会用高效的方式执行它。第二把常用查询参数化而不是在代码里拼接 SQL 字符串。占位符不仅是安全需要也是让数据库缓存执行计划的基础。同一个模板反复拼接出的 SQL数据库每次都要重新解析。第三遇到报错好奇怪的时候先别怀疑数据库有问题把报错信息按执行顺序拆开看。字段不存在、函数不识别、分组报错绝大多数都能追溯到 SQL 的某一步时机错误。数据库是最忠实于逻辑的系统它报错或返回奇怪结果大概率是你的描述出了问题。把这些习惯建立起来你会发现查询这件事从碰运气慢慢变成了可预期。数据不会骗人前提是你真正理解了它。