MySQL Clustered Index or Non Clustered index? (Database Design)
About PRIMARY KEYs:

Each table must have a PRIMARY KEY.
The PK (in MySQL's InnoDB engine) is always &quot;clustered&quot;
Indexes other than the PK are non-clustered.
The PK is &quot;unique&quot;.  It uniquely identifies each row.

In your question:

One INSERT per minute is very slow.  (So, no performance concerns here, regardless of the indexes on the table, regardless of anything else.)
&quot;Exporting&quot; rows -- Do you mean &quot;read&quot; (SELECT) or &quot;archive&quot; (SELECT, then DELETE)??  (More details, please.)
&quot;first 8 characters of the MYSQL DATE = 00/00/00&quot; -- Are you not storing the DATE part?  If not, then make it a TIME column.  If you want to &quot;extract&quot; just the time (from a DATETIME, see the TIME() function.
&quot;indexes ... slow down inserting and updating of data because the index needs to be rebuilt every time new data is entered.&quot;  NO, NO, NO.  Indexes are not rebuilt except on explicit requests -- which are rarely warranted.
Having an index does slow down writes slightly, but the index is likely to speed up reads significantly.  So, don't fear having indexes.
After 10 years, you will have about 5 million rows.  As tables go, this is only medium-sized.  Not a problem.  However, for accessing individual rows or groups of rows, indexes (whether PK or secondary) are strongly advised.
&quot;I'd want to put an index on the date column to make it future proof in terms of speed.&quot; -- That does not &quot;future-proof&quot; it.  It will help some SELECTs, but not others.  Show us the selects so we can recommend a set of indexes that would be optimal for those selects.
Later, if you add/drop/change an index (primary or secondary), there will be some amount of effort, possibly involving copying the table over.  It is premature to worry about that.