SQL基础查询实战：去重、聚合、分页优化与避坑指南

说实话，“基础查询示例”这个标题看起来简单到不能再简单，但我见过太多开发者在基础查询上栽跟头。有人把去重写成了多层子查询，有人不知道DISTINCT和GROUP BY的差异，有人被分页慢搞得焦头烂额，还有人因为一个IN查询的边界条件直接把线上服务干挂。这篇文章不打算做教科书式的罗列，而是把我在实际项目里反复用到的查询场景、优化思路和踩坑经验整理出来，从一条最简单的SELECT到慢查询日志定位，再到Redis缓存分页，一步不跳地讲清楚。适合刚入门的同学建立正确认知，也适合有经验的朋友查漏补缺。

1. 查询的核心概念与整体设计思路

1.1 查询不只是“把数据拿出来”

很多人把SQL查询理解为“把表里的数据拿出来”，这个理解没错，但它会限制你对查询的掌控力。我更愿意把查询看成一次集合运算：输入是一张或多张表，中间经过过滤、关联、分组、排序，最终输出一个结果集。SQL是一门声明式语言，你只需要告诉数据库“我要什么”，数据库自己决定“怎么拿”。但这不代表你什么都不用管，恰恰相反，你写出来的每条查询都会经过解析、优化、执行三个阶段，而执行计划直接决定了这次查询是毫秒级还是秒级。

理解SQL的执行顺序是排查问题的第一把钥匙。很多人以为SELECT在最前面就先执行，其实它是在最后面才执行的。一条标准查询的逻辑执行顺序大致是：FROM -> JOIN -> WHERE -> GROUP BY -> HAVING -> SELECT -> DISTINCT -> ORDER BY -> LIMIT。举个例子，当你写SELECT user_id, COUNT(*) FROM orders WHERE amount > 100 GROUP BY user_id HAVING COUNT(*) > 2时，数据库先从orders表取出数据，再根据amount过滤，再按user_id分组，再过滤分组结果，最后才投影出user_id和计数。如果你不理解这个顺序，就很容易犯“在WHERE里用别名”或者“在WHERE里用聚合函数”这种低级错误。

我自己在优化查询时，第一件事永远是看执行计划。MySQL用EXPLAIN SELECT ...，Oracle用EXPLAIN PLAN FOR，PostgreSQL用EXPLAIN ANALYZE。执行计划里最关键的是看访问类型type、命中的索引key、扫描行数rows。只要发现type是ALL全表扫描，rows又特别大，基本就是优化重点。后面聊慢查询时，我会再结合实际例子展开。

1.2 示例业务场景与表结构设计

为了让后面的示例不悬空，我设计一个最经典的电商场景：用户表和订单表。用户表包含用户基本信息，订单表记录每笔订单的金额和下单时间。这种设计能覆盖单表查询、去重、聚合、关联、分页、视图、慢查询等几乎所有基础场景。

假设用户表结构如下：

sql复制CREATE TABLE users (
  id INT PRIMARY KEY,
  user_name VARCHAR(50) NOT NULL,
  phone VARCHAR(20),
  created_at DATETIME
);

订单表结构如下：

sql复制CREATE TABLE orders (
  id INT PRIMARY KEY,
  user_id INT NOT NULL,
  amount DECIMAL(10,2) NOT NULL,
  status TINYINT NOT NULL DEFAULT 0,
  order_time DATETIME NOT NULL,
  INDEX idx_user_id (user_id),
  INDEX idx_order_time (order_time)
);

我故意给order_time和user_id都建了索引，因为查询优化的话题离不开索引。字段类型上，amount用DECIMAL而不是FLOAT，这是无数金额精度事故换来的经验，后面我会专门说这个问题。status字段用TINYINT存状态码，0表示待支付，1表示已支付，2表示已取消，这是很常见的做法。

这套表结构虽然简单，但足够支撑我们讨论所有基础查询示例。接下来的每个小节，我都会基于这两张表给出可执行的SQL，并且说明每条SQL在什么业务场景下使用，以及有什么注意事项。

2. 基础查询实操：从单表到多表

2.1 SELECT与条件过滤：别把简单查询写复杂

最基础的查询示例就是SELECT加WHERE。比如我想查所有金额大于100元的已支付订单，这个需求在很多报表里非常常见。

sql复制SELECT id, user_id, amount, order_time
FROM orders
WHERE amount > 100 AND status = 1;

