如果我有一个在辅助列上有索引的表,使用辅助列获取数据是否能保证结果始终保持一致的顺序?
例如,假设我有一个表 T,其中包含列 PKColumn、ColumnA、ColumnB、ColumnC....
以及 ColumnA 上的索引,例如在 ASC 中
查询是否select * from T where ColumnA = '<some-value>'
保证始终以相同的顺序返回结果(基于在 ColumnA 上创建的索引的排序方向?)
如果我有一个在辅助列上有索引的表,使用辅助列获取数据是否能保证结果始终保持一致的顺序?
例如,假设我有一个表 T,其中包含列 PKColumn、ColumnA、ColumnB、ColumnC....
以及 ColumnA 上的索引,例如在 ASC 中
查询是否select * from T where ColumnA = '<some-value>'
保证始终以相同的顺序返回结果(基于在 ColumnA 上创建的索引的排序方向?)
ColumnA 上的索引,例如在 ASC 中
是否查询,select * from T where ColumnA =
constant
保证结果总是以相同的顺序返回
简短的回答:没有。
长答案:
情况1:如果只有一行具有该值,则“保证”没有“订单”。
情况 2:具有该值的多行。好吧,索引没有指定如何处理 dupColumnA
值。InnoDB 通过添加PRIMARY KEY
列来实现二级索引。所以...
案例 2a:如果优化器选择使用该索引,它将按 PK 顺序排列。
情况 2b:如果它选择不使用该索引,那么优化器可能进行了表扫描。所以,再一次,这将是 PK 顺序。
案例 2c:您在查询中有其他内容(更多在WHERE
, GROUP BY
, LIMIT
,HAVING
等中) 现在所有的赌注都取消了。
案例 2d:(将来的某个时间。)如果优化器可以在多个线程中执行此查询会怎样?现在结果混在一起了。
底线:如果您想要订单,请使用ORDER BY
. 时期。句号。
而且,不要太担心性能。如果优化器可以将其折叠ORDER BY
成其他东西(通常GROUP BY
或附加在 PK 上),那么它会的。这导致ORDER BY
没有额外的成本。
不。
在没有ORDER BY
子句的情况下,引擎可以自由地以任何顺序提供结果集。更重要的是,随着时间的推移,排序可能会不一致。您今天可以按一个顺序获取行,但明天可能会有所不同。
现在,考虑到您已经在 column 上有一个索引ColumnA
,那么您可以通过添加一个ORDER BY
子句来修改查询以确保您想要的顺序,如下所示:
select *
from T
where ColumnA = '<some-value>'
ORDER BY ColumnA
此查询将以边际额外成本提供您想要的有序结果集。如果您要检索的行数很少(少于 1000),则性能变化几乎不会引起注意。
对于更大的结果集,您可以实施性能优化。您需要提供准确的查询,以便在这种情况下为您提供帮助。