MySQL对大小写敏感吗.docxVIP

MySQL对大小写敏感吗 之前看过阿里巴巴Java开发手册，在MySql建表规约里有看到： 【强制】表名、字段名必需使用小写字母或数字 ， 禁止消灭数字开头，禁止两个下划线两头只 消灭数字。数据库字段名的修改代价很大，由于无法进行预发布，所以字段名称需要慎重考虑。 说明：MySQL 在 Windows 下不区分大小写，但在 Linux 下默认是区分大小写。因而，数据库名、 表名、字段名，都不允许消灭任何大写字母，避开节外生枝。 正例：aliyun _ admin ， rdc _ config ， level 3_ name 反例：AliyunAdmin ， rdcConfig ， level 3 name 假如没有真正遇到过类似的问题，有时候干巴巴的看这些规约体会不深，理解起来似懂非懂，并且也只是死记硬背而已。 1 一个表字母大小故事 最近本人在鼓捣一个项目玩玩，在本人本机上开发和测试过程中一直没有问题，但是部署到Linux服务器上后，发觉有报错，日志信息或许是： MySQLSyntaxErrorException:?Table?kytu.tb_sutyHo?doesnt?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文件）