我目前是一個團隊設計一個網站的一部分，可能會有成千上萬的用戶誰將會做一些日期相關的搜索。在設計階段，我們一直在試圖確定哪個更適合性能優化。最好的方法來處理與數千用戶的MySQL性能日期
我們應該將datetime字段存儲爲mysql日期時間。或者應該將其分解爲多個字段（年，月，日，小時，分鐘......）
問題是有大量數據集和潛在的大量用戶，我們是否會獲得性能明智地將日期時間分成多個字段，並保存依賴於MySQL日期功能？或者mysql已經爲此優化了？
看一看的MySQL Date & Time Functions documentation，因爲你可以使用現有的功能，如YEAR，MONTH等日期拉特定信息雖然這些存在的，如果你對日期列（S）的索引，使用這些函數意味着這些索引不能使用...
將日期作爲單獨組件存儲的問題是需要將它們重建爲日期，以便進行範圍比較或日期操作的工作。
最終，選擇最適合您的應用程序。如果很少需要拆分日期，請考慮使用VIEW公開日期組件，而不必將可能的冗餘信息寫入表中。
使用常規的日期時間字段。如果性能成爲問題，您可以隨時切換到分離的組件。儘量避免過早優化 - 在很多情況下，YAGNI。您可能會使用這兩個 datetime字段和分離的組件方法，因爲他們都有自己的優勢。
如果您事先知道所有搜索都有的關鍵標準，那麼MySQL（> = v5.1）table partitioning可能會有所幫助。
舉例來說，如果你有一個像這樣的表：
create table Books(pubDate dateTime, title varchar(50));
而且你知道所有的搜索都至少有一年的時間，你可以在日期字段對它進行分區，沿着這些路線：
create table Books(pubDate dateTime,title varchar(50)
partition by hash(year(pubDate)) partitions 10;
然後，當您對錶運行select時，如果where子句包括限制分區結果可能存在的條件，則搜索將只掃描該分區，而不是全表掃描。您可以在行動看到這一點：
-- scans entire table
explain partitions select * from Books where title='%title%';
與類似：
-- scans just one partition
explain partitions select * from Books
where year(pubDate)=2010
and title='%title%';
MySQL的documentation on this是相當不錯的，你可以從多個分割算法選擇。
即使您選擇分解日期，也可以提供表示年份（int）的表分區（假設搜索總是指定一年）可能會有所幫助。