作一個積極的人html
編碼、改bug、提高本身mysql
我有一個樂園,面向編程,春暖花開!linux
見字如面,見標題知內容。你有遇到過由於MYSQL對大小寫敏感而被坑的體驗嗎?程序員
以前看過阿里巴巴Java開發手冊,在MySql建表規約裏有看到:sql
【強制】表名、字段名必須使用小寫字母或數字 , 禁止出現數字開頭,禁止兩個下劃線中間只 出現數字。數據庫字段名的修改代價很大,由於沒法進行預發佈,因此字段名稱須要慎重考慮。數據庫
說明: MySQL 在 Windows 下不區分大小寫,但在 Linux 下默認是區分大小寫。所以,數據庫名、 表名、字段名,都不容許出現任何大寫字母,避免節外生枝。編程
正例: aliyun _ admin , rdc _ config , level 3_ name 反例: AliyunAdmin , rdcConfig , level 3 namewindows
若是沒有真正遇到過相似的問題,有時候乾巴巴的看這些規約體會不深,理解起來似懂非懂,而且也只是死記硬背而已。服務器
最近本身在鼓搗一個項目玩玩,在本身本機上開發和測試過程當中一直沒有問題,可是部署到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
。
此變量描述數據目錄所在的文件系統上文件名的區分大小寫。 OFF表示文件名區分大小寫,ON表示它們不區分大小寫。此變量是隻讀的,由於它反映了文件系統屬性並設置它對文件系統沒有影響。
該參數爲靜態,可設置爲0、一、2。
0 --大小寫敏感。(Unix,Linux默認) 建立的庫表將原樣保存在磁盤上。如create database TeSt;將會建立一個TeSt的目錄,create table AbCCC ...將會原樣生成AbCCC.frm。 SQL語句也會原樣解析。
1 --大小寫不敏感。(Windows默認) 建立的庫表時,MySQL將全部的庫表名轉換成小寫存儲在磁盤上。 SQL語句一樣會將庫表名轉換成小寫。 如須要查詢之前建立的Test_table(生成Test_table.frm文件),即使執行select * from Test_table,也會被轉換成select * from test_table,導致報錯表不存在。
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,則不該將lower_case_table_names設置爲0。
我本身在個人window10環境嘗試設置lower_case_table_names
爲0的時候,MySQL的服務怎麼也啓動不能,啓動服務報錯。windows系統對大小寫不敏感,見下圖:
注: 若是要修改lower_case_table_names
這個值,windows下修改my.ini ,Linux下修改my.cnf配置文件,須要重啓服務,具體操做能夠自行上網找資料。
修改lower_case_table_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
,重啓生效。
③、導入數據至實例,此時包含大寫字母的庫名已轉換爲小寫。
有了踩坑的經驗,對開頭說的阿里Mysql規約理解更加深刻了。操做系統不一樣致使大小寫敏感不一致。咱們在開發時,應該按大小寫敏感的原則去開發,這樣可使開發的程序兼容不一樣的操做系統。所以,建議在開發測試環境下把lower_case_table_names
的值設爲0,便於在開發中就嚴格控制代碼大小寫敏感,提升代碼的兼容和嚴謹。
MySQL大小寫敏感問題lower_case_table_names & lower_case_file_system
謝謝你的閱讀,若是您以爲這篇博文對你有幫助,請點贊或者喜歡,讓更多的人看到!祝你天天開心愉快!
無論作什麼,只要堅持下去就會看到不同!在路上,不卑不亢!
願你我在人生的路上能都變成最好的本身,可以成爲一個獨擋一面的人
© 天天都在變得更好的阿飛雲