有史以来最差的SQL？

您见过的最糟糕的SQL查询是什么？是什么让它变得糟糕？

从中选择**

真糟糕。

当然是经典：

WHERE name = ROBERT'); DROP TABLE students;--

---

一位客户在varchar field classic ASP应用程序中存储一个由3个值组成的逗号分隔列表，因此他们的存储过程如下所示：

SELECT *
FROM
    SomeTable
WHERE
    Field LIKE @Param + ',%'
    OR
    Field LIKE '%,' + @Param + ',%'
    OR
    Field LIKE '%,' + @Param

for(int i = 0; i < query("SELECT COUNT .... WHERE ..."); i++)
{

}

---

它之所以可怕，原因应该很明显：

最近，我看到一个超过4000行的TSQL存储过程，它是一个IF语句链，用于匹配部分地址。它可以减少到少于50行

我正在为将来的DailyWTF保存代码

SELECT * FROM some_table;

让它如此糟糕的是，代码依赖于根据时间戳按顺序获得结果。在我被叫去修理它之前，它显然已经工作了一段时间

DELETE FROM table

在我输入并执行它之后，我就忘记了WHERE子句。现在，我总是先运行SELECT语句，在我确信正确的行将受到影响后，将SELECT更改为DELETE。

这可能不是最糟糕的，但我经常看到：

select * from users where clue > 0;
0 results found.

而不是：

---

我自己的，这是远远不够长的张贴在这里-关闭3500线现在

我必须用一个绝对可怕的模式来分担责任。一开始只是一个简单的练习，使用一些联合来旋转非规范化数据，结果变成了一场笨拙的噩梦。它急需修理

亚军是：

select 
case datepart(mm,getdate())
when 1 then 'Jan'
when 2 then 'Feb'
when 3 then 'March'
when 4 then 'Apr'
when 5 then 'May'
when 6 then 'Jun'
when 7 then 'July'
when 8 then 'Aug'
when 9 then 'Sept'
when 10 then 'Otc'
when 11 then 'Nov'
when 11 then 'Dec'
end

那篇文章没有打字错误——就是这样写的。谢谢你，咨询美元

我当然用selectleftdatenamemm，getdate，3重构了，大声读出来

select [select],*,star as [as] from [from],[order] order by [by] 

---

当我第一次得到目前的工作时，我的第一个项目是创建一个应用程序，总结我们计算机实验室中的许可证使用数据。他坚持说他不希望后端数据库被规范化，因为连接太昂贵了。这是我的第一个星期，我无法争辩

现在，为了从数据库中提取任何有用的数据，必须撤消每个需要提取摘要的查询中的反规范化，以删除每行中的重复数据。当然，这些是实际使用的唯一查询。您会看到许多嵌套选择，如果数据被规范化，这些选择将完全不必要，例如：

select location, sum(login_time) as total_login_time
from
    (select location, session_id, max(login_time) as login_time
     from sessions
     where location in ('lab1','lab2') 
           and session_start >= @start_date 
           and session_end <= @end_date
     group by location, session_id) tbl
group by location

尽管，查询本身并不特别难看——尽管有些查询是难看的——每次都必须跳转来撤销不必要的反规范化的过程

---

现在老板走了，但我没有时间重写它…

从某个表格中删除某个东西，从某个错误的表格中选择某个列，从正确的表格中选择某个id=某个东西

来自错误表的some\u列有一个甚至不在表中的列，但它在另一个表中。 问题是正确的_表名为“Event”，它以某种方式返回了所有行，而不是没有行，或者更重要的是，返回了一个错误

吸取的两个教训：在任何情况下，永远不要以任何形式的系统名称命名表。第二件事是首先运行select语句，然后更改为delete

---

顺便说一下，这是SQLServer2005。我仍然很生气它没有抛出错误。

在Access数据库中，有一个如下查询：

SELECT *
FROM Bad_2 INNER JOIN Bad_1 ON Bad_2.Bad_1_id = Bad_1.ID;

---

两个表都有一个同名字段。当Access第二次遇到一个字段名时，它会为它生成一个新名称。前一个家伙在代码中使用了生成的字段名。

在我的时代，看到了许多糟糕的SQL片段。 一个出现在脑海中的是形式

从文件加载数据，循环该文件，访问文件中每一行的db

在具有10条左右线路的测试系统上似乎还可以，10万-100万=即使对于主要线路也很糟糕 键查找

顺便说一句，解决方案是将数据加载到数据库中，并集中思考

-选择您最喜欢的语言，例如perl、python

将文件加载到数据结构如数组中

1。。n环 myid:=数组[n]； 从id=myid的表格中选择*； 如果行存在，请更新表集。。。其中id=myid； 端环；

SQL查询的最差使用频率：

一种SELECT查询，它统计与特定条件对应的行数，在for循环的停止条件中调用。 大概是这样的：

SELECT *
FROM
    SomeTable
WHERE
    Field LIKE @Param + ',%'
    OR
    Field LIKE '%,' + @Param + ',%'
    OR
    Field LIKE '%,' + @Param

for(int i = 0; i < query("SELECT COUNT .... WHERE ..."); i++)
{

}

不，查询的结果不会每次迭代都改变。是的，我意识到服务器将缓存结果。

在发布到新闻组中-一个真正的Informix工作表，我不建议使用：

