演示索引 SQL 表的性能优势答案

【问题标题】：Demonstration of performance benefit of indexing a SQL table演示索引 SQL 表的性能优势
【发布时间】：2012-12-18 23:03:04
【问题描述】：

我一直听说，对 SQL 表进行“正确”索引是提高性能的关键。我从未见过这样的真实示例，我想使用SQLFiddle 制作一个示例，但不确定使用 SQL 语法。

假设我有 3 张桌子：1) Users 2) Comments 3) Items。我们还假设任何用户都可以评论每个项目。因此，要获得 item=3 的 cmets，SQL SELECT 的样子如下：

SELECT * from comments join users on comments.commenter_id=users.user_id 
WHERE comments.item_id=3

我听说一般来说，如果行数变大，即数千/数百万，应该在WHERE 和JOINed 列上放置索引。所以在这种情况下，comments.item_id、comments.commenter_id 和 users.user_id。

我想创建一个SQLFiddle 来比较将这些表编入索引与每个表不使用成千上万行。有人可以帮忙生成这个 SQLFiddle 吗？

【问题讨论】：

好吧，我认为 SQL fiddle 不是最好的工具。获取一个 MySQL 实例，或者一个带有 MySQL 的完整虚拟设备，然后在上面进行操作。顺便说一句，生成测试数据并不是一件容易的事。最好的办法是从某个地方获取一个真实数据库的副本并使用它 - 但如果您手头还没有一个，这并不是最容易的事情......
SQL Fiddle 会限制你大约 8k 的数据，我想。现在，您几乎可以获得每个 dbms 的免费版本。安装您喜欢的，并使用您喜欢的脚本语言生成数据。（我喜欢一年学几次新语言，这样的事情是一个很好的借口。）
@ppeterka 感谢您的建议
@Catcall 感谢您的建议
看看Use The Index, Luke

标签： mysql sql join indexing sqlfiddle

【解决方案1】：

我是 SQL Fiddle 的所有者。它绝对不是为性能测试生成巨大数据库的地方。有太多其他变量是您无法控制的（但在现实生活中应该），例如内存、硬盘配置等。此外，作为共享环境，还有其他人使用它可以也会影响您的测试。话虽如此，您仍然可以在 sqlfiddle 中构建一个小型数据库，然后查看有无索引查询的执行计划。无论其他环境因素如何，这些都是一致的，并且将是学习优化的良好来源。

【讨论】：

摇滚。正如他所说，puleeeeze 不要尝试在 sqlfiddle 上进行基准测试。
嗨@jake，对不起，我不是故意建议我们使用 SQLFiddle 来引起问题。我的目的只是问其他人可以轻松获得答案的问题。

【解决方案2】：

索引一个表有很多不同的方法，您可以根据最常用的 SELECT 语句选择不同的索引多个表。两种基本类型的索引称为集群索引和非集群索引。

聚集索引存储索引本身的所有信息，而不是存储数据库可以从中提取然后用于查找实际数据的引用列表。可视化这一点的最简单方法是将索引和表本身视为单独的对象。在聚集索引中，如果您索引的列被用作标准（在 WHERE 子句中），那么查询提取的信息将直接从索引中提取，而不是从表中提取。

另一方面，非聚集索引更像是一个参考表。它告诉查询它所请求的实际信息存储在表对象本身的什么位置。因此，从本质上讲，当您使用非聚集索引时，实际上需要从表本身中检索数据。

聚簇索引按顺序将数据物理存储在硬盘上，因此，您只能在一个表上拥有一个聚簇索引（因为我们只能以一种“物理”方式将表存储在一个磁盘驱动器）。聚集索引也需要是唯一的（尽管肉眼可能不是这样，但数据库本身总是如此）。因此，大多数聚集索引都放在主键上（因为大多数主键都是唯一的）。

与聚集索引不同，您可以在一个表上拥有任意数量的非聚集索引，因为毕竟它们只是实际表本身的参考表。由于我们对于非聚集索引的选项数量基本上是无限的，因此用户喜欢根据需要在 SELECT 语句的 WHERE 子句中常用的列上放置尽可能多的选项。

但就像所有事情一样，过度并不总是好的。您在表上放置的索引越多，该表上的“开销”就越多。索引可能会加快您的查询运行速度，但过多的开销也会减慢它们的速度。关键是在索引过多和索引不足之间找到适合您特定情况的平衡点。

至于测试带或不带索引的查询性能的好地方，我建议使用 SQL Server。 SQL Server Management Studio 中有一个名为“执行计划”的函数，它可以告诉您运行查询的成本和时间。

【讨论】：