我有一個mysql數據庫，其中保存了項目的信息並且還保留了描述。字段長度對查詢時間的影響
問題是說明欄最多可容納150個字符，我認爲它很長，我想知道是否會減慢查詢時間。另外我想知道它是否建議縮短int的大小，我的意思是如果我的價格通常不是那麼大，我應該將列限制爲small/medium int嗎？
的列是這樣的：
id name category publisher mail price description
在此先感謝。
只有你認爲150長 - 數據庫最有可能不會，因爲它們旨在一次處理更多。 不要考慮犧牲你的數據來「表現」。如果您的應用程序的性質要求您一次存儲多達150個字符的文本，不要害怕這樣做，但要查看優化提示。
儘管使用正確的數據類型可以幫助您節省空間。例如，如果您有一個字段用於存儲值0到20，則不需要INT字段類型。一個TINYINT會做。
documentation列出了數據類型，並提供了他們使用多少空間以及他們如何管理的信息。
將您的字符數據存儲爲varchar()而不是char()並閱讀關於這些數據類型的MySQL文檔（here）。這隻會將字符實際存儲在描述中，另外還會有幾個字節的開銷。
至於較長的字段是否意味着性能較差的查詢。這是一個複雜的主題。顯然，在極端情況下，擁有最大容量的記錄會使事情減慢，而不是10個字節的記錄。原因與I/O性能有關。 MySQL讀入頁面並且頁面可以包含一個或多個記錄。然後處理頁面上的記錄。
適合頁面的記錄越多，I/O越少。
但隨後它變得更加複雜，這取決於硬件和存儲引擎。現在，磁盤和操作系統一樣都是預讀。因此，下一次閱讀的頁面（如果頁面沒有碎片並且彼此相鄰）可能比讀取初始頁面快得多。實際上，在第一頁上的處理完成之前，您可能會在內存中擁有下一頁。在這一點上，每頁上有多少記錄並不重要。
而且，200個字節的記錄並不是很大。您應該首先考慮讓您的應用程序正常工作，然後再擔心要使其達到性能目標。一路走來，做出合理的選擇，例如使用varchar()而不是char()和適當大小的數字（您可能會考慮定點數字類型而不是浮動的貨幣值）。
全心全意同意第1部分;但與第2部分強烈反對。現在所有硬件都是32位或64位，只有當你擁有數以億計的這些表示時，纔會考慮使用較小的int表示，並且知道你有性能問題。對可能的數據量使用較小的int表示可能會損害性能並提高性能。 – 2013-04-20 16:53:51
迄今爲止我所讀過的和學過的所有東西都得出結論：使用專門適合應用程序需求的字段類型僅對內存使用（以及緩存和更少的磁盤訪問）有利。如果你能指點我（並且每個人都閱讀這些內容）以獲取有關該主題的材料，我會非常高興！ – 2013-04-20 19:39:54