标签归档:规范

FAQ系列 | lower_case_table_names迷思

导读

关于 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中使用的表名都记录下来,然后检查还有哪些和我们定义的规则不一样,再逐渐完善修改,最终达到最终目标。

写在最后

强烈建议在定义数据库设计规范时,统一采用全部都大写或全部都小写的数据表命名规则,没必要为了所谓的美观,弄出一堆大小写混合的表名,是在太操蛋了。

关于MySQL的方方面面大家想了解什么,可以直接留言回复,我会从中选择一些热门话题进行分享。 同时希望大家多多转发,多一些阅读量是老叶继续努力分享的绝佳助力,谢谢大家 :)

关于MySQL的方方面面大家想了解什么,可以直接留言回复,我会从中选择一些热门话题进行分享。 同时希望大家多多转发,多一些阅读量是老叶继续努力分享的绝佳助力,谢谢大家 :)

最后打个广告,运维圈人士专属铁观音茶叶微店上线了,访问:http://yuhongli.com 获得专属优惠

 

个人PPT分享

个人最近几年内整理过的PPT,都放在百度文库上了,大家可以看看 :)

M​y​S​Q​L​ ​t​p​c​h​测​试​工​具​简​要​手​册

高​效​L​i​n​u​x​ ​S​A​

P​C​服​务​器​阵​列​卡​管​理​简​易​手​册​

服​务​器​基​准​测​试

M​y​S​Q​L​数​据​库​设​计​、​优​化 

M​y​S​Q​L​之​设​计​、​优​化​、​运​维