mysql中 varchar(20)數(shù)據(jù)長度超過了是設置錯誤造成的,解決方法為:
成都一家集口碑和實力的網(wǎng)站建設服務商,擁有專業(yè)的企業(yè)建站團隊和靠譜的建站技術,10年企業(yè)及個人網(wǎng)站建設經(jīng)驗 ,為成都成百上千家客戶提供網(wǎng)頁設計制作,網(wǎng)站開發(fā),企業(yè)網(wǎng)站制作建設等服務,包括成都營銷型網(wǎng)站建設,成都品牌網(wǎng)站建設,同時也為不同行業(yè)的客戶提供做網(wǎng)站、成都網(wǎng)站設計的服務,包括成都電商型網(wǎng)站制作建設,裝修行業(yè)網(wǎng)站制作建設,傳統(tǒng)機械行業(yè)網(wǎng)站建設,傳統(tǒng)農業(yè)行業(yè)網(wǎng)站制作建設。在成都做網(wǎng)站,選網(wǎng)站制作建設服務商就選成都創(chuàng)新互聯(lián)。
1、通過my.ini(Linux下為my.cnf)的配置文件進行修改。一般my.ini文件在安裝文件的根目錄下。
2、系統(tǒng)是Windows10,安裝目錄下沒有my.ini文件。
3、仔細找了一下,my.ini文件在ProgramData下。
4、打開配置文件,在?[mysqld] 的后面加入一行“ft_min_word_len=1”。PS:也可以設置成ft_min_word_len=2,具體情況根據(jù)自己的中文數(shù)據(jù)而定。
5、重啟MySQL服務。注意,配置文件修改后一定要重啟服務后才能生效。
6、查看一下最小索引長度,確定生效。SQL語句:SHOW GLOBAL VARIABLES LIKE '%__word_len%'。
我們經(jīng)常會遇到操作一張大表,發(fā)現(xiàn)操作時間過長或影響在線業(yè)務了,想要回退大表操作的場景。在我們停止大表操作之后,等待回滾是一個很漫長的過程,盡管你可能對知道一些縮短時間的方法,處于對生產環(huán)境數(shù)據(jù)完整性的敬畏,也會選擇不做介入。最終選擇不作為的原因大多源于對操作影響的不確定性。實踐出真知,下面針對兩種主要提升事務回滾速度的方式進行驗證,一種是提升操作可用內存空間,一種是通過停實例,禁用 redo 回滾方式進行進行驗證。
仔細閱讀過官方手冊的同學,一定留意到了對于提升大事務回滾效率,官方提供了兩種方法:一是增加 innodb_buffer_pool_size 參數(shù)大小,二是合理利用 innodb_force_recovery=3 參數(shù),跳過事務回滾過程。第一種方式比較溫和,innodb_buffer_pool_size 參數(shù)是可以動態(tài)調整的,可行性也較高。第二種方式相較之下較暴力,但效果較好。
兩種方式各有自己的優(yōu)點,第一種方式對線上業(yè)務系統(tǒng)影響較小,不會中斷在線業(yè)務。第二種方式效果更顯著,會短暫影響業(yè)務連續(xù),回滾所有沒有提交的事務。
問題
我們有一個 SQL,用于找到?jīng)]有主鍵 / 唯一鍵的表,但是在 MySQL 5.7 上運行特別慢,怎么辦?
實驗
我們搭建一個 MySQL 5.7 的環(huán)境,此處省略搭建步驟。
寫個簡單的腳本,制造一批帶主鍵和不帶主鍵的表:
執(zhí)行一下腳本:
現(xiàn)在執(zhí)行以下 SQL 看看效果:
...
執(zhí)行了 16.80s,感覺是非常慢了。
現(xiàn)在用一下 DBA 三板斧,看看執(zhí)行計劃:
感覺有點慘,由于 information_schema.columns 是元數(shù)據(jù)表,沒有必要的統(tǒng)計信息。
那我們來 show warnings 看看 MySQL 改寫后的 SQL:
我們格式化一下 SQL:
可以看到 MySQL 將
select from A where A.x not in (select x from B) //非關聯(lián)子查詢
轉換成了
select from A where not exists (select 1 from B where B.x = a.x) //關聯(lián)子查詢
如果我們自己是 MySQL,在執(zhí)行非關聯(lián)子查詢時,可以使用很簡單的策略:
select from A where A.x not in (select x from B where ...) //非關聯(lián)子查詢:1. 掃描 B 表中的所有記錄,找到滿足條件的記錄,存放在臨時表 C 中,建好索引2. 掃描 A 表中的記錄,與臨時表 C 中的記錄進行比對,直接在索引里比對,
而關聯(lián)子查詢就需要循環(huán)迭代:
select from A where not exists (select 1 from B where B.x = a.x and ...) //關聯(lián)子查詢掃描 A 表的每一條記錄 rA: ? ? 掃描 B 表,找到其中的第一條滿足 rA 條件的記錄。
顯然,關聯(lián)子查詢的掃描成本會高于非關聯(lián)子查詢。
我們希望 MySQL 能先"緩存"子查詢的結果(緩存這一步叫物化,MATERIALIZATION),但MySQL 認為不緩存更快,我們就需要給予 MySQL 一定指導。
...
可以看到執(zhí)行時間變成了 0.67s。
整理
我們診斷的關鍵點如下:
\1. 對于 information_schema 中的元數(shù)據(jù)表,執(zhí)行計劃不能提供有效信息。
\2. 通過查看 MySQL 改寫后的 SQL,我們猜測了優(yōu)化器發(fā)生了誤判。
\3. 我們增加了 hint,指導 MySQL 正確進行優(yōu)化判斷。
但目前我們的實驗僅限于猜測,猜中了萬事大吉,猜不中就無法做出好的診斷。
這個提示的意思是沒選擇數(shù)據(jù)庫。
如果你是使用軟件(如navicat、SQL
yog等)來創(chuàng)建數(shù)據(jù)庫的話,先點一下軟件左邊的數(shù)據(jù)庫名稱,選中要創(chuàng)建的表所屬數(shù)據(jù)庫,再新建表。
如果是使用命令行創(chuàng)建,則先執(zhí)行命令:use
數(shù)據(jù)庫名;(如在test數(shù)據(jù)庫中創(chuàng)建表,則輸入:use
test;后按回車)
MySQL 數(shù)據(jù)庫的varchar類型在4.1以下的版本中的最大長度限制為255,其數(shù)據(jù)范圍可以是0~255或1~255(根據(jù)不同版本數(shù)據(jù)庫來定)。在 MySQL5.0以上的版本中,varchar數(shù)據(jù)類型的長度支持到了65535,也就是說可以存放65532個字節(jié)的數(shù)據(jù),起始位和結束位占去了3個字 節(jié),也就是說,在4.1或以下版本中需要使用固定的TEXT或BLOB格式存放的數(shù)據(jù)可以使用可變長的varchar來存放,這樣就能有效的減少數(shù)據(jù)庫文 件的大小。
MySQL 數(shù)據(jù)庫的varchar類型在4.1以下的版本中,nvarchar(存儲的是Unicode數(shù)據(jù)類型的字符)不管是一個字符還是一個漢字,都存為2個字節(jié) ,一般用作中文或者其他語言輸入,這樣不容易亂碼 ;varchar: 漢字是2個字節(jié),其他字符存為1個字節(jié) ,varchar適合輸入英文和數(shù)字。
4.0版本以下,varchar(20),指的是20字節(jié),如果存放UTF8漢字時,只能存6個(每個漢字3字節(jié)) ;5.0版本以上,varchar(20),指的是20字符,無論存放的是數(shù)字、字母還是UTF8漢字(每個漢字3字節(jié)),都可以存放20個,最大大小是65532字節(jié) ;varchar(20)在Mysql4中最大也不過是20個字節(jié),但是Mysql5根據(jù)編碼不同,存儲大小也不同,具體有以下規(guī)則:
a) 存儲限制
varchar 字段是將實際內容單獨存儲在聚簇索引之外,內容開頭用1到2個字節(jié)表示實際長度(長度超過255時需要2個字節(jié)),因此最大長度不能超過65535。
b) 編碼長度限制
字符類型若為gbk,每個字符最多占2個字節(jié),最大長度不能超過32766;
字符類型若為utf8,每個字符最多占3個字節(jié),最大長度不能超過21845。
若定義的時候超過上述限制,則varchar字段會被強行轉為text類型,并產生warning。
c) 行長度限制
導致實際應用中varchar長度限制的是一個行定義的長度。 MySQL要求一個行的定義長度不能超過65535。若定義的表長度超過這個值,則提示
ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs。
如果不能更改數(shù)據(jù)庫結構,且不能更改查詢的語句,只是希望不報錯的話,
請檢查你程序文件中,調用Mysql的模塊,
以C#為例,會使用ado.NET來操作Mysql數(shù)據(jù)庫,
在配置文件中,會有TimeOut屬性,默認是60000ms 即一分鐘.
查詢時,程序請求Sql =sql處理 =sql返回結果,
如果處理過程超過60000ms 就會報錯,
將這個屬性該為更大的數(shù)值即可解決,
如果是其他語言開發(fā)的程序,應該也會有類似的屬性可供修改。