1. 程式人生 > >一個因MySQL大小寫敏感導致的問題

一個因MySQL大小寫敏感導致的問題

做一個積極的人

編碼、改bug、提升自己

我有一個樂園,面向程式設計,春暖花開!

00 MYSQL對大小寫敏感

見字如面,見標題知內容。你有遇到過因為MYSQL對大小寫敏感而被坑的體驗嗎?

之前看過阿里巴巴Java開發手冊,在MySql建表規約裡有看到:

【強制】表名、欄位名必須使用小寫字母或數字 , 禁止出現數字開頭,禁止兩個下劃線中間只 出現數字。資料庫欄位名的修改代價很大,因為無法進行預釋出,所以欄位名稱需要慎重考慮。

說明: MySQL 在 Windows 下不區分大小寫,但在 Linux 下預設是區分大小寫。因此,資料庫名、 表名、欄位名,都不允許出現任何大寫字母,避免節外生枝。

正例: aliyun _ admin , rdc _ config , level 3_ name 反例: AliyunAdmin , rdcConfig , level 3 name

如果沒有真正遇到過類似的問題,有時候乾巴巴的看這些規約體會不深,理解起來似懂非懂,並且也只是死記硬背而已。

01 一個表字母大小故事

最近自己在鼓搗一個專案玩玩,在自己本機上開發和測試過程中一直沒有問題,但是部署到Linux伺服器上後,發現有報錯,日誌資訊大概是:

MySQLSyntaxErrorException: Table 'kytu.tb_sutyHo' doesn't exist

出現了問題,有點鬱悶,本地開發好好的,怎麼部署伺服器就不行了。有鬼……不過莫慌。看著錯誤提示很明顯,不就是tb_sutyHo 表不存在嗎!

①於是我不慌不忙開啟nv(navicat),檢視這個表在不在,一看還真在,資料庫中顯示的tb_sutyho ,不過h是小寫;

②檢視程式碼發現程式碼中還真把表名寫成tb_sutyHo ,就一個h寫成大寫H了。

問題找到了,原來是不小心寫SQL的時候沒有寫對錶名,改一下表名就搞定了,功能也一切正常了。一般情況下故事到這裡也就應該結束了?問題找到了,也修復了,萬事大吉了,稍後就可以吃雞了。

對於不會玩吃雞的我,到這裡並沒有結束,找到問題和解決問題的確很重要,但是找到問題出現的根源更重要,這樣就能在下次規避此類問題,作為一個程式設計師不要兩次掉入一個坑裡。

我在想這個問題,本地Window環境怎麼就一直沒有出現這個報錯提示呢?非要等我部署伺服器才出現,這到底是什麼問題?(如果你對Mysql大小敏感很瞭解,以下內容可以跳過….)

於是就利用搜索引擎,發現Mysql中控制資料庫名和表名的大小寫敏感由引數lower_case_table_names控制。

在本機Window環境檢視如下:

mysql> show variables like '%case%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| lower_case_file_system | ON    |
| lower_case_table_names | 1     |
+------------------------+-------+

在Linux伺服器檢視如下:

mysql> show variables like '%case%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| lower_case_file_system | OFF    |
| lower_case_table_names | 0     |
+------------------------+-------+

從上面的結果已經可以看出不同了,然而對這兩個引數還沒有感覺,不知道具體是什麼意思。

在介紹lower_case_table_names的時候,順便也說一下lower_case_file_system

lowercasefile_system

此變數描述資料目錄所在的檔案系統上檔名的區分大小寫。 OFF表示檔名區分大小寫,ON表示它們不區分大小寫。此變數是隻讀的,因為它反映了檔案系統屬性並設定它對檔案系統沒有影響。

lowercasetable_names

該引數為靜態,可設定為0、1、2。

0 --大小寫敏感。(Unix,Linux預設) 建立的庫表將原樣儲存在磁碟上。如create database TeSt;將會建立一個TeSt的目錄,create table AbCCC …將會原樣生成AbCCC.frm。 SQL語句也會原樣解析。

1 --大小寫不敏感。(Windows預設) 建立的庫表時,MySQL將所有的庫表名轉換成小寫儲存在磁碟上。 SQL語句同樣會將庫表名轉換成小寫。 如需要查詢以前建立的Testtable(生成Testtable.frm檔案),即便執行select * from Testtable,也會被轉換成select * from testtable,致使報錯表不存在。

2 --大小寫不敏感(OS X預設) 建立的庫表將原樣儲存在磁碟上。 但SQL語句將庫表名轉換成小寫。

On Windows the default value is 1. On macOS, the default value is 2. On Linux, a value of 2 is not supported; the server forces the value to 0 instead.

在Windows上,預設值為1。在macOS上,預設值為2。在Linux上不支援值2;伺服器強制該值為0。

並且官網也提示說:如果在資料目錄駐留在不區分大小寫的檔案系統(例如Windows或macOS)上的系統上執行MySQL,則不應將lowercasetable_names設定為0。

我自己在我的window10環境嘗試設定lower_case_table_names為0的時候,MySQL的服務怎麼也啟動不能,啟動服務報錯。windows系統對大小寫不敏感,見下圖:

注: 如果要修改lower_case_table_names這個值,windows下修改my.ini ,Linux下修改my.cnf配置檔案,需要重啟服務,具體操作可以自行上網找資料。

 

02 注意事項

修改lowercasetable_names導致的常見不良隱患: 如果在lower_case_table_names=0時,建立了含有大寫字母的庫表,改為lower_case_table_names=1後,則會無法被查到。

首先設定lower_case_table_names=0

CREATE TABLE `Student` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(25) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

show tables;
+----------------+
| Tables_in_aflyun |
+----------------+
| Student           |
+----------------+

再設定lower_case_table_names=1,執行查詢,不管表名是大寫還是小寫,都提示表不存在。

mysql> select * from Student;
1146 - Table 'aflyun.Student' doesn't exist

mysql> select * from student;
1146 - Table 'aflyun.student' doesn't exist

解決方法:如果要將預設的lower_case_tables_name為0設定成1,需先將已經存在的庫表名轉換為小寫。

針對僅表名存在大寫字母的情況:

①、lower_case_tables_name=0時,執行rename table成小寫。

②、設定lower_case_tables_name=1,重啟生效。

 

針對庫名存在大寫字母的情況:

①、lower_case_tables_name=0時,使用mysqldump匯出,並刪除老的資料庫。

②、設定lower_case_tables_name=1,重啟生效。

③、匯入資料至例項,此時包含大寫字母的庫名已轉換為小寫。

 

03 總結

有了踩坑的經驗,對開頭說的阿里Mysql規約理解更加深入了。作業系統不同導致大小寫敏感不一致。我們在開發時,應該按大小寫敏感的原則去開發,這樣可以使開發的程式相容不同的作業系統。因此,建議在開發測試環境下把lower_case_table_names的值設為0,便於在開發中就嚴格控制程式碼大小寫敏感,提高程式碼的相容和嚴謹。

 

04 參考資料

MySQL大小寫敏感問題lowercasetablenames & lowercasefilesystem

 

 


謝謝你的閱讀,如果您覺得這篇博文對你有幫助,請點贊或者喜歡,讓更多的人看到!祝你每天開心愉快!


 

不管做什麼,只要堅持下去就會看到不一樣!在路上,不卑不亢!

 

願你我在人生的路上能都變成最好的自己,能夠成為一個獨擋一面的人

© 每天都在變得更好的阿