这条SQL看起来人畜无害，但有几个细节值得说。第一，不要写成SELECT *。虽然结果一样，但表结构一旦变更，你的应用代码可能会拿到多余的字段，增加网络传输和内存开销，更糟的是如果表里加了超大字段（比如BLOB），一次查询能把数据库IO拖垮。第二，amount和status的条件组合看起来简单，但MySQL优化器不一定能同时用到两个索引，这时候就需要用EXPLAIN看实际执行计划，必要时建联合索引(status, amount)。

条件过滤里最容易翻车的是 NULL 判断。很多人写“查所有未取消的订单”时会写WHERE status != 2，但如果status允许NULL，这条SQL会把status为NULL的记录也过滤掉，因为NULL参与比较运算的结果是UNKNOWN，不是TRUE。正确做法是明确写出WHERE status != 2 OR status IS NULL，或者在表设计时就加NOT NULL DEFAULT 0。我见过太多线上数据对不上账的情况，最后定位到就是NULL值导致查询结果不一致。

另外，日期字段比较也是重灾区。如果你用WHERE order_time = '2024-06-01'，可能什么都查不到，因为order_time是DATETIME，实际值是2024-06-01 00:00:00或者带具体时分秒。正确写法是使用范围查询：

sql复制SELECT id, user_id, amount
FROM orders
WHERE order_time >= '2024-06-01' AND order_time < '2024-06-02';

这种写法还能让order_time索引生效。很多性能问题不是索引没建，而是你写的条件让索引失去了作用。

2.2 去重查询：DISTINCT和GROUP BY怎么选

热词里有“sql语句去重查询”，确实高频。去重最简单的写法是DISTINCT。比如想看看有哪些用户下过单，可以写：

sql复制SELECT DISTINCT user_id FROM orders;

这个查询会返回所有下过订单的用户ID，重复的user_id会被合并。它本质上是在SELECT阶段对结果集去重。如果你想知道去重后的用户数量，可以叠加COUNT：

sql复制SELECT COUNT(DISTINCT user_id) FROM orders;

但这里有个常见误区：COUNT(DISTINCT user_id)和COUNT(*)性能差距不小，尤其在大表上。前者需要扫描所有数据并维护一个去重集合，比较吃内存。如果只是想知道大概数量，可以考虑用近似统计或者走单独的计数表。

DISTINCT和GROUP BY都能去重，但使用场景有区别。DISTINCT适合简单的唯一值列举，而GROUP BY天生是为分组聚合设计的。比如想查每个用户的订单数，就必须用GROUP BY：

sql复制SELECT user_id, COUNT(*) AS order_cnt
FROM orders
GROUP BY user_id;

如果你在GROUP BY查询里想过滤分组结果，不能用WHERE，要用HAVING。比如只想看下单次数超过5次的用户：

sql复制SELECT user_id, COUNT(*) AS order_cnt
FROM orders
GROUP BY user_id
HAVING COUNT(*) > 5;

WHERE在分组前过滤行，HAVING在分组后过滤分组，这个顺序和SQL执行顺序完全一致。实际开发中我经常看到有人用WHERE COUNT(*) > 5，这直接就是一个语法错误，因为WHERE阶段还没有聚合结果。

还有一个多字段去重的细节。SELECT DISTINCT user_id, status FROM orders返回的是user_id和status两个字段组合的唯一值，而不是user_id唯一。如果你想按user_id去重但还要看status，逻辑上就不成立，必须先想清楚你要的唯一键到底是什么。这点在写报表SQL时特别容易混淆。

2.3 聚合查询：总金额、数量统计

聚合查询是基础查询里最贴近业务价值的。热词里的“oracle查询总金额”就是典型的聚合场景。求所有已支付订单的总金额，可以写：

sql复制SELECT SUM(amount) AS total_amount
FROM orders
WHERE status = 1;

在Oracle里，SUM(amount)如果遇到全表没有匹配的行，返回的是NULL而不是0。很多应用拿到NULL后直接参与计算，结果变成NULL，界面显示空白。所以更稳妥的写法是：

sql复制SELECT COALESCE(SUM(amount), 0) AS total_amount
FROM orders
WHERE status = 1;

MySQL里也可以用IFNULL(SUM(amount), 0)。这个细节在报表开发里太重要了，我见过不少同事因为没处理NULL，导致汇总金额一栏出现空值，最后还得花时间排查。

