我是否只是在架構中的列上聲明索引，例如？

ALTER TABLE `table` ADD INDEX `index_name` (`colDate`)

ORDER BY我希望表記錄不僅在查詢時進行物理排序。

我相信，如果我將始終查詢日期範圍或有關順序範圍的任何查詢，則最好在日期上建立索引。我相信這一點是正確的嗎？

根據本書第 7 章第 148,149 頁Storing Tables in Column-Sorted ORDER

通過 usingALTER TABLE ... ORDER BY語句，您可以控制 MySQL 如何為您的表儲存物理數據，而不管是否有索引。

您在理論上是正確的，但儲存引擎將對組織擁有最終決定權。我引用的上述聲明適用於 MyISAM。InnoDB 呢？第 149 頁以

如果表是用 InnoDB 而不是 MyISAM 定義的，這將不起作用： InnoDB 總是通過Clustered Key儲存其數據。

正如MySQL 文件所說，聚集索引本質上是一個 rowid 索引

如果表沒有 PRIMARY KEY 或合適的 UNIQUE 索引，InnoDB 會在內部生成一個隱藏的聚集索引，該索引包含行 ID 值的合成列。這些行按 InnoDB 分配給此類表中的行的 ID 排序。行 ID 是一個 6 字節的欄位，隨著新行的插入而單調增加。因此，按行 ID 排序的行在物理上是按插入順序排列的。

這就是為什麼做ALTER TABLE ... ORDER BY對 InnoDB 表沒有影響的原因。即使行在物理上重新排序，行也將通過 rowid 的 Clustered Key 訪問。

您的原始問題

回頭看你做的索引，可以實現如下

• 如果您始終輸入日期值遞增的數據，則索引會簡化日期範圍掃描。
• 如果您從較早日期載入數據，則只有索引可以幫助您進行範圍掃描。

物理重新排序集群密鑰的唯一方法是執行這個

CREATE TABLE mytable_new LIKE mytable;
INSERT INTO  mytable_new SELECT * FROM mytable ORDER BY colDate;
DROP TABLE mytable;
ALTER TABLE mytable_new RENAME mytable;

除非這是一次性重新排序，否則這樣做不符合您的最佳利益。我的建議是堅持創建索引，讓 MySQL 完成所有必要的繁重工作。此外，您需要ANALYZE TABLE mytable;每週執行一次以確保在執行大日期掃描之前獲得最新的索引統計資訊。

引用自：https://dba.stackexchange.com/questions/115944