Java开发里那些数据库语句，真心得会用才行，不然项目写不下去

知乎高赞回答《Java开发，数据库不会真不行》）
Java开发里，数据库操作是绕不开的活儿，你要是觉得光把Java语法学明白就能做项目，那大概率项目做到一半就得卡壳，很多新手以为用MyBatis或JPA这种框架之后，就不用碰SQL了，结果遇到复杂业务直接傻眼，下面这些数据库语句和概念，要是不会，项目真可能写不下去。

连表查询（JOIN）必须熟练
（来源：掘金专栏《Java后端常见面试题》）
实际项目里数据都在不同的表里放着，比如用户信息在user表，订单在order表，你要查“某个用户的最近3个订单地址”，光靠单表查询得先查用户ID，再循环查订单，效率极低，这时候就得用JOIN：

SELECT u.name, o.order_date, o.address  
FROM user u  
LEFT JOIN order o ON u.id = o.user_id  
WHERE u.id = 1  
ORDER BY o.order_date DESC  
LIMIT 3;  

左连接（LEFT JOIN）、内连接（INNER JOIN）的区别得搞懂，比如左连接即使右表没数据也会返回左表记录，内连接只返回两边都有的数据，曾有个同事用错连接类型，导致统计报表漏数据，被测试揪出来返工。

分组统计（GROUP BY）和过滤（HAVING）
（来源：CSDN博主《SQL实战避坑指南》）
比如要统计“每个部门薪资超过5000的员工人数”，很多人会写成：

SELECT department, COUNT(*) FROM employee WHERE salary > 5000;  

这实际上会漏掉所有部门！正确做法得用GROUP BY分组，再用HAVING对分组后数据过滤：

SELECT department, COUNT(*)  
FROM employee  
WHERE salary > 5000  
GROUP BY department  
HAVING COUNT(*) > 2;  -- 只显示人数超过2人的部门  

WHERE和HAVING的区别是关键：WHERE在分组前过滤单条数据，HAVING在分组后过滤整个组。

子查询和EXISTS的灵活使用
（来源：开源项目文档《企业级Java开发规范》）
有时候需要“查存在订单的用户名单”，用IN子查询虽然简单：

SELECT name FROM user WHERE id IN (SELECT user_id FROM order);  

但数据量大时效率低，改用EXISTS会更高效：

SELECT name FROM user u  
WHERE EXISTS (SELECT 1 FROM order o WHERE o.user_id = u.id);  

因为EXISTS一旦找到匹配就停止扫描，而IN会遍历所有结果，曾有个系统因滥用IN导致数据库卡死，改成EXISTS后查询时间从10秒降到0.1秒。

事务控制（BEGIN/COMMIT/ROLLBACK）
（来源：阿里技术博客《分布式事务实践》）
Java中用@Transactional注解挺方便，但如果不理解底层原理，可能出bug，比如转账场景：

BEGIN TRANSACTION;  
UPDATE account SET balance = balance - 100 WHERE user_id = 1;  
UPDATE account SET balance = balance + 100 WHERE user_id = 2;  
COMMIT;  

如果第二条SQL执行失败，必须ROLLBACK回滚，否则用户1的钱扣了但用户2没收到，框架不会自动处理所有异常，比如非受检异常（如空指针）可能导致事务未回滚，得手动配置。

索引优化相关的语句
（来源：美团技术团队《MySQL索引设计原则》）
慢查询多是索引没用好，比如模糊查询LIKE '%关键字%'无法用索引，但LIKE '关键字%'可以，通过EXPLAIN分析执行计划是基本功：

EXPLAIN SELECT * FROM product WHERE name LIKE '手机%';  

结果中的“type”字段如果是index或range说明用了索引，如果是ALL就是全表扫描，有个项目因未给status字段加索引，页面加载超时，加上索引后从2秒变50毫秒。

分页查询的写法
（来源：GitHub热门仓库《Java开发手册》）
前端列表几乎都要分页，但LIMIT在大数据量时可能变慢：

SELECT * FROM log ORDER BY id LIMIT 1000000, 10;  

跳过100万条记录很耗资源，优化方法是改用条件查询：

SELECT * FROM log WHERE id > 1000000 ORDER BY id LIMIT 10;  

这需要前端记录上次查询的最大ID，一次大促活动时，某系统因分页过深导致数据库CPU飙高，临时改成条件分页才缓解。

数据备份与锁表语句
（来源：运维经验总结《生产环境SQL操作禁忌》）
偶尔要手动改生产数据，比如批量修改用户状态：

LOCK TABLES user WRITE;  -- 锁表防止并发修改  
UPDATE user SET status = 0 WHERE last_login < '2020-01-01';  
UNLOCK TABLES;  

不懂锁表可能造成数据不一致，有次运营误操作同时跑两个批量脚本，导致部分用户状态被覆盖，最后只能从备份恢复。

（来源：个人项目踩坑记录）
框架再强大，归根结底还是在生成SQL，复杂业务如报表统计、多条件筛选，往往要手写SQL，不会这些语句，轻则性能低下，重则数据错乱，尤其是面试时，数据库知识必问，光会SELECT *根本不够看。