CREATE TABLE VIEW
(
    DECIMAL     CHAR(30),
    NOT         INTEGER NOT NULL,
    SERIAL      DATE NOT NULL,
    NULL        CHAR(1) NOT NULL,
    INTEGER     DECIMAL(13,6) NOT NULL
);

---

如果您知道SERIAL是Informix数据库中的一种类型——基本上，它是一种用于连续生成自动分配的数字的类型，那么它会有一些帮助。

我喜欢dailywtf上的一种，它附带的故事也很精彩。

一种PL/SQL Oracle存储过程，它使用。这是在我和DBA被要求解决一个严重的性能问题时发现的。这位开发人员是Oracle专家，已经为它工作了一个多星期。他解释得很清楚 他在计算机科学课上学到了泡泡排序。该算法通常用于说明较差的性能

---

用订单条款取代了整个混乱局面。性能提高了几个数量级。

我认为这是最糟糕的情况，尤其是在痛苦的空回滚之后：

DROP DATABASE;
ROLLBACK;

他们显然不熟悉RTRIM

RTRIM(LastName) + ', ' + RTRIM(FirstName)

---

---

---

是的，你读对了。。。字段中以逗号分隔的字段。

为什么您对此投了反对票？太好笑了！哦，有人取消了他们的反对票。我们叫他小鲍比。这怎么算是最糟糕的？伟大不是质疑，而是名字：哎哟！那让我的牙齿痛！我在一个大型生产程序中也看到过类似的情况：有没有更好的方法来写这个？不知道BERTER这个词是否正确，但是-WHERE'、“+Field+”、“LIKE%”、“++@Param+”、“%”可能会运行得更快。当然，您不应该在RDBMS的字段中包含逗号分隔的数据。您可能希望将其设置为社区WIKI，否则会有人将其关闭。他肯定有足够的代表将自己的问题设置为WIKI。Wikify这个。强调什么是糟糕的编程实践是关于编程的，比我提到的其他一些模糊的话题更重要seen@mitch：这不是一个答案甚至有点确定的问题。相反，这是一个需要大量有效回答的问题。因此：维基。我刚刚发现了有史以来最差的帖子。哎哟。。！我是个偏执狂，我总是用begin tran/rollback来包围update/delete语句，尝试一下，然后在我觉得安全的时候执行内部部分。我做了类似的事情，只是在编写时我只是将TableName写成TableNameFOO。在我写整个电子邮件并校对之前，我还将电子邮件的“收件人”字段保留为空。。。以防万一@这是MySQL，在他们支持事务之前：伙计们。。。选择*进入z_备份作为第一步。我以前在工作时就做过这件事，幸运的是我在开发服务器上工作，我刚刚恢复了上一次工作的数据库备份。最近，我还写了一个管理员工教育状况的网页，但遗漏了where条款。假设现在每个人都有学位。选择*FROM*WHERE*='%%'；我不敢检查这是否真的有效。或者两个或两个以上较大的表之间的任何交叉连接。两个较大但较窄的表之间的交叉连接通常是匹配集的最佳解决方案。例如，多对多是一个常见问题此sql最糟糕的地方是它从不返回任何结果，无论您在哪里运行它，这就是为什么我们应该能够向上投票评论：为什么您在堆栈溢出数据库上运行此查询？它是否仍然返回0个结果？或者它只是返回用户ID 22656为什么这是糟糕的SQL？为什么玩射杀信使的游戏？打电话给我这是你会的，但我不同意作为一个规则，1是坏的，2是好的。在一个更复杂的例子中，2变得更难维护。对我来说，1的意图非常明确，因此更易于维护。2可以提供更好的性能，但收益可能不值得。此外，规则2在mysql下速度较慢。mysql-。如果将其分解并使用字符串替换来组合最终查询，则后者更易于维护。内部联接$customerTotals:d是否会有语法为2的额外联接？对于有趣的重构，可能重要，也可能不重要+1-这是一个好的观点。版本1是一个简单的SQL-92之前的查询，适合使用SQL-92连接表示法。第二个不应该更慢-它在单个表上进行分组，然后将其与原始表联接，除非优化器不对子查询结果排序，并在与客户表的合并联接中利用该顺序，在这种情况下，它可能比索引联接慢。创建一些视图来为您反规范化数据：数据这在许多级别上都是错误的。尤其是关于连接过于昂贵的评论。11映射到11月和12月？？真的吗？我们在12月发现了这颗宝石。在一个无名的工作场所，你的修复程序实际上会遭到反对，因为它破坏了9月和3月的拼写，更不用说它修复了一个错误。@Shivasubramanian:是的-Otc中有一个拼写错误；这就是要点之一。@TrickyNixon:这种解决方案的优点是它不受语言环境的影响，所以即使是法国、西班牙、德国或日本的用户也不得不使用英文缩写来表示月份名称这应该有点像甲骨文公司的一些顾问，他们并不坏到让人无法忍受，但我从未见过他们。我曾与一个团队合作，该团队的Oracle专家使用绑定到密钥的Bat文件编写了一个完整的会计程序。因此，I.bat运行发票表单，R.bat运行报告。是的，这是在90年代末。

RTRIM(LastName) + ', ' + RTRIM(FirstName)

SELECT name FROM categories WHERE id IN (".implode(",",corrected_cats($ad->id)).") ORDER BY name ASC