聚合查询另一个常见场景是按维度分组统计。比如按月份统计订单总金额：

sql复制SELECT DATE_FORMAT(order_time, '%Y-%m') AS order_month,
       SUM(amount) AS total_amount
FROM orders
WHERE status = 1
GROUP BY DATE_FORMAT(order_time, '%Y-%m');

这里要提醒一句：GROUP BY后面的表达式和SELECT后面的表达式必须保持一致，否则在一些数据库里会报错，在另一些数据库里可能返回难以预料的结果。另外，DATE_FORMAT会对order_time字段做函数运算，这会导致order_time上的索引失效。如果数据量很大，更好的做法是直接在WHERE里用范围条件把月份限定好，再按月份分组；或者新建一个冗余的月份字段，方便索引查询。

聚合查询的性能问题也很典型。如果表数据量达到千万级，一次全表聚合可能耗时好几秒。这时候优化手段可以是：在查询前用更精确的WHERE缩小数据范围；或者使用覆盖索引，让查询直接走索引返回数据，避免回表；再或者对实时性要求不高的报表，提前在离线层聚合好结果，查询时直接查结果表。这个思路和热词里“分页查询慢怎么用redis优化”的逻辑一脉相承，后面我会专门讲缓存方案。

2.4 多表关联：JOIN的使用与陷阱

单表查询到一定程度，就会遇到关联查询。比如订单列表要显示用户名，光查orders表不够，需要关联users表：

sql复制SELECT o.id, o.amount, o.order_time, u.user_name
FROM orders o
INNER JOIN users u ON o.user_id = u.id
WHERE o.status = 1;

INNER JOIN只返回两边都匹配的数据。如果某个订单的user_id在users表里不存在（比如用户被物理删除但订单还在），这条订单就会被丢掉。这时候要用LEFT JOIN保留左表全部记录：

sql复制SELECT o.id, o.amount, o.order_time, u.user_name
FROM orders o
LEFT JOIN users u ON o.user_id = u.id
WHERE o.status = 1;

如果users表里找不到对应记录，u.user_name会显示为NULL。这个差异在业务上很重要，比如订单报表就绝对不能因为用户已删除而丢单。

关联查询最大的坑是忘了写JOIN条件，或者条件写错，导致笛卡尔积。比如写成FROM orders o INNER JOIN users u ON o.status = 1，这是把过滤条件当关联条件，结果会返回orders数量和users数量的乘积，数据量直接爆炸。我在排查慢SQL时，第一步经常就是检查执行计划里的rows是不是异常放大，十有八九就是关联条件有问题。

另一个常见选择是IN和EXISTS的取舍。如果子查询返回的数据量小，两个都可以；如果子查询结果集很大，用EXISTS往往更快，因为它只要找到一条匹配就停止，而IN需要先构建完整子查询结果集再比较。举个例子，查所有下过单的用户：

sql复制SELECT * FROM users u
WHERE EXISTS (
  SELECT 1 FROM orders o WHERE o.user_id = u.id
);

这里有个小技巧：EXISTS里面通常写SELECT 1，不要写SELECT *，因为EXISTS只关心是否存在，不关心具体列，写SELECT 1更清晰，也避免无意义的字段读取。

关联查询时，外键列上一定要有索引。JOIN的关联列没有索引，查询效率会急剧下降。表结构设计时，我习惯在所有外键列上建索引，这不仅方便关联查询，也方便按外键条件过滤。很多慢查询查到最后都是因为某个JOIN列没索引。

2.5 排序和分页：LIMIT/OFFSET的底层逻辑

分页查询恐怕是日常开发里出现频率最高的查询操作。典型的写法是：

sql复制SELECT id, user_id, amount, order_time
FROM orders
WHERE status = 1
ORDER BY order_time DESC
LIMIT 20 OFFSET 40;

这条查询的意思是从排序后的结果集里跳过40条，取20条。看起来没毛病，但它在数据量大了以后会变得非常慢。原因在于OFFSET的语义是“跳过前N条”，数据库必须把前N条数据都找出来，然后才能定位到目标位置。OFFSET越大，扫描的数据越多，消耗的时间越长。比如一个百万级的表，查第999980页和查第1页，性能可能相差几十倍。

