我们有一个Web应用程序，用户可以根据输入的参数执行即席查询。我还可以提到响应时间对用户来说非常重要。
网页根据输入的参数动态构造要执行的SQL。例如，如果用户为“业务单位”输入“1”，我们构造一个这样的SQL：
SELECT * FROM FACT WHERE
BUSINESS_UNIT = '1'
--AND other criteria based on the input params
我发现在用户未指定BUSINESS_UNIT的情况下，构建了以下查询
SELECT * FROM FACT WHERE
BUSINESS_UNIT LIKE '%'
--AND other criteria based on the input params
恕我直言，这是不必要的（如果不是非常低效），并且保证发送代码不好修改，但由于我发送代码的返回率比其他代码高得多，我相信我可能会赢得声誉“太挑剔了。”
如果这是一个不恰当的问题，因为它不是直接编码Q，请告诉我，我会立即将其删除。我很困惑这样的主观问题是否被允许！我会看你的回复。
TY
更新
我正在使用Oracle数据库。
我的印象是Oracle没有通过删除条件来优化“LIKE'％'”并且将其保留在效率较低的情况下。有人可以证实吗？
答案 0 :(得分：14)
两个查询完全不同（从结果集的角度来看）
SELECT * FROM FACT;
和
SELECT * FROM FACT WHERE
BUSINESS_UNIT LIKE '%';
第一个将返回所有行，第二个，如果有NULL个值，则不会返回这些行，因为与NULL相比的任何内容都是NULL，因此不满足谓词。这就是Oracle的工作方式。
答案 1 :(得分：9)
虽然这看起来非常低效，但我只是在SQL Server中对其进行了测试，并且查询优化器非常智能，可以将其过滤掉。
换句话说，
SELECT * FROM FACT WHERE
BUSINESS_UNIT LIKE '%'
和
SELECT * FROM FACT
生成完全相同的查询计划。所以不应该有性能差异（我猜你的数据库引擎取决于它），虽然它确实看起来很邋..
这可能会影响您将其发回的决定。我个人可能会，但如果你已经在云下，那么你可以放松一下，至少在性能方面。
答案 2 :(得分：2)
使用BUSINESS_UNIT LIKE '%'的查询看起来效率不高 - 我想它会强制对表格进行全面扫描......
所以，是的，我会尝试重新设计该查询，以适当的方式处理这种情况 - 或者，至少我会通过我们的错误跟踪器报告该问题 （不确定我会分配的优先级，但是，仍然会在某处记录问题，有人会在某天没有更高优先级的问题处理时纠正它）。< / p>
答案 3 :(得分：2)
SELECT *是一个红旗。指定查询的列列表。
答案 4 :(得分：1)
我会把它寄回去，我喜欢这个问题。
所有代码审查在某种程度上都是主观的。标准应基于许多因素。
是否有效。
是否符合对性能，可维护性，可用性和可扩展性的合理期望
虽然我没有测试过这个特定的构造 - 我怀疑（就像你一样）这段代码会给你的SQL服务器做些可怕的事情。因此，性能和可扩展性受到质疑。
答案 5 :(得分：1)
作者想要一个虚拟陈述，以便他/她可以将“和”附加到所有后续陈述中。将其更改为更好的“无操作”语句，例如1 == 1会有所帮助。或者他们可以做更多的工作并智能地插入“在哪里”。
答案 6 :(得分：1)
我会质疑为什么没有使用绑定变量（除非在特定情况下有充分的理由）：
SELECT * FROM FACT WHERE
BUSINESS_UNIT = '1'
为什么不是：
SELECT * FROM FACT WHERE
BUSINESS_UNIT = :bu