我一直听说 SQL 表的“正确”索引是性能的关键。我从未见过这样的真实示例，并且想使用SQLFiddle制作一个示例，但不确定 SQL 语法是否可以这样做。
假设我有 3 张桌子： 1) Users2) Comments3) Items。我们还假设任何用户都可以评论每个项目。因此，要获得 item=3 的评论，SQLSELECT将如下所示：
SELECT * from comments join users on comments.commenter_id=users.user_id
WHERE comments.item_id=3
我听说一般来说，如果行数变大，即数千/数百万，则应该在 theWHERE和JOINed 列上放置索引。所以在这种情况下，comments.item_id、comments.commenter_id和users.user_id。
我想制作一个SQLFiddle来比较将这些表编入索引与每个表不使用数千、数百万行。有人可以帮助生成这个 SQLFiddle 吗？
我是 SQL Fiddle 的所有者。它绝对不是为性能测试生成巨大数据库的地方。有太多其他变量是您无法控制的（但在现实生活中应该），例如内存、硬盘配置等。此外，作为共享环境，还有其他人使用它可以也会影响您的测试。话虽如此，您仍然可以在 sqlfiddle 中构建一个小型数据库，然后查看带和不带索引的查询的执行计划。无论其他环境因素如何，这些都将保持一致，并将成为学习优化的良好来源。
索引一个表有很多不同的方法，您可能会根据最常用的 SELECT 语句选择不同的索引多个表。两种基本类型的索引称为集群索引和非集群索引。
聚集索引存储索引本身的所有信息，而不是存储数据库可以从中提取然后用于查找实际数据的引用列表。可视化这一点的最简单方法是将索引和表本身视为单独的对象。在聚集索引中，如果您索引的列用作标准（在 WHERE 子句中），则查询提取的信息将直接从索引中提取，而不是从表中提取。
另一方面，非聚集索引更像是一个参考表。它告诉查询它所请求的实际信息存储在表对象本身的什么位置。因此，本质上，当您使用非聚集索引时，实际上需要从表本身中检索数据的额外步骤。
聚集索引按顺序将数据物理存储在硬盘上，因此，一张表上只能有一个聚集索引（因为我们只能在磁盘驱动器上以一种“物理”方式存储表） . 聚集索引也需要是唯一的（尽管肉眼可能不是这样，但数据库本身总是如此）。因此，大多数聚集索引都放在主键上（因为大多数主键都是唯一的）。
与聚集索引不同，您可以在一个表上拥有任意数量的非聚集索引，因为毕竟它们只是实际表本身的参考表。由于我们对非聚集索引的选项数量基本上是无限的，因此用户喜欢根据需要在 SELECT 语句的 WHERE 子句中常用的列上放置尽可能多的选项。
但像所有事情一样，过度并不总是好的。您在表上放置的索引越多，该表上的“开销”就越多。索引可能会加快您的查询运行速度，但过多的开销也会减慢它们的速度。关键是在针对您的特定情况的索引过多和索引不足之间找到平衡点。
至于测试带或不带索引的查询性能的好地方，我建议使用 SQL Server。SQL Server Management Studio 中有一个名为“执行计划”的函数，它告诉您运行查询的成本和时间。