1. 无限长的结果集是导致响应缓慢的常见原因
1.1. 当违反稳态模式时，就可能产生无限长的结果集
1.2. 当调用方允许另一个系统支配调用时，就会出现一个无限长的结果集
2. 数据库突然返回500万行，而不是通常的100多行时会发生什么？
2.1. 在用户失去兴趣后的很长时间内，还在一个while循环中打转
2.2. 除非应用程序明确限制了其可以处理的结果数量，否则系统就可能会耗尽内存
3. 早期的社交媒体网站假定每个用户的连接数量将会呈现钟形曲线一样的分布，但事实上是一个幂律分布
3.1. 如果使用钟形曲线分布式关系进行测试，则永远不会期望能加载一个其关系数量比平均值多几百万倍的实体
3.2. 但是当使用幂律分布时，肯定会出现这种情况
4. 某表从不会超过1000行，但DBA发现，它位于最大系统开销查询列表之首
4.1. 高CPU使用率看起来像是垃圾回收造成的
4.2. 这个通常很小的表，当时竟然拥有超过1000万行的记录
4.2.1. 由于在开发过程中的数据集往往很小，因此应用程序开发工程师可能永远不会体验到这样的负面后果
4.3. 避免这台应用程序服务器查询中缺少LIMIT子句所造成的灾难
4.4. sql
-- Microsoft SQL Server
SELECT TOP 15 colspec FROM tablespec
-- Oracle（since 8i）
SELECT colspec FROM tablespec
WHERE rownum ＜= 15
-- MySQL and PostgreSQL
SELECT colspec FROM tablespec
LIMIT 155. 解决方案
5.1. 在所有API或协议中，调用方应该始终指出准备接受的响应数目
5.2. 注意所有可能会累积无限子记录的数据库关系
5.2.1. 标准的SQL语法限定结果集的大小
5.3. 可以先对完整的结果集进行查询，但在达到最大行数后，就跳出处理循环
5.3.1. 给应用程序服务器提供一些额外的稳定性，但代价是浪费了数据库的系统容量
5.4. 使用切合实际的数据量
5.5. 在前端发送分页请求
5.6. 不要依赖数据生产者
5.6.1. 由于系统某个其他部分的作用，这个数量可能会在没有警告的情况下发生变化
5.6.2. 合理的数量只能是“零”“一”和“许多”
5.6.3. 除非单单查询某一行，否则就有可能返回太多结果
5.6.4. 要想对创建的数据量加以限制，不要依赖数据生产者
5.7. 在其他应用程序级别的协议中使用返回数量限制机制
5.7.1. 服务调用、RMI、DCOM、XML-RPC以及任何其他类型的请求-回复调用，都容易返回巨量的对象，从而消耗太多内存
