数据库limit的作用+句子用于对查询结果进行分组输出？

来源：蜘蛛抓取(WebSpider) 时间：2022-11-19 06:56 标签： 数据库limit的作用

摘要 方式1：select * from table order by id limit m, n;很简单，该语句的意思就是查询m+n条记录，去掉前m条，返回后n条。无疑该查询能够实现分页，但m越大，查询性能就越低，因为MySQL需要扫描全部m+n条记录。

方式1：select * from table order by id limit m, n;很简单，该语句的意思就是查询m+n条记录，去掉前m条，返回后n条。无疑该查询能够实现分页，但m越大，查询性能就越低，因为MySQL需要扫描全部m+n条记录。

上传文件时，要获取上传文件的原名，使用哪个数组元素？

请编程PHP程序，统计用户输入的英文句子中有多少个单词并输出。假设用户输入的英文句子的内容通过$_POST['str’]可以获取

显然是个很糟糕但又很无奈的体验，数据分析领域的 SQL 通常是数百行甚至数千行的，过两月自己都看不懂。为这种巨大 SQL 头疼的人不在少数，为什么会这样？

发明 SQL 的初衷之一显然是为了降低人们实施数据查询计算的难度。SQL 中用了不少类英语的词汇和语法，这是希望非技术人员也能掌握。确实，简单的 SQL 可以当作英语阅读，即使没有经验的人也能运用。

然而，面对稍稍复杂的查询计算需求，SQL 就会显得力不从心，经常写出几百行有多层嵌套的语句。这种 SQL，不要说非技术人员难以完成，即使对于专业程序员也不是件容易的事，常常成为很多软件企业应聘考试的重头戏。三行五行的 SQL 仅存在教科书和培训班，现实中用于报表查询的 SQL 通常是以“K”计的。

SQL 困难的分析探讨

这是为什么呢？我们通过一个很简单的例子来考察 SQL 在计算方面的缺点。

设有一个由三个字段构成的销售业绩表（为了简化问题，省去日期信息）：

销售员姓名，假定无重名
该销售员在该产品上的销售额

现在我们想知道出空调和电视销售额都在前 10 名的销售员名单。

这个问题并不难，人们会很自然地设计出如下计算过程：

1． 按空调销售额排序，找出前 10 名；

2． 按电视销售额排序，找出前 10 名；

3． 对 1、2 的结果取交集，得到答案；

我们现在来用 SQL 做。

1． 找出空调销售额前 10 名，还算简单：

2． 找出电视销售额前 10 名。动作一样：

3． 求 1、2 的交集。这有点麻烦，SQL 不支持步骤化，上两步的计算结果无法保存，只能再重抄一遍了:

一个只三步的简单计算用 SQL 要写成这样，而日常计算中多达十几步的比比皆是，这显然超出来许多人的可接受能力。

我们知道了 SQL 的第一个重要缺点：不支持步骤化。把复杂的计算分步可以在很大程度地降低问题的难度，反过来，把多步计算汇成一步则很大程度地提高了问题的难度。

可以想象，如果老师要求小学生做应用题时只能列一个算式完成，小朋友们会多么苦恼（当然，不乏一些聪明孩子搞得定）。

SQL 查询不能分步，但用 SQL 写出的存储过程可以分步，那么用存储过程是否可以方便地解决这个问题呢？

暂先不管使用存储过程的技术环境有多麻烦和数据库的差异性造成的不兼容，我们只从理论上来看用分步 SQL 是否能让这个计算更简单捷些。

1． 计算空调销售额前 10 名。语句还是那样，但我们需要把结果存起来供第 3 步用，而 SQL 中只能用表存储集合数据，这样我们要建一个临时表：

2． 计算电视销售额前 10 名。类似地

3． 求交集，前面麻烦了，这步就简单些

分步后思路变清晰了，但临时表的使用仍然繁琐。在批量结构化数据计算中，作为中间结果的临时集合是相当普遍的，如果都建立临时表来存储，运算效率低，代码也不直观。

而且，SQL 不允许某个字段取值是集合（即临时表），这样，有些计算即使容忍了繁琐也做不到。

如果我们把问题改为计算所有产品销售额都在前 10 名的销售员，试想一下应当如何计算，延用上述的思路很容易想到：

1． 将数据按产品分组，将每组排序，取出前 10 名；

2． 将所有的前 10 名取交集；

由于我们事先不知道会有多个产品，这样需要把分组结果也存储在一个临时表中，而这个表有个字段要存储对应的分组成员，这是 SQL 不支持的，办法就行不通了。

如果有窗口函数的支持，可以转换思路，按产品分组后，计算每个销售员在所有分组的前 10 名中出现的次数，若与产品总数相同，则表示该销售员在所有产品销售额中均在前 10 名内。

这样的 SQL，有多少人会写呢？

况且，窗口函数在有些数据库中还不支持。那么，就只能用存储过程写循环依次计算每个产品的前 10 名，与上一次结果做交集。这个过程比用高级语言编写程序并不简单多少，而且仍然要面对临时表的繁琐。

现在，我们知道了 SQL 的第二个重要缺点：集合化不彻底。虽然 SQL 有集合概念，但并未把集合作为一种基础数据类型提供，这使得大量集合运算在思维和书写时都需要绕路。

我们在上面的计算中使用了关键字 top，事实上关系代数理论中没有这个东西（它可以被别的计算组合出来），这不是 SQL 的标准写法。

我们来看一下没有 top 时找前 10 名会有多困难？

大体思路是这样：找出比自己大的成员个数作为是名次，然后取出名次不超过 10 的成员，写出的 SQL 如下：

没有对象引用机制和彻底集合化的 SQL，也不能将子表作主表的属性（字段值）处理。针对子表的查询要么使用多表连接，增加语句的复杂度，还要将结果集用过滤或分组转成与主表记录一一对应的情况（连接后的记录与子表一一对应）；要么采用子查询，每次临时计算出与主表记录相关的子表记录子集，增加整体计算量（子查询不能用 with 子句了）和书写繁琐度。

问题说完，该说解决方案了。

其实在分析问题时也就一定程度地指明了解决方案，重新设计计算语言，克服掉 SQL 的这几个难点，问题也就解决了。

这就是发明 SPL 的初衷！

SPL 是个开源的程序语言，其全名是 Structured Process Language，和 SQL 只差一个词。目的在于更好的解决结构化数据的运算。SPL 中强调了步骤化、支持有序集合和对象引用机制、从而得到彻底的集合化，这些都会大幅降低前面说的“解法翻译”难度。

这里的篇幅不合适详细介绍 SPL 了，我们只把上一节中的 8 个例子的 SPL 代码罗列出来感受一下：

SPL 可以保持记录集合用作中间变量，可逐步执行递进查询。

有步骤和程序逻辑支持的 SPL 能很自然地逐步完成结果。

对于以有序集合为基础的 SPL 来说，按位置取值是个很简单的任务。

SPL 按自然的思路过程编写计算代码即可。

SPL 可以保存分组结果集，继续处理就和常规集合一样。

使用 SPL 只要按思路过程写出计算代码即可。

支持对象引用的 SPL 可以简单地将外键指向记录的字段当作自己的属性访问。

SPL 支持将子表集合作为主表字段，就如同访问其它字段一样，子表无需重复计算。

SPL 有直观的 IDE，提供了方便的调试功能，可以单步跟踪代码，进一步降低代码的编写复杂度。

对于应用程序中的计算，SPL 提供了标准的 JDBC 驱动，可以像 SQL 一样集成到 Java 应用程序中：

我要回帖

更多关于 数据库limit的作用 的文章

 

随机推荐