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

時間 2019-12-06

標籤一個 mysql 大小寫敏感致使問題欄目 MySQL 简体版

原文原文鏈接

作一個積極的人html

編碼、改bug、提高本身mysql

我有一個樂園，面向編程，春暖花開！linux

00 MYSQL對大小寫敏感

見字如面，見標題知內容。你有遇到過由於MYSQL對大小寫敏感而被坑的體驗嗎？程序員

以前看過阿里巴巴Java開發手冊，在MySql建表規約裏有看到：sql

【強制】表名、字段名必須使用小寫字母或數字，禁止出現數字開頭，禁止兩個下劃線中間只出現數字。數據庫字段名的修改代價很大，由於沒法進行預發佈，因此字段名稱須要慎重考慮。數據庫

說明： MySQL 在 Windows 下不區分大小寫，但在 Linux 下默認是區分大小寫。所以，數據庫名、表名、字段名，都不容許出現任何大寫字母，避免節外生枝。編程

正例： aliyun _ admin ， rdc _ config ， level 3_ name 反例： AliyunAdmin ， rdcConfig ， level 3 namewindows

若是沒有真正遇到過相似的問題，有時候乾巴巴的看這些規約體會不深，理解起來似懂非懂，而且也只是死記硬背而已。服務器

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、一、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，便於在開發中就嚴格控制代碼大小寫敏感，提升代碼的兼容和嚴謹。