很多业务场景在移动端会做“下拉加载更多”，这时候如果还用LIMIT 20 OFFSET 999980，用户翻到很深的地方就会明显感觉到卡顿。热词里提到的“分页查询慢怎么用redis优化”，其实可以参考的优化方式有很多，我放在后面的进阶章节专门讲。这里先建立一个基本认知：使用OFFSET深分页不是好方案，更优雅的是基于游标的分页，即利用上一页最后一条数据的某个排序字段值作为下一页的查询条件。

比如按order_time排序，传入上一页最后一条数据的order_time：

sql复制SELECT id, user_id, amount, order_time
FROM orders
WHERE status = 1
  AND order_time < '2024-06-01 12:00:00'
ORDER BY order_time DESC
LIMIT 20;

这种方式不管翻到多少页，每次都能利用索引定位到起始位置，性能稳定。代价是应用层需要保存上一页的最后一条数据，并且要求排序字段不存在重复值，或者至少保证排序字段的组合是唯一的。如果order_time有重复，需要用复合排序键（比如order_time + id）来保证结果稳定。这一点很多人忽略，导致分页时出现数据重复或遗漏。

3. 进阶查询场景：视图、慢查询与优化

3.1 视图过滤只显示当天：历史数据怎么查

热词里有一条非常具体的场景：“sql server视图过滤只显示当天的情况，要如何查询历史数据”。这个问题在报表系统里特别常见。有些人为了方便，直接创建一个视图，把当天数据过滤条件写死在视图里：

sql复制CREATE VIEW v_today_orders AS
SELECT id, user_id, amount, order_time
FROM orders
WHERE CONVERT(date, order_time) = CONVERT(date, GETDATE());

刚创建的时候用着挺方便，每天打开视图就是当天订单。但第二天问题就来了：昨天还能看到的数据，今天突然没了。因为视图的过滤条件跟随系统时间漂移，它永远不会显示历史数据。

理解一个核心概念：视图本质上是保存好的查询定义，不是数据快照。每次查询视图，数据库都会重新执行定义里的SQL。所以如果你希望历史数据也能查，就不应该把“当天”这个概念硬编码在视图定义里，而是让查询方通过参数传入日期范围。

好的做法是视图只负责把订单表和数据字典之类的表关联好，不限制日期，比如：

sql复制CREATE VIEW v_order_detail AS
SELECT o.id, o.user_id, o.amount, o.order_time, u.user_name
FROM orders o
LEFT JOIN users u ON o.user_id = u.id;

然后查询时可以按任意日期条件过滤：

sql复制SELECT * FROM v_order_detail
WHERE order_time >= '2024-06-01' AND order_time < '2024-06-02';

或者，如果你确实需要一个“今日视图”，可以在查询时用参数化视图（某些数据库支持表值函数），把日期作为参数传入，而不是让视图内部死锁GETDATE()。核心思想是：视图屏蔽了复杂性，但不能掩盖业务需求的变化。任何固定“当前时间”的查询都要谨慎，因为“当前时间”是一个不断变化的量，一旦视图被创建，它就会悄悄改变查询结果，让人摸不着头脑。

3.2 慢查询日志定位与索引优化

查询慢是绕不开的话题。遇到慢查询，第一步不是猜，而是看慢查询日志。以MySQL为例，可以在配置文件里开启：

ini复制slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2

这样执行时间超过2秒的查询都会被记录。拿到慢SQL后，下一步就是用EXPLAIN分析执行计划。我挑一个典型的慢查询场景。

假设我们经常查某个时间段内订单量大的用户：

sql复制SELECT user_id, COUNT(*) AS cnt
FROM orders
WHERE order_time >= '2024-01-01' AND order_time < '2024-02-01'
GROUP BY user_id
ORDER BY cnt DESC
LIMIT 10;

在orders表数据量很大的情况下，这条SQL可能会先扫描大量订单，再分组排序。执行计划里可能显示type=ALL，rows=几百万，这显然不行。优化方式是建一个联合索引(order_time, user_id)，让查询能通过索引范围扫描来定位到一月份的数据，然后再分组。分组时因为索引已经按order_time排序，但user_id不一定有序，所以还是可能用到临时表。

如果这种报表特别频繁，更极致的做法是建一个聚合表或者使用定时任务提前把每日订单聚合好。查询时直接查聚合表，避免每次都对明细表做全量扫描。这就是“空间换时间”的思路。热词里的“慢查询日志”其实提醒我们要养成定期巡检慢SQL的习惯，而不是等问题爆发了再去救火。

