MySQL聚集索引还是非聚集索引？(数据库设计)

Question

我知道在SE的这个角落，这可能是一件基本的事情，但是我在找出设计我的DB的最佳选择时遇到了一些困难。

我正在创建一个自定义应用程序，用户将在该应用程序中将数据输入到表中(让我们将此表称为“清单”)，每分钟至少有一个条目，每个条目将从输入字段抓取数据，当添加新行时，当前的日期和时间也将被添加到datetime列中。

这个表稍后会被前端的应用程序用户浏览至少4次，当他们开始导出以前输入的数据时。

我希望它们按日期排序，所以我计划对MYSQL = 00/00/00的前8个字符在date列上做一个索引(id省略时间部分)。

据我所知，索引会减慢数据的插入和更新，因为每次输入新数据时都需要重建索引。

如果用户每分钟至少输入一次数据，连续2小时(每天)，并且索引必须每分钟重建一次(？)，创建索引(主键id除外)听起来是效率低下的。新的数据来了。

我知道这个表会持续增长，因为他们需要连续几年跟踪记录，这就是为什么我想在日期列上一个索引，以使它在速度上成为未来的证据。但事实上，他们会频繁地将数据输入到其中，而且每次都必须重建索引，这使我对如何继续下去有点不知所措。

我在想一个非聚集索引能解决这个问题？我看过几段解释这两种情况的视频，而且似乎还需要对非聚集索引进行重建吗？

如有任何帮助和建议，将不胜感激。

Answer 1

关于主键：

• 每个表都必须有一个PRIMARY KEY。
• PK (在MySQL的InnoDB引擎中)总是“集群”的
• PK以外的索引是非聚集的。
• PK是“独特的”。它唯一地标识每一行。

在你的问题中：

• 每分钟一个INSERT非常慢。(因此，这里不考虑性能问题，不管表上的索引是什么，也不管其他什么。)
• “导出”行--您的意思是“读取”(SELECT)或“归档”(SELECT，然后是DELETE)?？(请提供更多细节。)
• “MYSQL =00/00/00的前8个字符”--您没有存储DATE部件吗？如果没有，则将其设置为TIME列。如果您只想“提取”时间(从DATETIME )，请参阅TIME()函数。
• “索引.减慢数据的插入和更新速度，因为每次输入新数据时都需要重建索引。”不，不，不。除了显式请求之外，索引是不被重建的--这些请求很少得到保证。
• 索引确实会稍微降低写入速度，但索引可能会显著加快读取速度。所以，不要害怕有索引。
• 10年后，你将有大约500万行。就桌子而言，这只是中等尺寸的.没问题。但是，对于访问单个行或行组，强烈建议索引(无论是PK还是次要索引)。
• “我想在日期列上一个索引，使它在速度上成为未来的证明。”--这并不是“未来证明”。它将帮助一些SELECTs，但对另一些则没有帮助。向我们展示选择，这样我们就可以推荐一组索引，这些索引对这些选择是最优的。
• 稍后，如果添加/删除/更改索引(主索引或辅助索引)，则会有一定的工作量，可能涉及到对表的复制。现在担心这个还为时过早。