我想用大量数据填充一些表，以便在最坏的情况下（尽可能接近它）凭经验测试 SQL 查询的性能。
我考虑使用随机值。但这需要手动调整才能接近最坏的情况。不受约束的随机值对于最坏的情况是不利的，因为它们往往大多是唯一的——在这种情况下，单个列上的索引应该与复合索引一样好。另一方面，从太小的集合中选择的随机值将导致返回大部分行，这并不有趣，因为它反映的与其说是搜索性能，不如说是列表性能。
我也考虑过只看解释计划，但这不是经验性的，而且解释也各不相同，部分取决于你已经拥有的数据，而不是最坏的情况。
是否有一种工具可以分析给定的SQL查询（以及数据库模式，理想情况下的索引），然后生成一个大型数据集（给定大小），从而使查询执行尽可能接近最坏情况？
任何RDBMS都可以。
我也对获得这种程度的对最坏情况行为的洞察力的替代方法感兴趣。
简短回答：没有最坏的情况，因为每种情况都可能变得更糟，通常只需添加更多具有相同分布的数据即可。
长答案：
我建议您不要寻找最坏的情况，而是寻找"夸张的现实场景"，其中您从生产数据开始，定义您认为的大量实体（分别针对每个表），乘以两或三倍，然后从您手动拥有的生产数据中生成数据。
例如，如果您的生产数据包含来自 150 家汽车制造商的 1000 种车型，并且您决定可能需要来自 300 家制造商的 10000 种车型，则首先将引用表中的记录数加倍（制造商），然后生成现有 1000 种汽车模型的"副本"，以创建引用这些生成的制造商的另外 1000 辆汽车， 然后每辆现有汽车再生成 4 辆汽车，每次都根据具体情况决定复制现有的值分布。 这意味着某些列中有新的唯一值，而其他列中只是复制了值。
完成后不要忘记重新生成统计信息。 我到底为什么这么说？ 因为您希望在给定查询、数据和架构的情况下测试最佳查询计划，并对其进行优化。
理由：查询不是算法。 查询优化器不仅根据查询来选择合适的查询计划，而且还根据有关表大致大小、索引覆盖率、运算符选择性等的信息来选择合适的查询计划。 你对了解选择不当的计划或针对不切实际填充的数据库的计划是如何执行的并不真正感兴趣的。 这甚至可能导致您添加选择不当的索引，而选择不当的索引会使生产性能变差。 您希望了解并测试使用实际（尽管大量行）的最佳计划会发生什么情况。
虽然您可以使用 1,000,000 个汽车模型进行测试，但此类生产内容很可能是针对您的特定数据库架构和查询的科幻小说。 但是，使用与数据库中的汽车制造商数量相等的车型数量进行测试将更加无用。 虽然这样的分布可能恰好是应用程序最糟糕的分布，但基于它的指标几乎不会学到任何东西。