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