今天在将开发环境中的门户数据库复制到新环境后，使用SqlSugar的ORM框架进行数据库操作的时候，出现了主键找不到的现象。排查了很久终于发现了关键点。特此记录。
1.开发环境：
操作系统：CENTOS7 64位
内存： 1GB
CPU 1/1
网络适配器：网桥模式
安装模式：最小化安装
系统语言设置：zh_CN.gb2312
数据库版本：MySQL 5.6.29 binary 模式安装
建立数据库之前：my.cnf参数配置
character-set-server = utf8
log-bin=mysql-bin
skip-name-resolve
lower_case_table_names = 0 #之后可能设置过1的现象
开发数据库实例名称：GoodMES_P_V0_5
数据库实例中表名称，列名称 全部大写
具体还经过哪些设置暂时不记得了，但是最终的结果是，不论sql语句中表名称大小写，都能查到数据。根据推测，数据库大小写也都能认识。对数据库的操作是DOS.ORM
2.这次的部署环境：
操作系统：CENTOS7 64位
内存： 1GB
CPU 1/1
网络适配器：网桥模式
安装模式：最小化安装
系统语言设置：zh_CN.UTF-8
数据库版本：MySQL 5.6.29 binary 模式安装
数据库实例名称：G_START
数据库实例中表名称，列名称 全部大写
使用SqlSugar的ORM框架进行数据库操作的时候，出现了主键找不到的现象。通过记录mysql日志信息，得到数据库操作记录信息，发现SqlSugar的ORM框架对数据库的操作之前，必然都会将实体名称，表名称，列名称全部转换成大小写。然而由于mysql默认设置的是大小写敏感，故而找不到主键信息。同时针对需要主键信息来进行处理的内容，都会存在问题，因为SQLSugar的InSingle操作或者其他的针对主键的操作，都会进行一个获取主键的动作，而这个获取主键的动作是通过
select DISTINCT TABLE_NAME as tableName,COLUMN_NAME as keyName from INFORMATION_SCHEMA.COLUMNS where table_name='" + tableName + "' AND COLUMN_KEY='PRI'这个SQL语句来获取的，虽然这里的tableName传入是正确的是表名称，但是由于是被转换成了小写，所以这里是查不到数据的。从而导致了找不到主键的情况（SQLSugar框架的坑还是大部分数据库操作框架的坑？）。
查阅网上信息，说可以通过设置lower_case_table_names这个数据库的参数来进行设置，设置了lower_case_table_names=1（大小写不敏感）一个更严重的问题出现了，因为数据库实例的名称也是大写的。但是SQLsugar同样的进行了小写化操作。所以数据库仍然是找不到的，同样的mysql客户端在选择该数据库的时候，也出现了数据库未找到的情况。
查询mysql官网，lower_case_table_names有第三个参数：
0：默认值，大小写敏感；请注意如果在大小写不敏感的文件系统上用--lower-case-table-names=0强制设为0，并且使用不同的大小写访问MyISAM表名，会导致索引破坏。
1：表名在硬盘上以小写保存，名称对大小写不敏感。MySQL将所有表名转换为小写以便存储和查找
2：表名和数据库名在硬盘上使用CREATE TABLE或CREATE DATABASE语句指定的大小写进行保存，但MySQL将它们转换为小写以便查找。（这个操作需谨慎，因为一旦这样设置了，那么实际上就变成了表里不一的情况，查找问题就比较难了。）
很明显我的目的是否能实现的最终拍板权还是文件系统，无论我怎么设置大小写敏感还是大小写不敏感，都无法对数据库进行操作。区别点在于一个是能连接到数据库，一个是连数据库都找不到了。
所以我的最终结果是：
1.设置数据库大小写不敏感
2.重新配置一个实例：实例名称小写
3.将开发环境中的数据表导出一份
4.将表结构导入到部署环境，你会发现导入后的表名都变成了小写。但是表中的列的名称仍然是大写。
结论：在windows下MySQL数据库中实例，表，列的名称都是大小写不区分的，随意折腾。但是到了类Unix系统，比如Ubuntu，CentOS，那么在部署数据库之前必须要谨慎考虑，是需要大小写敏感还是大小写不敏感。数据库中实例，表，列名称的命名是要用大写的还是小写的。万一处理不好，最糟糕的可能就是数据库重建。耗时耗力，还吃力不讨好。
建议：命名全部小写；建议区分大小写。一旦设定，则不建议修改数据库设置。同时在应用时选择数据库操作框架的时候，需要谨慎考虑。了解底层对数据库的操作方式。