读书笔记：**为什么你总把简单问题复杂化？**

我们的文章会在微信公众号IT民工的龙马人生和博客网站( www.htz.pw )同步更新 ，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！
由于博客中有大量代码，通过页面浏览效果更佳。

本文为个人学习《Expert Oracle Database Architecture Techniques and Solutions for High Performance and Productivity（第四版本》一书过程中的笔记与理解分享，仅用于学习与交流，部分内容参考原书观点并结合>实际经验进行整理。若涉及版权问题，请联系删除或沟通处理。也请大家支持购买原版书籍。

为什么你总把简单问题复杂化？

你有没有遇到过这种情况：明明可以用一行代码解决的问题，却写了几百行？或者花了好几天折腾一个功能，最后发现数据库早就内置了这个功能？

这不是因为你不够聪明，而是因为你可能没摸透手里的工具。

案例1：限制用户只能登录一次

很多系统想实现“一个用户只能同时登录一次”的功能，于是开发者们各显神通：

• 写脚本定时扫描数据库会话，发现重复登录就强制踢人
• 建一张表记录用户登录状态，退出时删记录（但如果程序崩溃，记录没删掉，用户就再也登不进去了）
• 甚至有人写了个后台服务专门管这事……

但其实，Oracle 早就内置了这个功能，一行 SQL 就能搞定：

-- 创建一个限制单会话的配置文件
CREATE PROFILE one_session LIMIT SESSIONS_PER_USER 1;

-- 把这个配置分配给用户
ALTER USER scott PROFILE one_session;

搞定！现在用户 scott 如果尝试同时登录两次，第二次就会直接报错：

ORA-02391: 超出单会话限制

——不用写代码，不用维护额外表，数据库自己就管好了。

案例2：统计不同粒度的数据

有些开发者需要从主表和子表汇总数据，但不知道 SQL 能直接处理，于是：

• 在代码里写循环，一条条查数据再拼结果
• 搞个中间层处理聚合逻辑，性能慢还难维护

其实 SQL 早就支持高级聚合，比如：

-- 方法1：内联视图（先聚合再关联）
SELECT p.id, c1_sum, c2_sum
FROM parent p,
     (SELECT id, SUM(value) c1_sum FROM child1 GROUP BY id) c1,
     (SELECT id, SUM(value) c2_sum FROM child2 GROUP BY id) c2
WHERE p.id = c1.id AND p.id = c2.id;

-- 方法2：标量子查询（逐行计算）
SELECT p.id,
       (SELECT SUM(value) FROM child1 WHERE id = p.id) c1_sum,
       (SELECT SUM(value) FROM child2 WHERE id = p.id) c2_sum
FROM parent p;

-- 方法3：WITH 子句（先定义临时结果集）
WITH 
c1_sum AS (SELECT id, SUM(value) sum FROM child1 GROUP BY id),
c2_sum AS (SELECT id, SUM(value) sum FROM child2 GROUP BY id)
SELECT p.id, c1.sum AS c1_sum, c2.sum AS c2_sum
FROM parent p, c1_sum c1, c2_sum c2
WHERE p.id = c1.id AND p.id = c2.id;

数据库自己就能高效处理聚合，何必在代码里折腾？

为什么我们总把问题搞复杂？

1. “我不知道还能这样”

   • 很多开发者只熟悉自己常用的功能，没深入研究数据库的完整能力。
   • 解决方案：抽空翻翻官方文档，你会发现很多“隐藏技能”。

2. “别人都这么写”

   • 团队里如果大家都用笨办法，新人也会跟着学，没人质疑“有没有更简单的方式？”
   • 解决方案：定期做技术分享，互相学习高效写法。

3. “复杂=高级？”

   • 有些人觉得用越多的技术栈（微服务、中间件、消息队列……）越显得厉害，但简单稳定才是王道。
   • 解决方案：先问“真的需要这么复杂吗？”，能用存储过程解决的问题，就别拉上 Java + Redis + Kafka。

简单 ≠ 低级，高效才是王道

• 小项目别上大架构：如果你只是做个个人博客，用 PHP + MySQL 就够了，没必要上 Kubernetes + React + 微服务。
• 数据库比你想象的强大：事务、聚合、约束、调度……很多业务逻辑直接写在数据库里更高效。
• 少写代码 = 少出 Bug：每多一行代码，就多一个出错的可能。能用数据库约束解决的，就别写业务逻辑校验。

下次写代码前，先问问自己：
❌ “我要怎么实现这个功能？”
✅ “数据库能不能直接帮我搞定？”

你会发现，很多问题早就有更优雅的解决方案，只是你还没发现而已。

------------------作者介绍-----------------------
姓名：黄廷忠
现就职：Oracle中国高级服务团队
曾就职：OceanBase、云和恩墨、东方龙马等
电话、微信、QQ：18081072613
个人博客: (http://www.htz.pw)
CSDN地址: (https://blog.csdn.net/wwwhtzpw)
博客园地址: (https://www.cnblogs.com/www-htz-pw)