如果数据按排序顺序存储，sql搜索是否会更快答案

【问题标题】：Does sql search faster if data is stored in a sorted order如果数据按排序顺序存储，sql搜索是否会更快
【发布时间】：2016-04-01 19:41:28
【问题描述】：

我正在创建一个将使用 LAMP 堆栈的聊天服务。它将是一个 REST api，它将每条聊天消息存储在其数据库中。

我有一个消息表，其中包含：

id|内容|时间戳

现在，api 可能需要从两个时间戳之间的特定 id 获取消息。

由于时间戳是由 mySQL 自动添加的，因此可以预期时间戳列会被排序（如果我错了，请纠正我）。

我不想在时间戳上创建索引，因为该表上将有相当多的写入操作，而且该表将是一个相当大的表。

我想知道在排序的列中搜索是否比普通搜索更快。

我想防止全表扫描只是为了获取两个时间戳之间的所有消息。

【问题讨论】：

"来自两个时间戳之间的特定 id 的消息" -- 复合 INDEX(particular_id, timestamp) 将是最佳的，而 PARTITIONing 将无济于事。
正如我所提到的，表格大小可能会变得非常大。此外，写入操作的数量也会很高。索引还有意义吗？
索引几乎总是有意义的；分区很少有意义。由于有多少变化，请提供SHOW CREATE TABLE 目前的情况。（您的描述不包括引擎、索引、PRIMARY KEY、数据类型等；所有可能值得讨论。）

标签： mysql database optimization database-design indexing

【解决方案1】：

“由于时间戳是由 mySQL 自动添加的，因此可以期望时间戳列被排序”

如果没有索引，搜索将需要全表扫描，无论相似值是否在物理上位于同一位置。这是因为数据库无法知道相似的时间戳值是位于同一位置的。此外，磁盘写入优化技术使得我们无法对任何给定数据的物理位置做出假设，

可能（取决于您对“相当大”的定义）您应该考虑Partitioning。我们可以定义具有 DATE 或 TIMESTAMP 范围的分区。

CREATE TABLE your_table (
    msg_id INT NOT NULL,
    content VARCHAR(2000) NOT NULL,
    msg_timestamp TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
)
PARTITION BY RANGE ( UNIX_TIMESTAMP(msg_timestamp) ) (
PARTITION pmin VALUES LESS THAN ( UNIX_TIMESTAMP('2014-01-01 00:00:00') ),
PARTITION p2014_q1 VALUES LESS THAN ( UNIX_TIMESTAMP('2014-04-01 00:00:00') ),
PARTITION p2014_q2 VALUES LESS THAN ( UNIX_TIMESTAMP('2014-07-01 00:00:00') ),
PARTITION p2014_q3 VALUES LESS THAN ( UNIX_TIMESTAMP('2014-10-01 00:00:00') ),
PARTITION p2014_q4 VALUES LESS THAN ( UNIX_TIMESTAMP('2015-01-01 00:00:00') ),
PARTITION p2015_q1 VALUES LESS THAN ( UNIX_TIMESTAMP('2015-04-01 00:00:00') ),
PARTITION p2015_q2 VALUES LESS THAN ( UNIX_TIMESTAMP('2015-07-01 00:00:00') ),
PARTITION p2015_q3 VALUES LESS THAN ( UNIX_TIMESTAMP('2015-10-01 00:00:00') ),
PARTITION p2015_q4 VALUES LESS THAN ( UNIX_TIMESTAMP('2016-01-01 00:00:00') ),
PARTITION pmax VALUES LESS THAN (MAXVALUE)
);

分区很有用，因为它保证了相关时间戳的协同定位，并且数据库知道该方案的好处，因此可以使用它来限制搜索by partition pruning。基本上，如果查询受用于分区键的列的限制，则数据库将仅扫描包含这些值的分区。缺点是不使用分区键的查询可能比针对非分区表的查询要慢。

【讨论】：