导读
关于 lower_case_table_names 选项的设置的建议是怎样的呢？
问题由来
我个人认为，纠结于这个选项设置源于有些项目是从ORACLE或SQL Server迁移过来，在这两个数据库系统中，都无需关心数据表的大小写。而在MySQL中，默认是要区分大小写的(因为Unix/Linux文件系统是区分文件名大小写的)，除非在windows系统下(windows系统是不区分大小写的)。
老叶的建议
我在公司制定的规范是要求默认设置 lower_case_table_names=0 的，也就是区分大小写。那么问题来了，如果是从ORACLE或SQL Server迁移到MYSQL的应用应该怎么处理呢？
我的建议是：
- 首先，检查确认在应用程序中（或者抓取一段时间的请求日志），数据表名的写法是大写、小写还是混用，如果都是大写或者都是小写，那就更简单些了；
- 其次，根据上面检查的结果，确定迁移到MySQL后统一使用大写还是小写（使用哪种规则的改动代价更小）；
- 最后，利用Linux下的awk\sed等工具，将包含数据表关键字的地方全部替换成第二部定义好的表名方案；
这样一来，就可以完成数据表名方案的切换了。
当然了，肯定有人（比如某领导、某PM，你懂得的，O(∩_∩)O哈哈~）会说全部修改表名风险太大，需要全面测试，但这个项目时间进度很紧张，希望能先上线。这种情况就没办法了，只能先设置 lower_case_table_names=1，然后迁移数据，优先保证项目的进度。
but，即便这时候，我们也建议数据表初始化时，统一采用大写或小写的表名，在项目的后续过程中，通过开启general log的方式，把所有请求SQL中使用的表名都记录下来，然后检查还有哪些和我们定义的规则不一样，再逐渐完善修改，最终达到最终目标。
写在最后
强烈建议在定义数据库设计规范时，统一采用全部都大写或全部都小写的数据表命名规则，没必要为了所谓的美观，弄出一堆大小写混合的表名，是在太操蛋了。
</div>