大多数情况下，“这取决于”。

例如，如果数据库正在为许多并发用户提供服务，则表格锁定的时间将比总查询时间更重要。

作为一条经验法则，我会说：

插入通常是最快的，因为它只添加数据，不需要锁定表，因为没有现有数据被修改。但是许多索引可能会稍微减慢速度。

SELECT 可能非常快或非常慢。这取决于查询。它有可能是最快的，并且不会锁定表。但 SELECT 操作通常比其他操作更复杂，需要从多个表中获取数据，或更全面地排序或使用索引。

删除相对较慢。表（或根据存储引擎，受影响的行）需要被锁定。索引需要更新。

更新通常是最慢的。需要锁定表（或根据存储引擎需要锁定受影响的行），需要更新索引，而且它比删除稍微复杂一些。

但正如我所说的，这只是一个基本规则，它非常取决于具体情况。

我不确定每个命令个别操作，但很多都取决于实际语句。在表上创建索引需要在插入、更新和删除时修改索引。虽然索引可以加快查询速度，但会拖慢任何数据修改语句。此外，查询的复杂性、列的数据类型、任何 SQL 函数（如聚合）都会改变查询的性能。

你并没有完全提出正确的问题。例如，SELECT必须以某种方式计算与选择相匹配的所有行的集合，然后通过某种机制返回它们，这可能是来自sqlite之类的大块动态数组（因为它在内存中并且在同一个进程中），也可能是通过互联网远程传递的数据。

因此，例如，本地返回10行的SELECT * FROM USERDATA可能只需要微秒，但如果通过广域网返回10,000,000行，则可能需要几分钟。

假设使用简单的查询和常见的使用情况和配置，SELECTs将是最快的，因为它们最容易被缓存（被所有内容 - CPU，磁盘，操作系统，MySQL内存和MySQL查询缓存）和最频繁地执行（允许上述缓存变得有用）。

所有其他操作都是写操作，这些操作需要更多的时间，并且不能被缓存。即使是简单的写查询的操作时间也经常高度依赖于服务器承受了多少读取负载（SELECT查询）。

在数据库查询中，速度只能相对地进行度量。对于大多数简单查询来说，毫秒级别上的差异是名义上的。

更好的问题应该从影响多少事情的角度来看。

• A query can take on a variety of forms but if you are selecting from 3 tables, it will likely be slower than 2 tables.
• Using LIMIT will help the query to execute quicker in all cases
• Indices can help a query if it uses them properly
• Updating indices takes time
• Larger tables take more time to work through

清单还可以继续列下去，但通常我会在事后建立和处理缓慢的地方。大多数人也不会过分地推动他们的数据库:)