我有一个包含很多IF条件的SELECT查询，我可以在查询本身（使用DB机器的CPU）中执行，也可以将其放在我的java代码中（使用服务器机器的CPU）。
这里是否有任何首选方法（将DB Vs中的条件置于中间层）？
更新：我的查询是超过2个表的连接， 我正在使用左连接进行组合，并且有一些行将在第二个表中具有相应的行而一些不是。 当我在第二个表中没有相应的行时，我需要为这些列设置一些默认值。
SElECT CASE WHEN t2.col1 is null
then 'default' else t2.col1
END
FROM table1 t1
LEFT JOIN table2 t2 ON t1.id = t2.id
答案 0 :(得分：2)
如果真的是数据库无法以比应用服务器更快的速度运行，和实际上减少了数据库服务器上的负载（如果移动到应用服务器），那么我会将其移动到应用服务器。
原因是：如果达到硬件限制，拥有多个应用服务器要比拥有群集数据库容易得多。
但是，应该彻底测试上面的第二个条件：如果远离数据库，很多事情不会减少（甚至增加）DB负载。
更新：对于你需要的东西，我怀疑第一个条件是否满足 - 你测试过了吗？除非条件或分支包含一些非常昂贵的计算，否则简单的CASE是完全无关紧要的。
答案 1 :(得分：1)
是的，虽然我建议采用另一种方法，一种不会给应用服务器增加负载，也不会给DBMS带来最小负载的方法。回答这个问题有点难，因为你没有提供一个具体的例子，但我会试一试。
我的首选解决方案是尽可能完全摆脱if条件。至少，你可以重新设置数据库模式，将计算成本从select（发生很多）转移到insert/update（不常发生）。
这是正常的情况，我有看到数据库写的频率比阅读更频繁，但它们是例外而不是规则。
举例来说，假设您存储了人员信息，并希望获得名字长度超过5个字符的人员列表。不要问为什么，我是顾客，你必须给我我想要的东西： - ）
而不是一个怪异的select语句（可能）拆分名称并计算其中的字符，当数据进入表时，将其作为插入/更新触发器 - 即 >毕竟价值可以改变的唯一时间。
将该计算放入另一列（已编制索引）并在您的选择中使用该列。计算的成本在选择上摊销，这将是非常快的。
它将占用更多的存储空间但是，如果你比较数据库的数量“我怎样才能让它更快？”对“如何使用更少的空间？”的数量提出疑问？问题，你会发现前者大大超过后者。
而且，是的，它确实意味着您存储冗余数据，但触发器可以减少丢失ACID属性的可能性。如果您知道可能的后果以及如何最好地避免它们，那么可以弯曲规则。
根据您的更新，您应该将工作负载放在影响最小的计算机上。这可能是DBMS，它可能是应用服务器，它甚至可能位于客户端（应用服务器）本身，因为这会将成本分配到很多机器而不是集中在一个点上。
你应该测量，而不是猜测！设置真实的性能测试系统以及逼真的生产质量数据，然后尝试不同的方法。这是唯一可以确定的真正的方式。