怎么给Mapper里的SQL动刀子优化，别光写死了慢查询的事儿

要给Mapper里的SQL动刀子优化，不能只盯着那些已经慢到不行的查询，那都是事后救火，真正的功夫在于平时设计和编码时，就埋下优化的种子，这就像健身，不能等胖得走不动路了才去跑步,而是要把健康饮食和锻炼融入日常生活。

第一刀：从设计源头就“砍”掉多余的数据

很多时候，SQL慢是因为它太“贪心”了，拿回了远超需要的数据量，这就像你去超市只想买瓶水，结果推了个大购物车，把整个超市都逛了一遍,结账时自然慢。

• *核心技巧：拒绝 `SELECT **，这是最经典也最容易被忽视的一点，来源中普遍强调，一定要明确列出需要的字段，你只需要用户的姓名和手机号，那就写SELECT username, phone FROM user，而不是SELECT *，好处是巨大的：网络传输的数据量小了，速度更快；如果表里有textblob`这类大字段，不查询它们能极大减轻数据库和应用的负担；当表结构发生变化（比如增加了新字段），你的查询结果也不会受到影响,代码更健壮。
• 进阶技巧：关联查询时更要“精打细算”，在多表关联时，要检查SELECT后面跟着的字段，是不是每个都是必需的，我们习惯性地把关联表的所有字段都选出来，但其实业务逻辑可能只用其中一两个，只取所需,是减少数据量的不二法门。

第二刀：给查询条件加上“精准的导航”

你的SQL要去数据库这片浩瀚的数据海洋里捞针，如果没有明确的指引，它就只能进行全表扫描，也就是一条条记录去比对，这无疑是最慢的方式，索引就是那个“精准的导航”。

• 核心技巧：为高频查询条件建立索引反复提到，WHERE子句和ORDER BY子句中的字段，是创建索引的首要候选目标，你经常按“创建时间”倒序查询订单，那就在create_time字段上建个索引，经常用“用户ID”来查数据，就给user_id建索引。
• 避坑技巧：小心索引失效，不是建了索引就万事大吉，错误的写法会让索引失效，常见的坑有：
  • 对索引列进行运算或函数操作：WHERE YEAR(create_time) = 2023，即使create_time有索引，数据库也无法利用，应该写成 WHERE create_time >= '2023-01-01' AND create_time < '2024-01-01'。
  • 使用左模糊或全模糊查询：LIKE '%关键字' 或 LIKE '%关键字%' 会导致索引失效，而 LIKE '关键字%' 通常可以使用索引。
  • 使用不等于条件： 或 <> 往往会导致全表扫描。

第三刀：重构连接，避免“笛卡尔积”灾难

多表关联查询（JOIN）是性能问题的重灾区，写得不好，数据量会呈指数级增长,严重拖慢查询。

• 核心技巧：先用小表驱动大表，来源中有观点指出，在关联查询时，要尽量让数据量小的表作为驱动表（即FROM后面的主表），去关联数据量大的表，因为数据库通常是先遍历驱动表，再用驱动表的结果去匹配被驱动表的数据，小表驱动大表,匹配的次数就少。
• 核心技巧：确保关联字段上有索引，这是JOIN优化的铁律。ON后面的关联条件，必须在两个表的对应字段上都有索引，否则每次关联都是一次小型的全表扫描,性能极差。
• 进阶思路：考虑拆分成多个简单查询，这不是说JOIN不好，而是有时候，一个非常复杂的、关联了七八个表的SQL，可能不如拆分成两三个简单的SQL，在Java业务代码里进行数据组装，这样做的好处是，每个SQL都简单明了，易于理解和优化，而且可以利用应用层的缓存，虽然可能会增加一点网络开销,但避免了单条复杂SQL可能带来的数据库锁竞争和执行计划不可控的风险。

第四刀：告别“一锅烩”，学会分而治之

当数据量达到百万、千万级别时，即使有索引，一些查询也可能变得缓慢,这时就要考虑更宏观的优化策略。

• 核心技巧：分库分表，这是来源中提到的应对海量数据的终极手段之一，当单张表的数据太大，索引的深度也会变深，查询效率下降，分表就是把一张大表按某种规则（比如用户ID哈希、按时间范围）拆分成多张物理小表，分库则是将表分布到不同的数据库实例上，从而分散读写压力，这需要对业务有深刻的理解,选择合适的分片键。
• 核心技巧：读写分离，大部分业务场景都是“读多写少”，读写分离就是在主数据库（负责写操作）基础上，挂载多个从数据库（负责读操作），通过数据同步机制保持主从数据一致，这样就将读请求分摊到了多个数据库上,极大提升了系统的整体读性能和处理能力。

第五刀：利用数据库的“预编译”能力

• 核心技巧：使用预编译语句（PreparedStatement），这在MyBatis中是默认开启的，它不仅能防止SQL注入，更重要的是，同一条SQL（参数不同）只需要在数据库端编译一次，后续直接执行即可，省去了重复解析和生成执行计划的开销,对高频查询性能提升明显。

给Mapper里的SQL动刀子优化，是一个贯穿始终的、需要深度思考的过程，它要求我们不仅要懂SQL语法，还要懂数据库的工作原理（比如索引）、懂业务的数据模型和访问模式，从写出第一行SQL代码开始，心里就要有性能这根弦，通过精细化的数据索取、合理的索引设计、聪明的关联方式和宏观的架构调整，才能真正让数据库飞起来,而不是等到慢查询日志爆表时才手忙脚乱。