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