索引优化有几点经验。第一，不要在索引列上做函数运算，比如WHERE DATE(order_time) = '2024-06-01'会让order_time索引失效。第二，避免隐式类型转换，比如WHERE phone = 13800138000，如果phone是VARCHAR，这里数字会被转换为字符串，可能造成索引失效。第三，前导模糊查询LIKE '%张'无法走索引，而后缀模糊LIKE '张%'可以。这些都是老生常谈，但每次线上出问题都能看到类似操作。

3.3 分页查询慢怎么用Redis优化

前面提到深分页的性能问题，这里可以说是热词直接点名的一个优化方案：分页查询慢怎么用Redis优化。先明确一个前提：Redis并不能直接加速SQL，它缓存的是“查询结果”或“查询所需的关键ID列表”。对于热点数据列表，比如首页热卖商品、最新公告，这种数据量不大、并发极高、实时性要求适中的场景，完全可以把整个列表数据放到Redis里。分页时直接从Redis取，不再打数据库。

但订单这种数据量大、维度多、更新频繁的业务，直接缓存整个列表不现实。我经常用的一个优化思路是：用Redis的ZSET保存符合条件的记录ID列表。假设我们要按order_time倒序展示某用户的订单，key可以是user_orders:1001，member是订单ID，score是订单时间戳。这样分页操作就变成了在ZSET上的范围查询：

bash复制ZREVRANGE user_orders:1001 0 19

这条命令返回第一页的20个订单ID，然后再用这些ID回表查询订单详情。翻页时使用ZREVRANGE配合ZRANGEBYSCORE和WITHSCORES，就可以实现高效的游标分页，完全甩掉OFFSET深分页的包袱。

这种方案的好处是把分页排序的压力转移到了Redis内存里，ZSET底层是跳表，范围查询复杂度是O(log N)，比数据库OFFSET一次性扫描前N条数据要快得多。但需要注意几个问题。第一，Redis和数据库的一致性。订单状态随时会变化，你不能让Redis里的ID列表长期不更新。通常做法是下单、取消订单时同步更新ZSET，或者通过消息队列异步更新，做好最终一致性。第二，如果用户量巨大，每个用户都维护一个ZSET，内存开销不小。实际开发中可以做冷热分离，只给活跃用户维护ZSET，冷用户直接查数据库。第三，回表查询还是要控制量，一次取20个ID，然后WHERE id IN (...)，配合主键索引，速度很快。

还有一个思路是延迟关联，不引入Redis也能解决部分深分页问题：

sql复制SELECT o.id, o.amount, o.order_time
FROM orders o
INNER JOIN (
  SELECT id
  FROM orders
  WHERE status = 1
  ORDER BY order_time DESC
  LIMIT 100000, 20
) tmp ON o.id = tmp.id;

这个子查询只查主键，扫描的数据量首先小很多，然后再关联原表取具体字段。相比直接LIMIT 100000, 20，性能提升明显。但我的经验是，当OFFSET超过一定阈值后，延迟关联也会吃力，还是游标分页或Redis方案更靠谱。

3.4 业务代码层查询注意：MyBatis Plus逻辑删除

很多项目在ORM层面用了MyBatis Plus，它的逻辑删除功能用起来方便，但也会埋一些查询上的坑。默认情况下，如果实体类上有@TableLogic注解：

java复制@TableLogic
private Integer deleted;

那么MyBatis Plus在普通查询时会自动拼接deleted = 0条件，查不到已删除的数据。这符合多数业务需求。但有时候你想把已删除的数据也查出来做数据修复，或者做关联排查，你会发现默认API怎么都查不到。

我踩过一次坑。当时要排查一批异常订单，订单状态被标记为删除但实际金额没退，我需要把这些已删除的订单全捞出来。用MyBatis Plus的selectList死活查不到，查了一下发现是逻辑删除注解生效了。解决办法有几种。

第一，直接写自定义SQL，绕过MyBatis Plus的自动拼接逻辑。在Mapper里写原生SQL，不用框架的Wrapper：

java复制@Select("SELECT * FROM orders WHERE deleted = 1")
List<Order> selectDeletedOrders();

这种方式最直接，但要注意字段名映射。

