『壹』 mysql varchar定義長度多少為好
MySQL的varchar定義長度到底是位元組
varchar存儲規則：
4.0版本以下，varchar(20)，指的是20位元組，如果存放UTF8漢字時，只能存6個（每個漢字3位元組）
5.0版本以上，varchar(20)，指的是20字元，無論存放的是數字、字母還是UTF8漢字（每個漢字3位元組），都可以存放20個，最大大小是65532位元組
Mysql4中最大也不過是20個位元組,但是Mysql5根據編碼不同,存儲大小也不同。
『貳』 資料庫單行數據總長度限制了
好像access的每行字元個數（不包含ole和備注）最大就是2000。
所以最好換資料庫。
『叄』 資料庫欄位的長度到底指的是什麼 是位元組 還是字元的個數 。。。
資料庫欄位的長度到底指的是位元組。
在多數的計算機系統中，一個位元組是一個8位長的數據單位，大多數的計算機用一個位元組表示一個字元、數字或其他字元。一個位元組也可以表示一系列二進制位。在一些計算機系統中，4 個位元組代表一個字，這是計算機在執行指令時能夠有效處理數據的單位。
一些語言描述需要2個位元組表示一個字元，這叫做雙位元組字元集。一些處理器能夠處理雙位元組或單位元組指令。位元組通常簡寫為「B」，而位通常簡寫為小寫「b」，計算機存儲器的大小通常用位元組來表示。
(3)資料庫列總長度擴展閱讀
欄位長度由字母、符號和數字組成。例如，有效字元數據包括「928」、「Johnson」。在Microsoft®SQLServer™2000中，字元數據使用char、varchar和text數據類型存儲。當列中各項的字元長度數時可用varchar類型，但任何項的長度都不能超過8KB。
當列中各項為同一固定長度時使用char類型（最多8KB）。text數據類型的列可用於存儲大於8KB的ASCII字元。例如，由於HTML文檔均由ASCII字元組成且一般長於8KB，所以用瀏覽器查看之前應在SQLServer中存儲在text列中。
『肆』 mysql中表列欄位名長度最長可以多少
mysql中表欄位名的最大允許長度64個位元組，如果都是英文字母或數字，那麼欄位名最長可以是64個字元，如果使用中文那麼每個中文字將佔用兩個位元組。
例如下面兩個字串（剛好64個位元組）作為列名不會出錯
``，
`中`
而下面兩個字串作為列名就會報錯，因為長度剛好超出64個位元組
`4`，
`中`
有關MySQL標識符最大長度請參閱下表
『伍』 資料庫中的一個欄位的數據大小不定如何設置欄位的長度查詢最快又節省空間
varchar是可變字元，varchar(2000)即可，不會浪費空間。
樓主為何要將歷史記錄存在access中呢？若您後台有sql server支持，建議您歷史記錄也存放在sql中，access的性能及對sql的語言支持都遠不如 MSSQL。
【VARCHAR限制了字元串的長度不能超過255個字元?】---哦，忘記了，這個可能access有此限制，sql可以的，最大varchar（8000）。
varchar(100)中的100並不多餘，在未存儲數據時用於佔位，系統會用於預先計劃分配空間，但直到真正存儲數據時才確實分配存儲空間。
個人看法：
1.佔用空間上varchar（100）和varchar（2000）沒什麼區別。
2.但varchar(100)會效率較低，因為按你說的該欄位會5-2000，若大於100，則您每次固定寫入100會需要多次寫操作，眾所周知寫操作是比較耗時的。
3.查詢性能方面，跟您這兒怎麼存沒太大關系，重要的還是常見的資料庫查詢優化，如索引、條件等等
對這個問題，我引用一下CSDN上的說法：
一。數據行結構
char(n): 系統分配n個位元組給此欄位，不管欄位實際長度(後邊用空格補齊)
varchar(n): 假設表中有M個varchar(或者nvarchar)類型的欄位
先分配兩個位元組(用來表示M)
再分配2*M個位元組(表示各變長行的偏移)
此後欄位值有多長，就分配多長
二。varchar(n)一定比char(n)節省空間么?
不一定。
我見過這樣的設計: varchar(3)
就算此欄位為空，也還是比char(3)多用一個位元組。
還有這樣的設計: user_ip varchar(16).
對於這種數據長度變化不大的欄位，用varchar只能浪費空間
結論: varchar適用於數據值長度不太短，且長度變化較大的欄位
三。char(n)一定比varchar(n)速度快么?
不一定
計算varchar的偏移是會花去一些cpu時間，但性能瓶頸不在此，在io.
db的io單位是數據頁(8192位元組)(一頁存有多個數據行，數據行不能跨頁。當然image,text等例外). 因此一頁中行越多，性能越好
另外，關於char和varchar的性能比較，
請參見該實驗：
http://www.yuanma.org/data/2006/0730/article_1266.htm
再補充一下：
[轉帖]char、nchar、varchar、nvarchar，對比那個好？
資料庫定義到char類型的欄位時，不知道大家是否會猶豫一下，到底選char、nchar、varchar、nvarchar、
text、ntext中哪一種呢？結果很可能是兩種，一種是節儉人士的選擇：最好是用定長的，感覺比變長能省些空
間，而且處理起來會快些，無法定長只好選用定長，並且將長度設置盡可能地小；另一種是則是覺得無所謂，
盡量用可變類型的，長度盡量放大些。
鑒於現在硬體像蘿卜一樣便宜的大好形勢，糾纏這樣的小問題實在是沒多大意義，不過如果不弄清它，
總覺得對不起勞累過度的CPU和硬碟。
下面開始了(以下說明只針對SqlServer有效)：
1、當使用非unicode時慎用以下這種查詢：
select f from t where f = N'xx'
原因：無法利用到索引，因為資料庫會將f先轉換到unicode再和N'xx'比較
2、char 和相同長度的varchar處理速度差不多（後面還有說明）
3、varchar的長度不會影響處理速度！！！（看後面解釋）
4、索引中列總長度最多支持總為900位元組，所以長度大於900的varchar、char和大於450的nvarchar,nchar
將無法創建索引
5、text、ntext上是無法創建索引的
6、O/R Mapping中對應實體的屬性類型一般是以string居多，用char[]的非常少，所以如果按mapping的
合理性來說，可變長度的類型更加吻合
7、一般基礎資料表中的name在實際查詢中基本上全部是使用like '%xx%'這種方式，而這種方式是無法利用
索引的，所以如果對於此種欄位，索引建了也白建
8、其它一些像remark的欄位則是根本不需要查詢的，所以不需要索引
9、varchar的存放和string是一樣原理的，即length {block}這種方式，所以varchar的長度和它實際佔用
空間是無關的
10、對於固定長度的欄位，是需要額外空間來存放NULL標識的，所以如果一個char欄位中出現非常多的NULL，
那麼很不幸，你的佔用空間比沒有NULL的大（但這個大並不是大太多，因為NULL標識是用bit存放的，
可是如果你一行中只有你一個NULL需要標識，那麼你就白白浪費1byte空間了，罪過罪過！），這時候，
你可以使用特殊標識來存放，如：'NV'
11、同上，所以對於這種NULL查詢，索引是無法生效的，假如你使用了NULL標識替代的話，那麼恭喜你，
你可以利用到索引了
12、char和varchar的比較成本是一樣的，現在關鍵就看它們的索引查找的成本了，因為查找策略都一樣，
因此應該比較誰佔用空間小。在存放相同數量的字元情況下，如果數量小，那麼char佔用長度是小於varchar
的，但如果數量稍大，則varchar完全可能小於char，而且要看實際填充數值的充實度，比如說varchar(3)
和char(3)，那麼理論上應該是char快了，但如果是char(10)和varchar(10)，充實度只有30%的情況下，
理論上就應該是varchar快了。因為varchar需要額外空間存放塊長度，所以只要length(1-fillfactor)
大於這個存放空間（好像是2位元組)，那麼它就會比相同長度的char快了。
13、nvarchar比varchar要慢上一些，而且對於非unicode字元它會佔用雙倍的空間，那麼這么一種類型
推出來是為什麼呢？對，就是為了國際化，對於unicode類型的數據，排序規則對它們是不起作用的，
而非unicode字元在處理不同語言的數據時，必須指定排序規則才能正常工作，所以n類型就這么一點好處。
總結陳詞：
1、如果數據量非常大，又能100%確定長度且保存只是ansi字元，那麼char
2、能確定長度又不一定是ansi字元或者，那麼用nchar；
3、不確定長度，要查詢且希望利用索引的話，用nvarchar類型吧，將它們設到400；
4、不查詢的話沒什麼好說的，用nvarchar(4000)
5、性格豪爽的可以只用3和4，偶爾用用1，畢竟這是一種額外說明，等於告訴別人說，我一定需要長度
為X位的數據
『陸』 SQL數據類型！
SQL字元類型介紹
一，名詞定義
char為 定長字元型，如char(10)，你實際數據是『hello』，這時Sql Server 會自動補充空格，填滿10位。varchar：可變長字元，沒有上述問題，是多長就保存多長的數據。另外, char 和 varchar 在存儲數據時,每個英文字元和數字都佔一個位元組,而一個中文的字元會占兩個位元組.
nchar 與 nvarchar 的用法基本相同,只不過在存儲數據時採用的是 Unicode元碼, 一個英文字元和一個中文字元所佔的空間是相同的.都是兩個位元組.
二、名詞解釋
1、當使用非unicode時慎用以下這種查詢：
select f from t where f = N』xx』
原因：無法利用到索引，因為資料庫會將f先轉換到unicode再和N』xx』比較
2、char 和相同長度的varchar處理速度差不多（後面還有說明）
3、varchar的長度不會影響處理速度（看後面解釋）
4、索引中列總長度最多支持總為900位元組，所以長度大於900的varchar、char和大於450的nvarchar,nchar將無法創建索引
5、text、ntext上是無法創建索引的
6、O/R Mapping中對應實體的屬性類型一般是以string居多，用char[]的非常少，所以如果按mapping的合理性來說，可變長度的類型更加吻合
7、一般基礎資料表中的name在實際查詢中基本上全部是使用like 『%xx%』這種方式，而這種方式是無法利用索引的，所以如果對於此種欄位，索引建了也白建
8、其它一些像remark的欄位則是根本不需要查詢的，所以不需要索引
9、varchar的存放和string是一樣原理的，即length {block}這種方式，所以varchar的長度和它實際佔用空間是無關的
10、對於固定長度的欄位，是需要額外空間來存放NULL標識的，所以如果一個char欄位中出現非常多的NULL，那麼很不幸，你的佔用空間比沒有NULL的大，這時候，你可以使用特殊標識來存放，如：』NV』
11、同上，所以對於這種NULL查詢，索引是無法生效的，假如你使用了NULL標識替代的話，那麼恭喜你，你可以利用到索引了
12、char和varchar的比較成本是一樣的，現在關鍵就看它們的索引查找的成本了，因為查找策略都一樣，因此應該比較誰佔用空間小。在存放相同數量的字元情況下，如果數量小，那麼char佔用長度是小於varchar的，但如果數量稍大，則varchar完全可能小於char，而且要看實際填充數值的充實度，比如說varchar(3)和char(3)，那麼理論上應該是char快了，但如果是char(10)和varchar(10)，充實度只有30%的情況下，理論上就應該是varchar快了。因為varchar需要額外空間存放塊長度，所以只要length(1-fillfactor)大於這個存放空間（好像是2位元組)，那麼它就會比相同長度的char快了。
13、nvarchar比varchar要慢上一些，而且對於非unicode字元它會佔用雙倍的空間，那麼這么一種類型推出來是為什麼呢？對，就是為了國際化，對於unicode類型的數據，排序規則對它們是不起作用的，而非unicode字元在處理不同語言的數據時，必須指定排序規則才能正常工作，所以n類型就這么一點好處。
三、名詞總結
1、如果數據量非常大，又能100%確定長度且保存只是ansi字元，那麼char
2、能確定長度又不一定是ansi字元或者，那麼用nchar；
3、不確定長度，要查詢且希望利用索引的話，用nvarchar類型吧，將它們設到400；
4、不查詢的話沒什麼好說的，用nvarchar(4000)
5、性格豪爽的可以只用3和4，偶爾用用1，畢竟這是一種額外說明，等於告訴別人說，我一定需要長度為X位的數據
（這些字元型在網上都能搜索到的，搜搜看那，給你幾個網址：
http://blog1.poco.cn/myBlogDetail.htx&id=1619242&userid=40517719&pri=&n=0
http://www.w3school.com.cn/sql/sql_syntax.asp
）