第二，如果只在极个别场景需要临时查看，可以在配置里调整，但一般不建议全局关闭逻辑删除。更稳妥的是使用MyBatis Plus提供的@InterceptorIgnore注解，在特定方法上忽略逻辑删除插件：

java复制@InterceptorIgnore(tenantLine = "true")
@Select("SELECT * FROM orders WHERE deleted = 1")
List<Order> selectDeletedOrders();

不过这个注解的具体行为要配合你的插件版本，最好先查看源码确认。

这个问题的核心是：框架帮你做了太多事情，你得知道它在底层拼了什么SQL。任何涉及逻辑删除的项目，排查数据问题时都要先确认deleted字段的状态，否则你看到的“查无数据”可能只是被框架过滤掉了，而不是数据真的不存在。这一点也和“查询修改数据流图”之类的排查思路相关，你要把整个查询链路看清楚，才能定位到是SQL问题还是ORM问题。

4. 常见问题排查与避坑实录

4.1 IN查询语句报错：参数为空或数量过多

热词里有一条“in查询语句报错”，非常典型。最常见的就是传入的集合为空，生成的SQL变成WHERE id IN ()，这在MySQL里直接语法错误。比如Java代码里：

java复制List<Long> ids = queryIds(); // 可能是空列表
List<Order> orders = orderMapper.selectBatchIds(ids);

如果ids为空，MyBatis生成的动态SQL如果没有做空集合判断，就会报SQL语法错误。解决思路是在业务代码里先判断集合是否为空，如果为空，就不用走查询，直接返回空列表。

另一个更隐蔽的问题是IN条件元素数量过多。Oracle数据库对IN列表的数量上限是1000，超过会报ORA-01795: maximum number of expressions in a list is 1000。MySQL虽然没这么严格的上限，但列表特别长也会导致SQL解析变慢、执行计划变差。

我的建议是不要试图用一个超大IN查询解决问题。可以把大列表拆分成多个小批次，每批500个，然后多次查询，最后在应用层合并结果。或者对于Oracle，更优雅的方案是把目标ID批量插入临时表，然后JOIN临时表查询。这能避免IN上限问题，也更容易利用索引。

4.2 Timer执行查询报空指针：线程与连接池隐患

热词里有“timer执行查询是报空指针”，这个问题我在定时任务里也遇到过。典型的场景是：项目里用java.util.Timer定时执行一个数据库查询任务，运行一段时间后突然报空指针。排查下来发现，TimerTask里持有的数据库连接是从某个共享变量中获取的，而这个连接可能已经被连接池回收或关闭，定时任务执行时用的却是一个不可用的连接。

更常见的原因是对查询结果没有判空。比如某个定时任务去查当天是否有新订单，如果结果集为空，代码里直接用resultSet.getString("order_no")，自然就抛空指针。正确做法是在使用ResultSet前判断next()是否还有值，或者在ORM框架里判断返回的集合和对象是否为null。

使用Timer本身也有潜在问题。Timer是单线程调度，如果某个任务执行时间过长，会延迟后续任务，甚至抛出异常后整个Timer线程终止。我的建议是改用ScheduledExecutorService，它支持多线程，且异常处理更灵活。定时任务里的数据库操作一定要确保资源释放，用try-with-resources或者在finally里关闭连接，不然连接泄漏会让整个应用越来越慢。

做完这些基础防护后，定时查询的稳定性会大幅提升。排查这类问题最有效的方式是看完整异常堆栈，空指针不能只看表面，要往堆栈深处找是哪个变量为null、哪个资源没拿到。

4.3 Django执行查询后删除对象：ORM层误删数据

热词里有一条“django执行查询-删除对象”，虽然带“删除”，但本质上也是查询对象后的一种操作。Django的ORM删数据很方便，但误删也很方便。我见过有人这样写：

python复制Order.objects.filter(user_id=1001).delete()

如果user_id写错，或者该用户刚好有大量订单，这一句就把数据全删了。Django的delete()是立刻执行的，没有软删除概念（除非你用第三方库），所以非常危险。

正确做法分几步。第一，先查询确认影响范围：

python复制queryset = Order.objects.filter(user_id=1001)
print(queryset.count())

第二，在一个事务里执行删除，确保出错能回滚：

python复制from django.db import transaction

with transaction.atomic():
    deleted_count, _ = Order.objects.filter(user_id=1001).delete()

第三，删除后要关注外键关联。如果Order模型被其他模型通过ForeignKey引用，Django默认会级联删除关联对象，这可能不是你想要的。如果不希望级联，要在ForeignKey上设置on_delete=models.SET_NULL或PROTECT。

ORM虽然简化了查询，但它在删除这种破坏性操作上把系统底层的安全性隐藏了。我的习惯是永远在删除前做一次count确认，并且用事务包裹。即使是在生产环境，也要先备份表或开启SQL日志，做到可追溯。

4.4 pinyin4j做查询：汉字转拼音实现模糊搜索

热词里“pinyin4j做查询”是个很有趣的业务场景。有时候用户输入的是拼音缩写，比如输入“zhang”想搜索“张三”，或者输入“bj”想搜索“北京”。数据库本身不懂拼音，所以需要把汉字转成拼音，再在查询时做匹配。

一种常见做法是在数据入库时用pinyin4j生成拼音字段，比如用户表增加pinyin_full和pinyin_short两个字段。pinyin_full存全拼“zhangsan”，pinyin_short存首字母“zs”。查询时，把用户输入的关键词也用pinyin4j转成拼音或者首字母，然后去匹配对应字段。比如用户输入“zs”，就执行：

sql复制SELECT * FROM users
WHERE pinyin_short = 'zs'
OR user_name LIKE '%张%';

这里要注意pinyin4j的多音字问题。比如“重庆”的“重”读“chong”还是“zhong”，pinyin4j默认不一定正确。解决方法是针对业务常见词维护一个多音字字典，或者接受一定程度的误差。我的经验是：如果搜索场景是模糊匹配，可以先按拼音全拼精确匹配，再按首字母前缀匹配，再按汉字模糊匹配，多重结果合并后按权重排序。这样即使拼音转错了，也能靠其他路径把数据捞回来。

还有一个性能问题：拼音字段如果要支持LIKE 'z%'，需要建索引，但LIKE '%z%'会导致索引失效。所以在设计时就该想清楚，用户输入的是前缀还是包含关系。如果业务是“输入拼音缩写就能快速定位”，前缀匹配就够了。

4.5 查询总金额精度问题：避免float，用decimal

最后聊一个不算报错但比报错更麻烦的坑：金额精度。热词里有“oracle查询总金额”，如果order表里amount字段用的是FLOAT或DOUBLE类型，早晚会出事。因为二进制浮点数无法精确表示0.1这样的十进制小数，累加后会出现0.30000000000000004这种结果。哪怕单个金额看起来没问题，SUM一大票数据后，误差就会积累到不可忽视的地步。

我在Oracle里见过因为金额用NUMBER(10,2)和FLOAT混用导致对账差几分钱的案例。所以表设计阶段，金额字段必须用定点数，MySQL用DECIMAL(10,2)，Oracle用NUMBER(12,2)，SQL Server用DECIMAL(18,2)。查询聚合时也要注意COALESCE处理NULL，这点前面提过。

如果已经用了浮点类型，需要根据业务情况做迁移或者查询时转成DECIMAL再聚合。比如MySQL可以写：

sql复制SELECT SUM(CAST(amount AS DECIMAL(10,2))) AS total_amount
FROM orders
WHERE status = 1;

但这是补救措施，最好的办法还是从源头规范类型。别小看这个细节，金额相关的查询一旦出现精度问题，排查成本极高，往往要逐笔核对明细才能定位到哪条记录开始出错。

回到“基础查询示例”这个主题，我个人的体会是：查询能力高低，不在于会写几种花哨的SQL语法，而在于你是否能预判边界条件、理解执行计划、处理好NULL和精度这些底层细节。很多看起来奇怪的查询报错，最后都能归结到对基础概念的理解不到位。如果你在写查询时能时刻问自己：这条SQL执行计划是怎样的？边界条件有没有覆盖？返回类型和精度会不会有问题？那么大部分坑都能提前避开。

最后再分享一个小技巧：无论你用什么数据库，拿到一条慢SQL或者错误查询时，第一时间用EXPLAIN看执行计划，用事务包裹有风险的写操作，再用最小数据集手工执行一遍SQL。这三种动作能解决80%的查询问题。基础查询示例本身不难，难的是在真实场景里把每个细节都处理得当。希望这篇文章里的例子和经验，能让你以后再碰到类似问题时少走点弯路。